Describe the operation before granting access
Imagine an assistant that prepares a customer update. Reading a support ticket, saving a private draft and sending a message are three operations with different consequences. A permission called “manage communications” hides those differences. A more useful design names the resource, permitted operation and destination, then states how the application will check them.
That design can begin without an autonomous agent. Anthropic's Building effective agents distinguishes predefined workflows from systems in which a model directs its own process and tool use. The distinction helps locate responsibility: a predictable draft-and-review sequence may need fewer capabilities than a system allowed to choose its own next action. This is an architectural observation, not a recommendation for a particular current service tier.
Keep the access boundary in the application
Our proposed capability record has a concrete shape: read these ticket identifiers, create drafts in this workspace, and never send to an external address through that capability. The tool implementation checks the resource and operation on every request. A prompt can explain the boundary to the model; the application still needs to enforce it when a tool call arrives.
Credential scope also needs a destination. RFC 8707 defines resource indicators that let an OAuth client identify the protected resource for which it requests a token. Its audience discussion explains why a credential intended for one service should not become general access to another. “Has a token” is an incomplete authorization decision.
The official MCP security guidance describes audience-validation failures and forbids token passthrough in its authorization model. This is a specific protocol requirement. It should not be stretched into a claim that connecting an MCP server automatically makes every exposed tool safe. The server's actual methods and downstream privileges still matter.
Give consequential steps a concrete review surface
For the hypothetical customer update, a review screen should show the recipient, message, attachments and identity used to send it. Approval can then refer to that proposed action. If the destination or attachment changes, the application can request a fresh decision. A vague request to “continue” provides little evidence about what the reviewer understood.
Retries deserve their own rule. An uncertain response after a send request may mean that delivery happened and its acknowledgment was lost. Automatically repeating the operation can create a duplicate. Where a service supports idempotency identifiers, keep the identifier with the attempted action and inspect its result before issuing another request. Where it does not, make uncertainty visible to the operator.
Test denial as carefully as success
A useful permission test includes an allowed ticket, an unauthorized ticket, an unexpected destination and an expired credential. Check what the application actually does, including whether a rejected call leaves behind a partial draft or background job. Save the operation, resource identifiers and decision without placing secrets in the audit record.
This approach treats tool access as an interface that can be inspected and tested. Start with the smallest action set that completes the workflow, then expand it when a real task requires more. A readable permission boundary gives both the operator and the developer a better chance of understanding an agent's next step.