Comments addressed! Lmk if you need follow ups.

I think it is a shame that so many SDKs make it easy for server authors to choose structured output and simply stringify it in the unstructured output (content) field without making a conscious decision as to whether this is the right choice.

A lot of models do better with unstructured data. We should make it easy to do the right thing. Making structured output extremely convenient leads developers to assuming it is always superior. Perhaps this cannot be solved at the spec level, especially given we already have the fields with these names.

But I think it would be good with a blog post after this is presumably included in a future spec version, making it clear that whether the model-oriented output is structured or not is a choice, where both options can be valid.

Agreed @PederHP - as I started writing a server and looking into the defaults in the ecosystem that's what motivated me to ask the questions and write this. The MCP Inspector checks that content is stringified-StructuredContent and gives this warning if not which strongly encourages developers to limit their content output to stringified JSON.

Edit: added inspector #1089 to track that fix as well.

good work here folks, thank you!

@PederHP i'm happy to draft the related blog post you mentioned or is the typical practice for that to come from one of the maintainers?

Would you want the blog post to go in at the same time as this or would that be in a subsequent PR when the spec gets bumped to include this?

Maintainer Activity Check

Hi @olaservo!

You're assigned to this SEP but there hasn't been any activity from you in 14 days.

Please provide an update on:

• Current status of your review/work
• Any blockers or concerns
• Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

@PederHP i'm happy to draft the related blog post you mentioned or is the typical practice for that to come from one of the maintainers?

Would you want the blog post to go in at the same time as this or would that be in a subsequent PR when the spec gets bumped to include this?

Hi @krubenok I think we don't need to have the blog post ready at the same time as this, it can be a followup. Typically its been maintainers authoring them, but I think it would also be welcome for other contributors to propose or draft them.

The MCP Inspector checks that content is stringified-StructuredContent and gives this warning if not which strongly encourages developers to limit their content output to stringified JSON.

Just want to note that this was fixed - thank you @krubenok for opening the Inspector issue!

Thanks @evalstate and @cliffhall for the additional feedback.

After tracing the full history of structuredContent through the original PRs, I think Shaun's point (#2200 (comment)) about this being breaking needs to be addressed before this can move forward.

Here's a recap of my current understanding based on more digging:

PR #371's description explicitly stated that structuredContent was "mutually exclusive with CallToolResult.content." It appears that the "SHOULD also return the serialized JSON in a TextContent block" language was added during review (#371 (comment)) as a backwards-compatibility concession and not the core design. PR #559 then made content non-optional again, cementing the coexistence pattern.

So the current spec text where content is expected to be a JSON-stringified copy of structuredContent appears to be a pragmatic compromise layered onto a design that didn't originally intend duplication. The Inspector enforced this compromise (modelcontextprotocol/inspector#1089), SDKs defaulted to it, and it became the de facto understanding for several implementations.

Shaun and Cliff are right that the current spec says content SHOULD be "the serialized JSON in a TextContent block." This SEP redefines content as a potentially different, model-optimized representation.

@krubenok, lets address the above more directly in the SEP:

• The Abstract says "The changes are non-breaking and do not modify the protocol surface area" and the Backward Compatibility section says "This SEP introduces no protocol-level breaking changes." While true at the wire/schema level, this understates the change. The current spec says content SHOULD be "the serialized JSON in a TextContent block." This SEP replaces that with guidance that content should be a model-optimized representation that may differ significantly from structuredContent. Technically a server following the new guidance will produce content that a client built to the old guidance would not expect.
• I'd suggest language like: "This SEP does not change the protocol wire format or field types, but it does change the normative guidance for what servers are expected to return in content when structuredContent is present. Implementations that assume content is a JSON-serialized copy of structuredContent may need to be updated."

@olaservo Thanks, this was helpful.

I updated the SEP to address this more directly:

• the Abstract and Backward Compatibility sections now say this does not change the wire format or field types, but does change the normative guidance for what content should contain when structuredContent is present
• I also softened the Inspector wording to clarify it reflected the prior spec guidance rather than being misleading
• and I noted that treating content as a JSON-serialized copy was assumed in some tooling/implementations, but was not a universally safe assumption in practice

Let me know if this framing now matches your concerns.