A Model Context Protocol tool call should reach a protected operation only after its actual arguments pass the tool schema, its credentials are valid for the intended server, and the caller is permitted to perform that action on that target. Reject a call at the failed boundary before any protected side effect; check the returned data separately after execution.
For AI agent tool calling, well-formed JSON is only the starting point. A valid object can still name another tenant's record, request a prohibited write, or arrive with a token issued for a different service. Use the checks below to review an integration and determine what must change before a rejected call can be retried.
The protocol details follow MCP revision 2026-07-28. The authorization discussion concerns protected HTTP connections; STDIO uses credentials supplied through its environment. The dispatch gates and acceptance tests are recommended application design based on the protocol's validation and access-control requirements.
What must pass before a tool runs?
Schema validity, token validity and operation permission are separate decisions. Each required decision must succeed before execution. The MCP Tools specification requires servers to validate tool inputs and implement access controls; advertising an inputSchema does not perform those checks for the server.
- Arguments: Validate the values that will actually reach the handler against the selected tool's contract. If values change, validate the changed values.
- Credentials: Establish that the access token is valid and intended for this MCP resource server.
- Permission: Check the operation, target object, tenant and permitted effects against the authenticated caller's authority.
A tool list can reflect the permissions on a discovery request. Still enforce permissions when tools/call arrives: a caller can construct a request without using the displayed list. Likewise, a client-side preflight check improves feedback but cannot replace enforcement at the server.
Place cheap envelope checks and authentication where they suit the implementation, while preserving the central rule: every required gate completes before the protected operation. When a sensitive action also needs a human decision, connect these checks to the approval and resume checks for its exact action and arguments.
Build an MCP tool schema the server can enforce
Define the accepted input precisely, then verify that the server uses the matching validator. MCP's default schema dialect is JSON Schema 2020-12. An explicit $schema selects a dialect; unsupported dialects must produce an appropriate error rather than silently changing validation semantics. These requirements appear in the specification's Basic overview, “JSON Schema Usage.”
| Contract element | What to enforce | Failure to prevent |
|---|---|---|
| Contract elementDialect | What to enforceUse the declared dialect, or MCP’s 2020-12 default when none is declared. | Failure to preventA validator accepts a schema while ignoring keywords it does not implement. |
| Contract elementRequired properties | What to enforceList fields the operation needs in required. | Failure to preventA field appears under properties but can still be omitted. |
| Contract elementUnexpected properties | What to enforceFor a simple closed object, use additionalProperties: false. Review composition separately. | Failure to preventExtra arguments reach the handler because properties alone leaves the object open. |
| Contract elementTypes and values | What to enforceSet appropriate types, enums, lengths, patterns and bounds from the operation’s real contract. | Failure to preventSyntactically valid JSON carries an unsupported value. |
| Contract elementFormats | What to enforceVerify whether the validator asserts the formats you depend on. | Failure to preventAn email, date or URI annotation is treated as sufficient enforcement. |
| Contract elementReferences | What to enforceResolve trusted local references and reject unusable contracts. | Failure to preventAn unresolved reference becomes permissive validation or triggers an uncontrolled network fetch. |
JSON Schema's “Understanding JSON Schema” documentation explains the defaults behind these checks: properties are optional unless required, and extra properties are allowed unless constrained. With composed schemas, review how additionalProperties or unevaluatedProperties applies under the chosen dialect. For regular expressions, anchor a pattern when the whole string must match. A format keyword needs the validator's corresponding assertion support and configuration.
Keep resource authorization outside string validation. A URI can satisfy its syntax while pointing to a destination the caller cannot use. An object identifier can have the correct type and still belong to another tenant. Resolve those questions through application policy before acting on the value.
Schema loading also creates a boundary. MCP prohibits automatic fetching of network $ref targets. An optional network-resolution mode must be disabled by default; the specification recommends safeguards such as restricted destinations and bounded resource use. It also recommends rejecting schemas with unresolved external references rather than treating them as permissive. For an integration review, require the validator configuration and trusted-reference policy alongside the schema itself.
Bind the token to the intended resource
Audience answers where a token can be used; scope answers which capabilities it grants. Application authorization then determines whether that caller may exercise the capability on the requested object. Keep all of these checks in the server's trusted code.
Under MCP's HTTP authorization framework, the client supplies the MCP server's canonical resource URI in both the authorization request and the token request. The resource server must still validate the token it receives. Send the access token in the Authorization header on each authorized HTTP request, never in a query string. The MCP Authorization specification's “Resource Parameter Implementation” and “Access Token Usage” sections define these requirements.
For JWT access tokens using RFC 9068, validation includes the expected issuer, signature, expiration, token-type rules and audience membership. The expected resource indicator must be present in the audience. Avoid reducing this to a string comparison between an arbitrary decoded aud and the full request endpoint: token profiles and resource identifiers have defined semantics, and decoding is not validation. MCP does not require every access token to be a JWT. RFC 7662 defines introspection for deployments that obtain token status and metadata from an authorization server.
Reject credentials for another service
The MCP server must reject a token that is invalid for its own resources. Passing an incoming token through to a downstream API without the correct audience boundary is prohibited token passthrough, described in MCP's Security Best Practices. Use a credential and authorization relationship appropriate to the downstream API.
An invalid or expired token receives HTTP 401. A valid token with inadequate scope receives HTTP 403; the specification recommends a Bearer challenge with insufficient_scope and the minimum scopes needed for the operation. The client may then request an appropriate grant through the authorization flow. Repeating the unchanged call cannot create permission.
Enforce the target and the side effect
A scope is one input to an authorization decision. Evaluate it together with the caller's tenant, object access and the operation's allowed effects. For example, a read capability still needs an object-access decision, and a write capability still needs a decision about the target and change being requested. Scope names are application-defined; a tool description cannot grant them.
For each tool, document the mapping from required scopes to permitted operations and objects. Ensure the final arguments cannot substitute another tenant or destination after that decision. The MCP Security Best Practices section on scope minimization supports narrow grants and warns against treating scope claims alone as sufficient authorization.
Reject at the boundary that owns the failure
Distinguish HTTP authorization failures, JSON-RPC protocol errors and tool-level errors. They tell the client different things about what can be repaired. The following matrix combines the MCP Tools and Authorization error rules with recommended dispatch and retry handling.
| Failed check | Response and execution boundary | What permits a retry |
|---|---|---|
| Failed checkUnsupported schema dialect or unresolved reference | Response and execution boundaryStop validation and keep the protected handler out of reach. Unsupported dialects require an error; unresolved references should cause rejection. | What permits a retryA supported, valid schema and resolvable trusted references. |
| Failed checkUnknown tool or malformed call envelope | Response and execution boundaryReturn a JSON-RPC error. The official unknown-tool example uses code -32602. Do not dispatch the protected operation. | What permits a retryCorrect the request structure or select a tool available to this caller. |
| Failed checkInvalid arguments for a known tool | Response and execution boundaryFor actionable input-validation failures, return a tool result with isError: true. Stop before the protected operation. | What permits a retryCorrect the arguments, then rerun validation and authorization. |
| Failed checkMissing, expired, invalid or wrong-audience token | Response and execution boundaryReject at HTTP authorization with 401 and the applicable Bearer challenge. Do not execute the protected tool. | What permits a retryA valid access token for the intended MCP resource. |
| Failed checkValid token, insufficient scope | Response and execution boundaryReturn HTTP 403; use the recommended insufficient_scope challenge. Do not execute the protected tool. | What permits a retryAn appropriate authorization grant for the operation. |
| Failed checkCaller cannot access the tenant, object or requested effect | Response and execution boundaryDeny before dispatch. Use HTTP 403 for an authorization failure; use a tool error for an actionable business-rule failure. | What permits a retryAn authorized context and permitted action. Argument shape alone cannot resolve this denial. |
| Failed checkReturned value violates outputSchema | Response and execution boundaryContain the invalid result before downstream use. The original operation may already have completed. | What permits a retryEstablish action status and retry safety before any new execution. |
In this protocol revision, an actionable argument error belongs in the tool-error category even when validation prevents the business operation from running. The category's name, “Tool Execution Errors,” is not permission to perform a side effect first. A complete tool result in this revision uses resultType: "complete"; isError: true marks failure. Check the selected SDK and negotiated revision when implementing the wire response.
Keep feedback useful and bounded: identify the failing field or missing permission without returning secrets or exposing a protected object's contents. A model can repair an argument; it cannot approve its own access. After any repair, assess the complete new call again.
Validate returned data separately from LLM structured outputs
LLM structured outputs constrain model generation; MCP structuredContent carries data produced by a tool server. The Tools specification explicitly distinguishes these contracts. Model-generated arguments still need input validation and authorization, while a returned value needs its own result checks.
When a tool declares an outputSchema, the server must return conforming structured results and clients should validate them. In MCP 2026-07-28, structuredContent can be any JSON value allowed by the schema. Decide how the application handles an invalid result before passing it to another component or using it as evidence.
A schema-valid string can contain instructions aimed at the agent. Treat returned text as data, and keep credentials, authorization decisions and tool allowlists outside its control. Tool annotations from an untrusted server are also untrusted. The specification calls for output sanitization and recommends client-side result validation; neither establishes that arbitrary prose is safe to obey.
Result rejection is also different from call rejection. If a write completed and its response failed validation, discarding the response cannot undo the write. Establish what happened before retrying. In a workflow with several agents, make the result's validation status and action status explicit in the handoff between agents.
Bring these inputs to the integration review
Review the actual contract and authority mapping before connecting a consequential tool. Assemble a packet that the implementation owner can compare with the server's enforcement points:
- Tool schemas:
inputSchema, anyoutputSchema, selected dialect, validator options, reference-resolution policy and negotiated MCP revision. - Token resource: canonical MCP resource URI, expected issuer and audience, supported token profile and the validation method.
- Permission mapping: scopes required for each operation, tenant and object-access rules, and the trusted identity used for the decision.
- Allowed side effects: which records, destinations and changes each tool may affect, including actions that require human approval.
- Rejection evidence: expected HTTP, protocol or tool error for each negative case, plus instrumentation at the protected handler or downstream service.
Use the rejection matrix as an acceptance-test plan. Send a missing required field, an extra field forbidden by the schema, a token for another resource, insufficient scope, and a request for an object outside the caller's tenant. For each pre-execution denial, assert that the protected operation was never dispatched; an error message alone does not prove that. Include a permitted-call control so a server that rejects everything cannot pass the exercise.
Then test a result that violates the declared output schema. Confirm that the application contains it and preserves the action's execution status before deciding whether to retry. These checks turn the schema, token audience and allowed side-effect list into concrete integration decisions. Explore the wider AI software development coverage for the surrounding engineering context.
Source notes
Protocol requirements are attributed to the Model Context Protocol specification, revision 2026-07-28: Tools (“Capabilities,” “Structured Content,” “Output Schema,” “Error Handling,” “Security Considerations”); Basic overview (“JSON Schema Usage”); and Authorization (“Resource Parameter Implementation,” “Access Token Usage,” “Error Handling,” “Scope Challenge Handling”). The same revision's Security Best Practices supplies the “Token Passthrough” and “Scope Minimization” guidance.
Schema behavior follows the JSON Schema project's Understanding JSON Schema documentation: “Object” (required and additional properties), “String” (length and regular expressions), and “Format.” Token details follow the IETF's RFC 8707, section 2 (resource indicators); RFC 9068, section 4 (JWT access-token validation); RFC 7662, section 2 (token introspection); and RFC 6750, section 3.1 (Bearer error codes).
For a correction to a technical detail, email our team with the affected passage, the protocol revision and the supporting source section. Keep access tokens and private account data out of the message.