Remove the SHOULD requirement to duplicate structuredContent within a TextContent block, relaxing guidance to match field usage.

Motivation and Context

Problem: Usage of structuredContent in the field has diverged from the specification. In particular, the marquee MCP Apps extension provides guidance on using structuredContent in a way that contradicts the "SHOULD" guidance in the current MCP Specification.

Usage in the Field: Tool Result structuredContent is normally used to deliver information to Host applications for pre-processing before presenting to the model. Primary use-cases are:

• Code Generation tools where the Output Schema is presented to the model to enable code generation. This allows the host (or a tool-embedded execution environment) to process data out-of-context.
• UI integrations where structuredContent is used to send data to the presentation layer.

Examples of contradictory guidance:

From the MCP Apps specification:

Best Practices:

• content: Text representation for model context and text-only hosts
• structuredContent: Structured data optimized for UI rendering (not added to model context)
• _meta: Additional metadata (timestamps, version info, etc.) not intended for model context

From the OpenAI Apps SDK Developer guide:

Every tool response can include three sibling payloads:

structuredContent – concise JSON the widget uses and the model reads. Include only what the model should see.
content – optional narration (Markdown or plaintext) for the model’s response.
_meta – large or sensitive data exclusively for the widget. _meta never reaches the model.

NB: Discussion of the difference between these two specifications is out of scope - they are presented to highlight the discrepancies to the MCP Specification.

Proposed Action:

The current MCP Specification states:

For backwards compatibility, a tool that returns structured content SHOULD also return the serialized JSON in a TextContent block.

This guidance is contradictory to current practice.

The proposal is to update the guidance to instead read:

For backwards compatibility, a tool that returns structured content SHOULD also return a TextContent block representative of the result data.

Reduces ambiguity in the specification, improves developer experience, provides greater flexibility for MCP Server authors to return most appropriate representations of content.

How Has This Been Tested?

Breaking Changes

Developers adhering to the old guidance do not need to make any changes. Developers presenting other content (e.g. markdown, MCP Apps guidance) are no longer violating the SHOULD guidance.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Example thread of confusion caused by existing guidance: https://discord.com/channels/1358869848138059966/1411057080902746293