Old paradigm spoiling new – MCP's Structured Output undermines the point of MCP

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

tl;dr - Structured Output actually hurts LLM response quality while making the tools/server ecosystem less interoperable... it should be off by default

Unpacking that slightly: Structured Outputs hurt LLM responses in favor of (very theoretically) better Client interactions.

But this misapprehends the role of the MCP client: the Client's job is to link the API, the LLM, and the user... and get out of the way.

When you start enforcing Client-Server schemas you're coupling specific tools to a specific orchestration which is what makes RPA and agentic workflows so brittle and burdensome in the first place.

--In sum, Structured Output creates the worst of all worlds by misapplying old paradigms to new--

First issue is that Structured Output actually diminishes LLM response quality. Why?

LLMs are trained on raw text and familiar schemas, so they like those things best:

1. The LLM does best with text (it is trained on text)
2. If data is structured, it does best when it trained on that particular structure (e.g. a common MSGraph response, say)

LLMs do actively worse when you introduce extra, low relevance information (like tool schema info):

1. It increases context and token size which quickly reduces LLM response quality
2. It breaks the flow of context, forcing the LLM to reason across spread out information that is interrupted by ancillary info (hurting reasoning)

Second issue is that enforcing Structured Output actually hurts tool availability by making MCP Servers less interoperable with LLMs. How?

Enforcing Structured Output adds boilerplate and overhead to servers for (as per above) no gain to the LLM ; i.e.:

1. Good MCP Servers actually frame their tool names, parameters, and structure in ways that maximize the inherent ability of the LLM to find and select the best tools for the job
2. Structured Output schemes actually add boilerplate and metadata that obfuscates that from the LLMs perspective
3. Only the client benefits from this (which is a problem discussed below)

Structured Output encourages tight coupling between clients and servers, which breaks mass interoperability and self-orchestration (i.e. ruins the main advantage of MCPs); i.e.:

1. If you enforce Structured Output between client and server you've introduced tigher coupling... clients will only work with servers that abide (this is what made agentic workflows and RPA so brittle)
2. If you don't enforce Structured Output between client and server, then you're adding unnecessary overhead to Clients and Servers that try to make themselves univeral
3. Keeping in mind... all this friction you're adding, afford no gain to the LLM interaction... it makes the LLM interaction worse

The final issue is that Structured Output locks client-builders into an old paradigm. How?

MCP clients, in contrast to agentic workflows, are more about UX than logic - they should be thin:

1. The entire advantage of MCP is the LLM self-orchestrates (i.e. does complex logic)... the client's job is to link the API, the LLM, and the user and get out of the way
2. If the client wants to be more about logic, with the occasional check with the LLM, that's fine... but you're building an agentic workflow... go use Langchain, not MCP

If an MCP client needs help with server output, it should rely on the LLM for guidance, not the server's schema:

1. Claude Desktop can work with any MCP Server in existence because it doesn't need a schema to work... it has the LLM to interpret and control flow
2. Clients should be built to get the LLM to help with logic and orchestration
3. If the client wants structured info, it can get that by asking the LLM to structure it in a certain way... this preserves de-coupling with the server and maintains interoperability