What's broken?
The spec is ambiguous or self-contradictory
Where in the spec or docs?
https://modelcontextprotocol.io/specification/2025-11-25/server/tools
What should happen?
The use of unstructured content in the example for tool execution error without a textural reference of whether its proposed to be always used or it is up to the implementor choice is unclear.
The gap this creates:
Since content[].text is unstructured and unvalidatable, anything can reach the LLM context window via the error path — including stack traces, internal system identifiers, and PII sourced from downstream systems. There is no structural mechanism to prevent this; it relies entirely on developer discipline at the MCP server layer.
structuredContent with outputSchema already provides exactly the right mechanism — schema validation before client consumption — but is undefined for errors.
Specific questions for the spec
1. Is content[] intentionally prescribed as the LLM-facing error signal, or is this an example that became a de facto standard?
2. Is structuredContent intentionally excluded from the error path, or is this a gap?
3. Given that the spec uses SHOULD (not MUST) for content[] when structuredContent is present, would the spec support structuredContent as the primary error signal when outputSchema is declared?
4. Would the spec consider defining a structured error schema within structuredContent for isError: true responses — analogous to how Protocol Errors have a defined schema in JSON-RPC 2.0?
Proposed direction
Allow structuredContent to carry a defined error object on the error path when outputSchema is declared, enabling MCP clients to schema-validate before LLM forwarding. This would: close the PII leakage vector, provide a deterministic LLM self-correction signal, and align the error path with the structured governance model already established for the success path.
What actually happens?
Observation
The MCP spec 2025-11-25 prescribes content[] as the error signal for Tool Execution Errors (isError: true), shown by example in the tools specification. However the spec explicitly describes content[] as carrying “unstructured” content with no schema validation mechanism.
Simultaneously, the spec defines structuredContent with outputSchema validation for the success path — a schema-governed, client-validatable channel — but does not extend this to the error path.
Anything else?
No response
What's broken?
The spec is ambiguous or self-contradictory
Where in the spec or docs?
https://modelcontextprotocol.io/specification/2025-11-25/server/tools
What should happen?
The use of unstructured content in the example for tool execution error without a textural reference of whether its proposed to be always used or it is up to the implementor choice is unclear.
The gap this creates:
Since content[].text is unstructured and unvalidatable, anything can reach the LLM context window via the error path — including stack traces, internal system identifiers, and PII sourced from downstream systems. There is no structural mechanism to prevent this; it relies entirely on developer discipline at the MCP server layer.
structuredContent with outputSchema already provides exactly the right mechanism — schema validation before client consumption — but is undefined for errors.
Specific questions for the spec
Proposed direction
Allow structuredContent to carry a defined error object on the error path when outputSchema is declared, enabling MCP clients to schema-validate before LLM forwarding. This would: close the PII leakage vector, provide a deterministic LLM self-correction signal, and align the error path with the structured governance model already established for the success path.
What actually happens?
Observation
The MCP spec 2025-11-25 prescribes content[] as the error signal for Tool Execution Errors (isError: true), shown by example in the tools specification. However the spec explicitly describes content[] as carrying “unstructured” content with no schema validation mechanism.
Simultaneously, the spec defines structuredContent with outputSchema validation for the success path — a schema-governed, client-validatable channel — but does not extend this to the error path.
Anything else?
No response