I've cut token counts significantly for some of my MCP servers by returning csv or tabular data or sometimes even just good old fashioned plaintext "template style" words. JSON is highly repetitious. In some instances like 30% or more of the token response was just boilerplate JSON.
Once you realize that to an LLM JSON is just a stream of tokens no different than XML, markdown, or a punctuation-less stream of conciseness.... you start to realize there is no reason not to just make up your own crazy formats. The LLM isn't throw parsing errors if your MCP is returning something other than JSON. The LLM is smart enough to figure it out. It's far more important to make sure your tool descriptions and parameter descriptions properly "market" what it is you do (and dont do) than return syntactically correct JSON.
Same with versioning.... it's all ephemeral. There is no backwards compatibility to speak of with MCP (at least for tooling "contracts".... what the tool actually does however... that is a different level and is product requirements not API contracts).
alt Hacker News
> JSON is a bad format/transport.
I've cut token counts significantly for some of my MCP servers by returning csv or tabular data or sometimes even just good old fashioned plaintext "template style" words. JSON is highly repetitious. In some instances like 30% or more of the token response was just boilerplate JSON.
Once you realize that to an LLM JSON is just a stream of tokens no different than XML, markdown, or a punctuation-less stream of conciseness.... you start to realize there is no reason not to just make up your own crazy formats. The LLM isn't throw parsing errors if your MCP is returning something other than JSON. The LLM is smart enough to figure it out. It's far more important to make sure your tool descriptions and parameter descriptions properly "market" what it is you do (and dont do) than return syntactically correct JSON.
Same with versioning.... it's all ephemeral. There is no backwards compatibility to speak of with MCP (at least for tooling "contracts".... what the tool actually does however... that is a different level and is product requirements not API contracts).