MCP results and model Structured Outputs: what schema checks leave unestablished

Two valid records can leave one business question unanswered

An inventory API returns typed stock data, and an agent produces a typed replenishment recommendation. Both records fit their schemas. Before relying on the recommendation, the business still needs to know whether it uses the right item's stock observation at the decision time. A successful schema check does not answer every part of that question.

MCP describes structuredContent as server-produced result data and explicitly distinguishes it from schema-constrained model generation.[1][3] OpenAI's Structured Outputs guide describes model responses constrained by a supplied JSON Schema, including required keys and enum values.[2] A server returning data and a model generating a recommendation are different stages, even when both produce JSON.

Our interpretation: validation establishes the constraints encoded in that schema for that result. It does not independently establish the truth of an observation or the contents of a record named by an evidence_id. Identify which condition the existing checks have left unestablished before adding another check.

MCP defines the returned data contract, with edition-specific details

An MCP tool can declare outputSchema, an optional JSON Schema for its expected output. When it does, the specification says servers MUST provide structured results conforming to that schema and clients SHOULD validate those results.[1][3] A server's obligation is not proof that a particular deployed server fulfilled it, and the client guidance should not be rewritten as an unconditional protocol MUST.

The value shape depends on the edition. The 2025-11-25 Tools page describes structuredContent as a JSON object.[1] The preserved 2026-07-28 Tools edition permits any JSON value—an object, array, string, number, boolean or null—conforming to outputSchema when one is defined.[3] Bind the integration to its actual protocol edition and implementation support rather than carrying the old object-only description into every contract. This comparison does not establish which edition a reader's deployed client supports.

The legacy edition also says a tool returning structured content SHOULD serialize the JSON in a TextContent block for backward compatibility.[1] Two representations of the same result are not two independent confirmations of its underlying facts. Compare representations if needed for compatibility, but do not count the text copy as fresh stock evidence.

MCP separates JSON-RPC protocol errors from tool-execution errors reported with isError: true.[1][3] Do not accept an execution-error result as an ordinary stock observation just because some fields can be parsed. The reviewed passages do not establish an isError-specific exemption from outputSchema or one mandatory structured error object. Resolve the actual server/client error contract rather than inferring it from an unrelated example.

Constrained generation reduces a parsing problem, not every evidence problem

A schema-constrained model response can make the next application step more predictable: the application can expect declared keys and permitted decision values on the successful response path described by the guide.[2] That is different from a database server returning its own structured result. A recommendation schema organizes what the model says; it does not make the model's referenced inventory record current.

OpenAI explicitly says Structured Outputs can still contain mistakes and warns that unrelated input can lead to hallucinations as the model tries to fit the schema.[2] A required evidence_id string can therefore be present without demonstrating that it identifies the right item. This is a documented limitation, not an accuracy rate measured here.

The guide also describes refusals that need not follow the supplied response_format schema and incomplete responses, including those caused by a token limit.[2] Inspect the completion and refusal signals appropriate to the API in use before consuming the ordinary recommendation. Its examples use different response paths across APIs; there is no single field path demonstrated here for all integrations. A refusal or incomplete response is not a business decision of no_replenishment.

OpenAI supports a subset of JSON Schema.[2] Do not assume an MCP outputSchema can be reused unchanged as the model's generation schema. Check the supported constraints and API/model combination. This article compares documented mechanisms; it does not report a compatibility test.

Completed hypothetical example: the same valid shape, a different evidence decision

Everything in this example is fictional: the records, schemas, model recommendations and checks. No MCP tool or model was run. The task is to prepare a replenishment recommendation for SKU-DEMO-17, not to place an order. At a hypothetical decision time of 12 October 2026, 12:00 UTC, the business requires an authoritative stock snapshot between 0 and 30 minutes old and prepares replenishment only when stock is below 10 units. These thresholds are proposed example policy, not MCP or OpenAI requirements.

The fictional INVENTORY-v1 contract requires sku, stock_units, as_of and evidence_id. It permits a nonnegative integer stock_units and string values for the other fields. RECOMMENDATION-v1 requires sku, evidence_id and decision, whose permitted values are no_replenishment, prepare_replenishment and hold. Assume both examples satisfy these illustrative shape constraints. These names are application labels, not protocol-defined fields or status enums. The shape contracts alone do not enforce the freshness calculation or evidence lookup.

Stale branch: DEMO-STOCK-r1 reports SKU-DEMO-17 with 30 stock_units and as_of 2026-10-12T09:00:00Z. The fictional model returns no_replenishment for SKU-DEMO-17, citing DEMO-STOCK-r1. That recommendation is consistent with the old quantity and fits the permitted decision enum. At 12:00 UTC, however, the observation is 180 minutes old, beyond the 30-minute limit. The resolved application decision is HOLD: do not rely on this recommendation for current replenishment. The next action is to obtain a current authoritative snapshot for the same item and recompute the recommendation. The old record need not be false for this hold to be justified.

Current branch: assume the application's lookup confirms DEMO-STOCK-r2 is an authoritative record for the same SKU, with 4 stock_units and as_of 2026-10-12T11:55:00Z. The fictional model returns prepare_replenishment citing DEMO-STOCK-r2. The observation is 5 minutes old, within the 30-minute limit, and 4 is below 10. Under the explicitly assumed source and item checks, the resolved decision is ACCEPT FOR PREPARATION: route the recommendation to the replenishment planning step. No purchase follows from this acceptance; execution still needs its own business authority and conditions.

Countercase: replace the second recommendation's evidence_id with DEMO-OTHER-ITEM-r2, a string that resolves to a different SKU. The recommendation can still meet its shape contract, but the item correlation fails. Keep it on HOLD until the correct record is supplied and the decision is recomputed. If lookup is inaccessible, call the evidence condition unresolved—not a zero-stock observation. A digest can help identify retained bytes; without access to those bytes and their source, it cannot tell the reader what the record says.

A practical acceptance procedure for the integration you already have

The following procedure is our proposed application policy. Add only checks that the intended decision needs and that the existing system has not already established. Keep enough evidence to explain the resolved outcome; do not build a second service merely to repeat a trusted check.

• Define the use before the schema: a stock display, a planning recommendation and an executed order have different consequences. Identify the material freshness, item-binding and business-rule conditions for that use.
• Separate result paths first. Classify protocol errors, isError tool results, model refusals and incomplete responses under the actual integration contract. Only an ordinary completed result enters the ordinary recommendation path.
• Validate the exact tool result against its declared outputSchema when applicable, and validate the model response under its supported generation contract. Record which schema version was used; a declared schema is not a record of validation.
• Resolve the evidence reference to the relevant authoritative record. Check the same item, the observation time against the decision time, and the material rule. A string-shaped identifier or date does not itself perform these checks.
• Record the resolved outcome and reason. In the stale example, hold for a current snapshot; in the current example, accept for planning only. Keep the observation, recommendation and checked evidence correlated, subject to applicable access and retention limits.
• Change the decision only when the missing condition is established. A current authoritative same-item record can release a freshness hold; an inspectable existing application check can establish a condition without a new manual review. Neither automatically grants execution authority.

Acceptance evidence can be an existing application result that checks the rule and retains the relevant record. If the stock system already binds item identity and enforces the required freshness limit, reuse its evidence rather than asking a human to confirm every recommendation. A low-consequence exploratory display may need only typed data with clearly disclosed scope.

Strengthen the contract where it helps; retain evidence where it matters

Do not reduce schemas to punctuation checks. Supported enums, ranges and other constraints can encode meaningful business conditions—for example, rejecting a negative stock count or an impermissible decision value. Where a relevant condition can be enforced by a stronger schema or a trusted existing application, enforce it there. The remaining question is whether the asserted evidence corresponds to the authoritative, applicable observation.

Clearer contracts can reduce ad-hoc parsing, but someone must maintain them, handle exceptional paths and obtain evidence for consequential conditions. Additional checks can delay a decision or hold a recommendation that later proves correct. Match them to the use. These are design trade-offs, not measured latency, savings or reliability results.

Source limits matter to this comparison. The legacy MCP page and OpenAI guide were captured on 12 October 2026 KST; the 2026-07-28 MCP edition uses a preserved capture from 8 October KST, not a fresh latest-version check. Whole-page editorial publication and update dates are unknown. A discovery extraction doubled some MCP code lines; the synthesis relies on preserved passages and checked source examples rather than copying those doubled lines. No deployed client, stock API or model was exercised, and no cost or accuracy advantage was established.

For the inventory example, another schema pass over DEMO-STOCK-r1 cannot resolve the freshness hold. A current authoritative same-item record can; inspectable evidence that the existing application has already checked the required condition can also be enough. Use those checks to advance a supported recommendation to planning. Purchase authority remains a separate decision.