Validate tool evidence before downstream use

Learning objective

Validate tool-result structure, provenance, and functional quality before downstream consumption; apply security screening of untrusted responses separately.

Core idea

A tool result is evidence from an external operation. Receiving it does not establish that it has the expected shape, comes from the intended source, or answers the task. Before another agent, model, or business action consumes it, validate structure, provenance, and functional fitness. Then apply a distinct security screen to untrusted content.

A result can be schema-valid but stale, correctly sourced but incomplete, or accurate while carrying malicious instructions. One generic “tool succeeded” flag cannot represent all those outcomes. Keep acceptance reasons separate so downstream code can distinguish usable evidence from technical delivery alone.

See 2.3.9 for pre-invocation compatibility and approval, and 2.3.8 for recovery. Here the decision begins after a call produces a result and ends before that result enters downstream reasoning or execution.

How it works

Validate the result envelope and structure

MCP distinguishes JSON-RPC protocol errors from tool execution errors carried in a result with isError: true. An HTTP response that arrives successfully can therefore contain a failed tool execution. Inspect the protocol and tool outcome before treating content as the requested business data.

MCP tools can declare outputSchema. In revision 2026-07-28, structuredContent can contain any JSON value that conforms to that schema, including an object or array. If a schema is provided, servers must return conforming structured results, and clients should validate them. Do not hard-code “all structured results are objects” across revisions or infer the expected schema from the input alone.

Validate the completed value against the selected tool version’s output schema. Require the fields and constraints that downstream code actually needs. If a tool does not provide outputSchema, define a consumer-side contract or adapter rather than passing arbitrary text directly to a process that expects typed business data. That local contract is an application decision, not a schema supplied automatically by MCP.

The specification distinguishes server-produced structuredContent from schema-constrained model generation. Asking the model to rewrite malformed tool output into JSON does not prove that the rewritten fields existed in the source. If an adapter normalizes a legitimate representation, retain the original result and make the transformation traceable.

MCP also supports text, image, audio, resource links, and embedded resources. Validate the content representation your consumer accepts. An unexpected resource link is not equivalent to already validated document content; fetching it introduces another source and another result to check.

Establish provenance from execution evidence

Bind each accepted result to the invocation that produced it: selected server endpoint, tool name, deployed contract version, request identifier, and arguments. Distinguish that execution evidence from a result’s own claims about its origin. A string saying “verified by finance” is not proof that the finance service produced it.

API Management supports correlation IDs in request headers and the trace policy for custom tracing. Its Azure Monitor and Application Insights integrations provide gateway activity evidence. Use those mechanisms to connect the accepted result to the routed operation; gateway delivery alone still does not prove the correctness of returned business facts.

For workflow-backed tools, Logic Apps workflow run history and its monitoring integrations provide execution evidence. Join that evidence to your application invocation record where the integration exposes a suitable identifier. Do not invent a universal provenance field that every MCP server or connector returns.

For domain data, require provenance fields appropriate to the operation, such as a source record identifier, observation time, or document reference. Define them in the tool or consumer contract when you own it. Confirm that they match the requested object and approved source; a valid field containing another customer’s invoice identifier is still the wrong evidence.

Preserve provenance when deriving a summary or handing data to another specialist. The receiving agent should be able to distinguish an observed source value from an adapter’s normalization or a model’s inference. A concise downstream payload can retain source identifiers and validation outcomes without copying every raw response into the prompt.

Test functional fitness separately from shape

Functional checks ask whether the data can support the intended next action. For invoice status, check that the result refers to the requested invoice, uses an understood status, and is fresh enough for the decision. For search, examine relevance and coverage. These rules depend on the business operation; they are not universal Microsoft thresholds.

Make missing, partial, stale, and contradictory results explicit. An empty result can be a valid “not found” response or a failed lookup disguised as success. The contract must let the consumer distinguish those cases. Do not replace absence with a guessed value merely because the next stage requires one.

Foundry’s agent evaluators provide complementary evidence. Tool Call Success measures technical failures or exceptions. Tool Output Utilization measures whether the agent correctly understood and used returned results. Their evaluator identifiers are tool_call_success and tool_output_utilization. A technically successful lookup followed by an incorrect summary can pass the former and fail the latter.

Use representative evaluation cases alongside deterministic runtime checks. These evaluators support Function Tool, MCP, Knowledge-based MCP, and File Search. Microsoft advises avoiding them for conversations containing Azure AI Search, Bing Grounding, Bing Custom Search, SharePoint Grounding, Code Interpreter, Fabric Data Agent, or Web Search because support is limited. Evaluation evidence does not replace a required-field or exact-invoice check before payment.

Screen untrusted content as a separate control

External results can contain instructions intended to redirect the model. Passing a schema check does not make that text trusted. Keep tool content as data and prevent it from becoming a source of application policy, permissions, or approval.

For managed Foundry agents, configure a guardrail with an Indirect attacks (Prompt Shields) control at the Tool response intervention point, where content returned from a tool enters the agent. Agent guardrails and the Tool response intervention point are preview; Tool response is agents-only, not a model-deployment intervention point.

For application-managed screening, use Azure AI Content Safety’s standalone Prompt Shields document analysis; see 2.1.3 for the REST interface and response handling. Apply the selected block or review policy before downstream consumption.

Prompt Shields detects prompt and document attacks. It does not prove a source’s identity, certify factual accuracy, or establish that an invoice is fresh. Likewise, a security result without a detected attack does not compensate for a failed schema or functional check. Keep these outcomes in separate fields in your application validation record.

Structure, provenance and functional fitness are checked separately before a distinct security screen, and only evidence that passes the applicable gates enters downstream consumption.

Key distinctions and trade-offs

Structure versus function: A schema-valid status response can concern the wrong invoice or be too stale for the requested decision.

Provenance versus self-description: Correlated execution evidence identifies the operation that returned data. Source claims inside that data require their own verification.

Technical success versus correct utilization: tool_call_success and tool_output_utilization answer different evaluation questions. Neither is a universal runtime acceptance gate.

Quality validation versus security screening: Useful evidence can contain an attack. Attack-free content can be false or incomplete. Require each applicable check independently.

Architecture / decision scenario

An assistant retrieves invoice status before drafting a supplier message. The runtime first rejects protocol errors and isError: true, then validates structuredContent against the selected version’s outputSchema. It checks invoice identity and observation time against the task’s declared freshness requirement.

The application binds the result to its invocation record and correlated gateway or workflow evidence. If the response refers to another invoice, it blocks the draft even though the JSON validates. If the response is partial, it records an incomplete outcome rather than letting the assistant invent the missing status.

The supplier note includes external free text. A managed Foundry agent screens that content with the preview Indirect attacks control at Tool response; an application-managed path uses standalone Prompt Shields as covered in 2.1.3. The security outcome remains independent of the business checks. An embedded instruction to send customer records cannot become a tool command. Evaluation cases separately examine technical call success and faithful use of accepted results. Only evidence that passes the applicable gates enters the drafting step; sending the draft still requires the authorization and approval controls in 2.3.9.

Common exam traps

• Treating HTTP success or valid JSON as a usable business result.
• Confusing MCP structuredContent with model structured outputs.
• Trusting source claims inside a response as verified provenance.
• Using a quality evaluator in place of deterministic runtime checks.
• Treating Prompt Shields as a fact checker or provenance verifier.
• Allowing external tool text to grant permissions or approve side effects.

What to remember

Validate the outcome, structure, source evidence, and fitness for the next decision before consumption. Preserve provenance through transformations and handoffs. Screen untrusted content separately; security, correctness, and technical success answer different questions.

Knowledge check

References

• Microsoft, Guardrails and controls overview in Microsoft Foundry.

• Model Context Protocol, Tools, revision 2026-07-28.

• Microsoft, Overview of MCP servers in Azure API Management.

• Microsoft, Create remote MCP servers from Standard workflows.

• Microsoft, Agent evaluators for generative AI.

• Microsoft, Prompt Shields.