MCP Client builders have been asking SDK builders to enforce Structured Output schemas on MCP Servers. The Python SDK has agreed.
Here I assert this is another example of an old paradigm misunderstanding a new one.
Specifically, it is traditional builders and "agentic workflow" builders misunderstanding the various roles in an MCP flow.
Namely, an MCP Client's role is to thinly connect an LLM, a user, and an API... and then get out of the way.
The LLM doesn't gain from wrapping tool output in additional metadata and boilerplate. That just makes the output harder to parse while also making it less similar to the patterns the LLM trained on.
The Client doesn't need the structure to help it orchestrate/route tools... it is the LLM's job to orchestrate.
If you want the Client to orchestrate, that's totally fine. Build with Langchain, not MCP.
The reason agentic workflows need strict adherence to structured input/output is because they are so rigid. Each interaction between one step and another is highly coupled and basically "one-shot".
To get "flexibility" across tasks, you have to layer many of these "one-shot" and coupled flows on top of each other. This is what makes agentic workflows like RPA.
Implicitly, we often treat LLMs as one-shot too. If we ask it to do a coding task, it might make up a method name and we say it hallucinated. But that's raising the bar far above what a human would face. A human would get to goole the method or see in the IDE the warning that the method doesn't exist. Our experience with flaky LLM coding is actually caused by this "one shot" assumption.
MCP flows are the opposite of one-shot. The LLM can use a tool, make a mistake with the data structure, read the error, fix it and move on. There is much lower gain to optimizing to avoid that specific mistake because the LLM still got to the right answer and, with infinite Servers/Tools, the LLM may never do that exact same flow again.
MCP affords a much more self-correcting and flexible system. To the extent there is an art to improving the LLM-Tool interaction, it lies in having the Server builder be thoughtful about how to name the tools and parameters and docstrings.
Enforcing schemas from the client actually makes the least important player (the Client) slightly better off by hamstringing the stars of the show (the LLM and the tool). The real answer, build your clients differently.
MCP Client builders have been asking SDK builders to enforce Structured Output schemas on MCP Servers. The Python SDK has agreed.
Here I assert this is another example of an old paradigm misunderstanding a new one.
Specifically, it is traditional builders and "agentic workflow" builders misunderstanding the various roles in an MCP flow.
Namely, an MCP Client's role is to thinly connect an LLM, a user, and an API... and then get out of the way.
The LLM doesn't gain from wrapping tool output in additional metadata and boilerplate. That just makes the output harder to parse while also making it less similar to the patterns the LLM trained on.
The Client doesn't need the structure to help it orchestrate/route tools... it is the LLM's job to orchestrate.
If you want the Client to orchestrate, that's totally fine. Build with Langchain, not MCP.
The reason agentic workflows need strict adherence to structured input/output is because they are so rigid. Each interaction between one step and another is highly coupled and basically "one-shot".
To get "flexibility" across tasks, you have to layer many of these "one-shot" and coupled flows on top of each other. This is what makes agentic workflows like RPA.
Implicitly, we often treat LLMs as one-shot too. If we ask it to do a coding task, it might make up a method name and we say it hallucinated. But that's raising the bar far above what a human would face. A human would get to goole the method or see in the IDE the warning that the method doesn't exist. Our experience with flaky LLM coding is actually caused by this "one shot" assumption.
MCP flows are the opposite of one-shot. The LLM can use a tool, make a mistake with the data structure, read the error, fix it and move on. There is much lower gain to optimizing to avoid that specific mistake because the LLM still got to the right answer and, with infinite Servers/Tools, the LLM may never do that exact same flow again.
MCP affords a much more self-correcting and flexible system. To the extent there is an art to improving the LLM-Tool interaction, it lies in having the Server builder be thoughtful about how to name the tools and parameters and docstrings.
Enforcing schemas from the client actually makes the least important player (the Client) slightly better off by hamstringing the stars of the show (the LLM and the tool). The real answer, build your clients differently.