An MCP Tool Description Is Not a Permission Policy

Tool metadata helps an agent choose a function, but execution still needs trusted identity, object-level authorization and enforced business constraints.

Use descriptions for selection and application controls for authority

An MCP tool description tells a model what a function is intended to do. It does not establish that the current user may perform that function on a particular record. Enforce identity, tenant scope, object access and business constraints at the execution boundary, even when the model selected the right tool and produced valid arguments.

Writing “only use this after approval” in metadata can help explain a workflow. It cannot prove that approval exists, covers the current inputs or remains valid. The application must verify those conditions independently. Otherwise a direct call or a misleading instruction can reach the effect without satisfying the intended rule.

This article proposes a practical review for a write-capable integration. Its scheduling example is hypothetical. It does not suggest that MCP itself makes a system unsafe or that every read-only request needs a complex approval process. The question is where your actual application enforces the authority it claims to enforce.

Start with one consequential tool and identify the operation behind it. Ask which component can reject the request before the effect occurs, what trusted facts that component uses and what evidence proves rejection. If the only answer is “the prompt tells the agent not to,” the boundary is incomplete.

Separate metadata, schema, identity and business policy

Metadata describes purpose and expected behavior. An input schema defines permitted shape and types. Authentication establishes an identity through the chosen transport and credential mechanism. Authorization determines what that identity may do. Business policy adds constraints such as record state, approval scope and allowed transitions.

These layers answer different questions. A schema can establish that a record identifier is a string, but not that the requester owns the record. A valid credential can identify a client, but not necessarily grant access to every tenant the server can reach. Keep those distinctions visible in the integration review.

The MCP tools specification, version 2025-11-25 defines tool descriptions, schemas and annotations, and requires server-side input validation and access controls. It also warns clients about trusting annotations from untrusted servers. Treat metadata as information to evaluate, not a substitute for verified enforcement.

Document the version and implementation you actually deploy. Protocol-level support does not prove that a particular server checks object-level access correctly. Review the handler and the downstream operation. A convincing tool label can coexist with an overly broad service credential or an omitted record-state check.

Bind execution to trustworthy scope

Construct the effective requester and tenant scope from trusted server-side context. Do not let a model-provided tenant identifier or user name override that context. Tool arguments may identify a requested target, but the executor must resolve whether that target belongs to the allowed scope.

Check the specific object and action. Permission to read a schedule does not imply permission to publish it. Permission to edit one venue does not imply permission to edit another. Apply field-level restrictions where the task needs them, rather than granting a generic update operation over the entire record.

Downstream credentials need their own boundary. The MCP security best practices identify token passthrough as an anti-pattern and discuss audience validation and related risks. Use an explicitly designed authorization flow instead of assuming any token that works somewhere should be forwarded everywhere.

A server using broad service credentials has additional responsibility. The downstream system may see the service account rather than the original reader's permissions. In that case, the executor must constrain the operation to the verified requester and record the attribution required for investigation. Possession of a powerful credential is not business authority.

Worked example: a schedule tool with an approval sentence

Consider a synthetic tool named publish_schedule. Its description says that publication requires an approved draft. Its schema accepts a schedule identifier and revision. A coordinator asks the assistant to publish revision 12, but the approval record covers revision 11. The tool call is structurally valid while the requested transition is not authorized.

The executor should resolve the current schedule, the requester, the applicable approval and the revision binding. If approval does not cover revision 12, it should reject the publication without changing the record. The agent can explain what needs review, but it must not reinterpret the old approval as permission for the new version.

| Check | What it establishes | What it does not establish | | --- | --- | --- | | Tool description mentions approval | Intended workflow is described | A valid approval exists for this request | | Arguments pass schema validation | Required fields have permitted shape | The requester may access the target record | | Requester is authenticated | Identity is established | Publication is allowed in the current state | | Approval matches revision and scope | The intended authority covers the proposal | The effect completed after execution | | Downstream readback confirms revision | The observed record reflects the operation | Every unrelated notification also completed |

Rejection should be understandable without exposing restricted record details. Return a bounded reason such as approval mismatch or unauthorized target according to the application's disclosure policy. Do not include another tenant's schedule content in an error merely to help the model troubleshoot.

The acceptance test must inspect the receiving system. A refusal message is insufficient if the handler already changed the schedule before returning it. Verify that the prohibited effect did not occur, that permitted operations still work and that the attempt retains an appropriate audit record.

Make approval an enforced record, not conversation memory

For consequential actions, define which approval channel is authoritative. A statement in chat can express intent, but the executor needs a trustworthy way to connect that intent to the exact action, target, revision and scope. Do not let arbitrary retrieved text or a tool result masquerade as a new user approval.

Bind approval to the proposal the reviewer saw. If the arguments change after review, evaluate whether the approval remains applicable. Amounts, recipients, record revisions and action types can change the consequence. A generic “yes” stored without that binding is difficult to enforce or investigate later.

Set expiration and revocation behavior according to the workflow. A delayed job should not execute indefinitely on an old decision. Recheck authority at the defined execution boundary and preserve why a held proposal could not proceed. This is especially important when retries, queueing and model fallback happen between approval and execution.

User confirmation in the interface and server authorization complement each other. The interface helps the person understand the proposed effect. The server prevents bypass through a direct request or altered arguments. Neither is a replacement for the other when both are part of the application's stated contract.

Test bypasses without relying on the model's behavior

Exercise the tool handler directly with synthetic identities and records. Try an unauthorized tenant, a permitted tenant with a forbidden object, an expired approval and a changed revision. The expected result is rejection before the effect, regardless of whether a model would normally choose to make that call.

Then test the agent path. Supply misleading source text that asks it to change scope, invoke a different action or treat document content as approval. Verify that the application's enforcement still blocks unauthorized effects even if tool selection or argument generation is wrong. Prompt-level improvements are useful, but they are not the sole acceptance evidence.

Include stale metadata and tool-list changes. A client may have cached a description while the server implementation changes. Version the relevant contract and review behavior changes before enabling them. A familiar name must not silently acquire broader effects under an existing approval policy.

Check uncertain outcomes as a separate failure mode. If the executor sends a write and loses the response, a second invocation must follow the operation's recovery contract. Authorization tells you whether a write is allowed; it does not prove retrying it is safe. Retain operation identity and reconcile the downstream state.

Limitations: the review scope must match the effect

A tool-level review is not a complete assessment of an MCP deployment. OAuth setup, network destinations, local process privileges, session handling and dependencies require their own controls. This article focuses on preventing metadata and model intent from being mistaken for application authority.

Read-only tools also need scope checks when they expose protected information. A tool that never modifies a database can still disclose another customer's records. Classify the actual effect, including exports and external transmissions, rather than assuming every tool labelled read-only has negligible risk.

Do not build an approval ceremony around every trivial operation without considering usability. Match controls to the task's consequence and existing authorization model. A useful design makes ordinary permitted work straightforward while making consequential transitions explicit and independently enforceable.

Tests establish behavior for the implementation and cases exercised. They do not make tool descriptions trustworthy forever or prove every downstream API is correctly constrained. Revisit the boundary when credentials, schema, server version or business rules change, and retain the evidence needed to compare old and new behavior.

Start with a one-tool authority record

For one write-capable tool, record its implementation version, effective identity source, tenant and object checks, allowed transitions, approval binding, downstream credential scope and recovery behavior. Add rejection fixtures and downstream readback evidence. Name the owner who can disable the tool if those guarantees stop holding.

Ask another engineer to call the handler without the agent and demonstrate the denied cases. Then run the same cases through the agent interface. If the direct path can bypass the policy, fix the executor before improving the wording of the description. Better wording does not close an enforcement gap.

Read approval expiry for AI actions for revision binding and tool timeouts and duplicate actions for recovery. Use the action-recovery playbook to organize the exercise. For implementation help, explore agentic workflows or share a tool-boundary question. Reading these resources does not require personal details.