Sampling structuredOutput

[kentcdodds]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

I think when we request a sampling, we should be able to specify the return output. Here's all the stuff I have to do because sampling doesn't have this in the spec currently:

https://github.com/epicweb-dev/mcp-fundamentals/blob/fbf4689e4634fd13684728ba21000b59451ab5f8/exercises/05.sampling/02.solution.advanced/src/sampling.ts#L48-L78

TL;DR, it's a bunch of zod schema stuff. Also if this was supported then maybe examples would be unnecessary as well. That would be nice.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[evalstate]

Great idea. Some initial thoughts on this:

1. The availability of Structured sampling should be advertised during negotiation as a capability.
2. The current design allows the Server to provide model selection hints. Since not all Model Integrations will support Structured Outputs I wonder what precedence the request for a Structured return should have alongside Cost/Intelligence parameters.
3. Separately I wonder how many people are using those parameters for dynamic selection anyway, and the adjectives people tend to use at the moment are more around reasoning, planning capability rather than the current adjectives...
4. LLM Structured Output APIs are extremely sensitive to JSON Schemas, so this will likely cause integration headaches. I don't think this is something the protocol itself can solve, but worth being aware of (@toby, @digitarald).
5. Structured Output schema adherence varies with technique used. My initial thought is that validation of result should occur at the MCP Server side. There's also the possibility of advertising "Strong" or "Weak" generation based on the technique used, but think in most cases integrators will be choosing the "Strong" option. I don't think the protocol should make guarantees on the quality of downstream model response.
6. Looking at the APIs, mapping the stop reason and output content type to be most similar to the APIs would probably mean returning JSON in the initial TextContent (OpenAI response_format style). Anthropic JSON mode uses a stop reason of tool_use and delivers JSON in the input field if using non-prompt style structured outputs. The other alternative would be either EmbeddedResource or a new JSON Object (but given the ability for weak generation my initial thought would to go TextContent).... So basically this would work by providing a response_format in the sampling requestand return a TextContent with whatever the model generated.

Either way, we are proposing a breaking change for Sampling so now would be a good time to get this in - and I can imagine using this a lot. (I'm going to undraft modelcontextprotocol/modelcontextprotocol#198 when I get a few minutes!).

Updated modelcontextprotocol/modelcontextprotocol#198.

Also tagging @ibuildthecloud.

[edit] - I think the principle I am going for is to not burden the Protocol with the nuances of LLM APIs and structured outputs. So maybe just add response_format and indicate that the Host SHOULD return a TextContent with JSON if it's present. (The MCP Server developer can also get structured outputs via Prompting as well).

[kentcdodds]

I don't think this has to be breaking. Could this not be additive?

[evalstate]

This one could be additive - especially if we take the delegative approach. The earlier one linked is the breaking one (although it's straightforward to transition to in the SDKs).