Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-102.3 Build and integrate tool ecosystems

Check compatibility before authorizing tool execution

Completed by the knowledge check

Learning objective

Validate tool-contract compatibility before invocation (argument schemas, tool versions, and idempotency/retry semantics); treat authorization and side-effect approval as separate security controls.

Core idea

Before invoking a tool, establish that the proposed call matches the implementation you intend to run. Compatibility covers its argument schema, deployed version, and repeated-call behavior. Authorization answers whether the caller may perform the operation. Side-effect approval answers whether the concrete operation should proceed with these arguments. Passing one gate does not pass the others.

For an architect, a dangerous mistake is to turn a successful schema check into permission to act. A well-formed transfer request can target an unauthorized account; an authorized caller can still propose an unintended amount. Conversely, human approval cannot repair an argument format that the selected implementation does not accept.

See 2.3.1 for defining typed contracts, 2.3.2 for routing versions, and 2.3.4 for MCP client approval. This lesson joins those mechanisms into a pre-invocation decision rather than repeating their setup.

How it works

Validate the call against the selected schema

MCP tool definitions contain name and inputSchema. In revision 2026-07-28, the input schema must be a valid JSON Schema object, and the default dialect is 2020-12 when $schema is absent. The proposed tools/call arguments must be checked against the definition for the selected server and tool, not against a remembered schema for a similarly named capability.

Treat schema validation as a deterministic execution gate. Check types, required fields, allowed values, and any other constraints the contract declares. Reject or request correction before execution. A description that says “positive amount” is useful selection guidance, but does not replace a schema constraint or a business rule that actually rejects a negative amount.

Bind the tool name to its source. MCP tool names should be unique within a server, and uniqueness is scoped to that server; aggregation can encounter the same name on different servers. A bare search identifier is therefore insufficient to identify the implementation whose contract you validated. Retain the selected endpoint and version alongside the name and arguments.

The MCP specification requires servers to validate inputs as well. Client-side checking gives earlier feedback and prevents avoidable calls, but it does not replace server enforcement. A server must not trust an agent’s statement that its arguments have already passed validation.

Bind validation to a deployed tool version

Do not confuse MCP protocol revision with business tool version. The protocol revision determines the message and capability rules. A tool version determines the operation’s arguments, outputs, behavior, and deployment. Two implementations can speak the same MCP revision while accepting incompatible business requests.

See 2.3.2 for Foundry Toolbox endpoint selection and promotion. Record which Toolbox version your validation ran against. Microsoft directs agents to the consumer endpoint, so enforce compatibility before promotion: test representative valid calls, rejected calls, result expectations, and side-effect behavior against the version-specific developer endpoint before making that version available to consumers.

A changed required argument is an obvious incompatibility; a changed default destination or meaning of a field can be equally significant even when JSON still validates. The promotion decision must cover those semantics, not only protocol support or successful discovery.

Establish replay semantics before accepting retries

The MCP schema defines readOnlyHint, destructiveHint, and idempotentHint in tool annotations. readOnlyHint: true describes a tool that does not modify its environment. For a modifying tool, idempotentHint: true describes repeated calls with the same arguments having no additional environmental effect. An additive action can still be non-idempotent: sending another message adds a second message.

These are hints, not a deduplication implementation. The specification says clients must treat annotations as untrusted unless they come from trusted servers. Even a trusted declaration should be backed by the actual operation contract before it controls automatic retry. Do not infer replay safety from a friendly name or destructiveHint: false.

For a mutation, establish how the implementation handles repeated operation identifiers, the same identifier with different arguments, and a lost response after commitment. If the service implements an idempotency key, preserve it across retries of the same logical operation. If it does not, use the operation’s documented status or reconciliation path before repeating uncertain work. These are backend-specific semantics; there is no universal MCP field that makes every business tool idempotent.

Record the replay decision with the selected contract. An operation can be compatible for one initial call but unsuitable for automatic retries. The bounded retry policy in 2.3.8 must consume this decision rather than assigning retries solely from an HTTP status.

Keep authorization and approval independent

For MCP endpoints governed by API Management, validate-azure-ad-token can validate inbound Microsoft Entra tokens. Apply the intended authorization rules at the gateway and business service; see 2.3.7. A token accepted by the gateway does not, by itself, establish access to every account identifier that fits the schema.

Foundry MCP tools have a separate require_approval configuration. The documented default is always; never disables approval, and tool-specific lists can select which operations require it. When a call requires approval, a response includes mcp_approval_request; the application submits an mcp_approval_response tied to the request’s approval_request_id to continue.

Review the selected tool and concrete arguments. Approval should cover the action that actually executes, not a vague earlier request to “help with finance.” If you change the destination, amount, or tool after review, treat it as a different proposal that must satisfy the same gates again. Keep authorization checks enforceable even when a person approves the request.

Key distinctions and trade-offs

Shape versus meaning: Schema validation detects declared structural defects. Business checks determine whether a structurally valid identifier or value is appropriate for this request.

Protocol revision versus tool version: A shared protocol revision does not establish compatible arguments or business semantics. Validate argument and side-effect semantics before promoting a replacement version; see 2.3.2.

Idempotency versus harmlessness: Idempotency limits additional effects on repetition. It does not establish authorization or eliminate the significance of the first effect.

Authorization versus approval: Authorization grants permitted access. Approval accepts a specific proposed action. Neither substitutes for the other or for compatibility.

Architecture / decision scenario

A purchasing assistant proposes a supplier notification. Before promotion, the team tests the candidate Toolbox version through its developer endpoint. The production agent uses the consumer endpoint, and its runtime checks tools/call arguments against that tool’s inputSchema. A renamed required field causes rejection before invocation rather than silent coercion to a guessed field.

The contract declares that notification sends are not automatically replayable unless the backend’s operation identifier supports deduplication. The runtime records that identifier and the exact arguments. It checks the caller’s access to the supplier independently of the schema, then presents the destination and message through the MCP approval flow.

A returned mcp_approval_response approves that concrete request; it does not widen the caller’s supplier permissions. If the response later times out, the runtime follows the established reconciliation semantics and bounded recovery policy. An upgrade that changes those semantics must pass compatibility review before promotion, even if the tool name and MCP revision remain unchanged.

Common exam traps

  • Assuming valid JSON proves a call matches the selected input schema.
  • Skipping compatibility tests before promoting a Toolbox version to consumers.
  • Equating protocol compatibility with business contract compatibility.
  • Treating idempotentHint as implemented deduplication or authorization.
  • Treating an additive action as necessarily safe to repeat.
  • Using human approval to bypass a failed authorization check.

What to remember

Bind the proposed call to a known source and deployed version, validate its arguments, and establish replay semantics before invocation. Then enforce authorization and concrete side-effect approval independently. A retry policy is safe only when it respects the selected contract.

Knowledge check

References