Connect business tools: APIs, MCP and permissions

When an automated tool needs to read your emails, create a calendar event or send a message, four distinct roles come into play: the provider's API, the MCP server that exposes tools, the connection manager that holds OAuth permissions, and the consuming application that decides what to do. Confusing these roles leads to two classic mistakes: believing that a protocol "secures" things by itself, or believing that a scope label guarantees limited behavior. This guide helps you separate transport, authorization and business operations, then organize revocation and reconnection.

Four roles not to confuse

The provider's API (Gmail API, Calendar API, WhatsApp Business Platform) is the official interface through which software accesses your data. It defines what is technically possible: read an inbox, create a draft, book a time slot. It does not decide what your organization permits.

The MCP server is an intermediary that exposes tools to a consuming application, for example a custom AI agent. According to the protocol's architecture documentation, MCP exchanges tools and context between a client and a server. It structures communication; it does not choose business rules or permissions on your behalf. An MCP server that exposes "send an email" has decided nothing substantive: it is your application that must enforce "drafts only" if that is your choice.

The OAuth connection manager stores access tokens, the granted scopes and their lifecycle. It is what lets you revoke cleanly, reconnect an expired account and know who has access to what.

The consuming application carries the logic: when to act, with what limits, what to do on failure. It is the application, not the protocol, that turns a technical capability into acceptable behavior.

Transport, authorization, operation: three different things

A frequent mistake is to treat these three layers as one. The transport connection answers "did the message arrive?": an MCP server can be reachable, the session active, without any business operation having succeeded. The provider authorization answers "does this token have the right to perform this action at Gmail or WhatsApp?". The business operation answers "did the intended event actually happen, according to the rules?".

A simple example makes the distinction useful. Your agent tries to create a calendar event. Transport works, the token is valid, the call goes out. Yet the event does not appear: the API server accepted the request but a provider-side control rejected the creation. Only an operation proof — the event identifier returned, subsequently verified by a read — tells you it is done. Calendar moreover allows providing explicit event identifiers, which makes reconciliation easier; there is, however, no guaranteed global transaction between your system and the calendar. On this point, handling retries and duplicates deserves particular attention, as detailed in our guide on workflow automation and handling retries and duplicates.

Gmail scopes: a label is not a boundary

OAuth scopes describe the extent requested, not the exact behavior of your application. Two Gmail scopes illustrate this trap. The gmail.compose scope allows creating drafts, but it also allows sending. The gmail.modify scope, broader, also allows sending. In other words, wanting to "limit the agent to drafts" cannot rest on the scope choice alone: the restriction must be an application-level control — your application never calls the send endpoint, even if the token would allow it.

The official page of Gmail API scopes describes each extent; consulting it avoids assuming that a scope name means what its label suggests. Two concrete consequences:

• Choose the narrowest scope that covers the actual need, but never present it as a guarantee of behavior.
• Document, on the application side, the list of calls deliberately forbidden. It is this list, not the scope, that counts during an access review.

A related technical point: a Gmail draft's identifier is stable, but the identifier of the message it contains changes when the draft is modified. If your application caches the message identifier to display or verify a draft, it must reload it after each modification, otherwise it reasons on an outdated version.

MCP exposes tools, it decides nothing

A well-designed MCP server makes capabilities explicit: "create a draft", "list events", "send a WhatsApp template". This explicitness is valuable for review: you see at a glance what the consuming application can attempt. But exposure is not authorization. Three levels of control must remain distinct:

1. What the server exposes: the list of tools, with their parameters.
2. What the token permits: the scopes granted to the provider.
3. What the application allows: its own rules, for example "drafts only for customer service accounts".

If you reduce the perimeter, you often need to act on all three: remove a tool from exposure, reduce the scope at the next reconnection, and adjust application rules. Removing only the exposed tool leaves the token intact; removing only the scope can break other legitimate uses.

The WhatsApp Business Platform case: window, templates and channel

WhatsApp Business Platform operates on a 24-hour service window logic, reopened by a message from the user. Within this window, your application can reply freely. Beyond it, sending goes through approved templates. This mechanics changes the design of an automation: an agent that "answers requests" must know whether it is inside the window or not, and if not, switch to a suitable template.

The WhatsApp usage rules govern compliance, permission and channel exits: a user must be able to stop the conversation, and the permission to contact them must be real. Platform pricing is set per delivered message, depending on category and market; not all messages are paid. Avoid building a budget on a fixed rate remembered from an old scheme: the structure has changed. Finally, beware of shortcuts: a QR code does not prove that a number is connected to the official Business Platform. Preparing the number and the connection is covered in our guide to create a WhatsApp chatbot and prepare the number connection.

Choosing your entry point: decision table

The following table summarizes common situations. The scenarios are hypothetical and serve to situate the roles, not to promise an outcome.

Situation	Dominant role	Decisive control	Trap to avoid
Triage an email inbox	Consuming application	Narrow scope + application triage rules	Believing that gmail.modify "limits" to reading; it also allows sending
Prepare draft replies	Consuming application	Forbid the send call in code	Relying on the scope label
Create calendar events	Provider API	Verify the returned event identifier	Assuming a guaranteed global transaction
Expose tools to an agent	MCP server	Review of the exposed tool list	Confusing exposure and authorization
Connect multiple accounts to an agent	OAuth manager	Inventory of tokens and scopes	Losing track of who has access to what
Reply on WhatsApp within the 24 h window	Provider API	Tracking of window opening	Replying outside the window without an approved template
Connect an uncovered tool	Specific integration	Verify the existence of an official API	Assuming universal compatibility

Composio: a possibility, not universal compatibility

Integration platforms like Composio offer prebuilt connectors to many providers, with authentication management. This can speed up a first project: instead of writing yourself the OAuth dance of each provider, you configure the connection and focus on business logic.

Two caveats apply. First, coverage is not universal: an internal tool of your company, or a niche provider, will have no connector, and a specific integration will be needed. Second, delegating the connection does not delegate the decision: you remain responsible for choosing the requested scopes and the application rules. Before integrating a provider through such a platform, check three things: does the official API exist, do the available scopes match your minimal need, and does revocation remain possible from a single place?

Procedure: connecting a tool cleanly, end to end

Here is a generic procedure, to be adapted to each provider. It assumes one project per use case, which makes revocation easier.

1. Create the container: a dedicated project or application at the provider (for example a Google Cloud project for Gmail and Calendar). Note its name; it is your deletion unit.
2. List the necessary capabilities: write the exact list of operations (read, draft, create an event) and derive the minimal scope. Check the official documentation for what the scope actually allows.
3. Configure the connection manager: register the OAuth client, the scopes, and plan token storage with an expiration date.
4. Define application rules: for each exposed tool, decide what the application allows, forbids, and under what conditions. Fictional example: "drafts only for support accounts, sending impossible even if the token allows it".
5. Test the operation proof: after each action, verify a concrete return (draft identifier, event identifier) by a read. Never consider "the call went out" as "it is done".
6. Document the revocation cycle: where to revoke (provider console, connection manager, both), who can do it, and how to reconnect.

This procedure aligns with the general mission-selection approach described in AI agents in business: choosing a mission that actually ends: a well-bounded connection serves a bounded mission.

Main example: a triage agent with drafts only

Consider a hypothetical example, built to illustrate the roles. An SME wants an agent that triages incoming requests and prepares draft replies, without ever sending. Here is the setup, role by role.

• Provider: Gmail, via a dedicated Google Cloud project. Requested scope: gmail.modify (needed to read and label), accepting that it also allows sending.
• MCP server: exposes three tools — "list unread messages", "apply a label", "create a draft". No sending tool is exposed.
• Connection manager: stores the token, its expiration date and the scope actually granted.
• Consuming application: applies its rules — never call the send endpoint, reload the draft after modification because the message identifier changes, verify each draft by reading before flagging it as ready.

Design commentary. Choosing gmail.modify rather than a read-only scope may be surprising: it is dictated by the need to label, not by a desire to send. It is precisely because the scope is broader than the intended behavior that the application-level control exists. The triage itself — which requests are urgent, which can wait — is covered in our guide on a Gmail AI agent that triages requests without losing the urgent ones. Here, we limit ourselves to the wiring: who exposes what, who permits what, who decides what.

The limit of this setup is honest: nothing technically prevents a developer from calling send with this token. The protection rests on reviewing the consuming application's code and on the absence of a sending tool exposed at the MCP level. It is defense in depth, not an absolute guarantee.

Revocation and reconnection: the cycle to plan from the start

A connection is not a permanent state. Tokens expire, accounts change, needs shrink. Plan the full cycle from the design stage:

• Revocation on the provider side: in the security settings of the Google or WhatsApp Business account, the user can remove an application's access. After that, every call fails until a new authorization.
• Revocation on the connection manager side: delete the stored token and the project entry. Ideally, both revocations happen together; otherwise, a dead token lingers in your records and distorts the inventory.
• Reconnection: redo the OAuth flow, revalidating the scopes. This is the right moment to reduce the perimeter: request only what remains necessary.

The AI agent permissions checklist proposes a periodic review of these accesses; the revocation cycle is its operational complement. One point of vigilance: after a reconnection, cached identifiers (drafts, events) must be revalidated, because the account state may have changed during the interruption.

Common mistakes and how to avoid them

Three mistakes recur as soon as you connect several tools. The first: attributing security to the protocol. MCP structures exchanges; it replaces neither scopes, nor application rules, nor human review. The second: confusing transport success and business success. A call sent without a network error proves nothing about the operation; only the operation proof counts. The third: stacking connections without an inventory. After a few projects, nobody knows which token has which scope at which provider. A simple register — project, provider, scopes, date of last reconnection — avoids this drift.

A fourth mistake, more insidious: designing as if all channels were alike. WhatsApp does not have the same window mechanics as email; the calendar does not have the same consistency guarantees as a database. Adapting the design to the channel is part of the wiring, not an implementation detail. For a first project, the guide on creating your first AI agent helps you choose a perimeter small enough that these controls remain readable.

Frequently asked questions

Can an MCP server prevent my agent from sending emails?

It can refrain from exposing a sending tool, which greatly reduces the risk of accidental use. But if the underlying OAuth token includes a scope allowing sending, such as gmail.compose or gmail.modify, the real protection also comes from your application, which must never call the send endpoint. The protocol structures; it does not decide.

Why not choose a read-only Gmail scope if the agent only triages?

Because triaging often implies labeling or marking as read, which requires a write. The minimal scope covering that need, gmail.modify, also allows sending: it is a limitation of the authorization model, not of your design. The answer is an explicit, documented application-level control.

How do I prove that a calendar event was actually created?

By verifying the event identifier returned by the API, then re-reading the event. Calendar accepts explicit identifiers, which makes this reconciliation easier. There is no guaranteed global transaction between your system and the calendar: verification by reading is part of the normal flow, not an optional precaution.

What happens if a user revokes access on the Google or WhatsApp side?

All calls fail until a new OAuth authorization. Your application must handle this case without an error loop: detect the authorization failure, suspend the affected actions and prompt for reconnection. Reconnection is also the opportunity to revalidate scopes downward if the need has decreased.

Does Composio replace permission management?

It can simplify it by centralizing connections to covered providers. But coverage is not universal and responsibility for the requested scopes and application rules remains yours. Treat this type of platform as an integration shortcut, not as a delegation of your access decisions.