outputSchema
outputSchema is an optional JSON Schema describing the structured result a tool returns. It lets a client validate and parse a response instead of treating it as opaque text. It is genuinely optional, and only 5.6% of the 288 tools we read on 5 August 2026 carried one.
Updated
What is outputSchema?
An MCP tool's outputSchema is the mirror of its inputSchema: a JSON Schema describing the shape of what comes back when the tool is called, rather than what goes in.
When present, a client can validate the result and hand the model structured data. When absent, the result is whatever content the tool returned, typically text.
outputSchema and structuredContent
Declaring an outputSchema is a promise about a second field in the result. Under the current spec revision (2026-07-28), a tool with an output schema MUST return its data in structuredContent, and that value must conform to the schema. Clients SHOULD validate it. structuredContent can be any JSON value, an array included, as long as it matches. For older clients, the spec also says a tool returning structured content SHOULD repeat it as serialized JSON in an ordinary text block in content.
That is where the validation errors come from. A tool that declares a schema and then returns only text has broken the promise, and so has one whose structuredContent is missing a required field or carries the wrong type. A client that validates rejects a response the server thought was fine. The fix is on the server: return structuredContent that matches, or drop the schema. Both fields appear on every tool object in a tools/list response, which is where a client first reads the promise.
Why do so few tools have one?
Because it is optional and the default path works without it. A tool that returns prose has nothing useful to describe with a schema, and most tools return prose.
Across 288 tools from 14 servers on 5 August 2026, only 16 carried an outputSchema, which is 5.6%. It was the rarest field we measured apart from _meta at 2.4%.
Should you add one to your server?
Only when your tool genuinely returns structured data. A schema describing a blob of text adds nothing, and an inaccurate one is worse than none because a client may validate against it and reject a correct response.
Where it pays is a tool returning records: a client that knows the shape in advance can extract fields reliably instead of asking a model to parse them back out of a string.
Example
A tool returning a list of issues with an id, a title, and a status is a good candidate: the schema lets the client render a table directly. A documentation search tool returning matched prose is not, which is consistent with what we saw, since the documentation-oriented servers in our sample, including Microsoft Learn and Context7, returned tools with no outputSchema at all.