Why is it replacing true/false with T/F? true/false is already 1 token in all tokenizer I've seen. Even worse is replacing null with ∅. ∅ is a special unicode symbol that takes up 2 tokens compared to the 1 token for null...
Maybe they want to be tokenizer agnostic? Then they would need to go by character count, right? Despite these inconsistencies, has anyone actually verified their promise? 350 vs. 10.000 tokens would still be very valuable even if they mess up some edge cases
Brand new GitHub account, brand new HN account. I stay far away from projects like this these days, they can easily be malicious. GitHub needs some kind of indicator for projects authored by tenured developers with a real identity.
I don’t think the Show Me section makes sense, the TOON variant clearly doesn’t have the same information. And the examples in the “How TOON works” section focuses on number of characters instead of tokens. I would think “null” is a single token anyway, why bother replacing it with an uncommon character?
I spent more than one week, as a side project, to add an MCP server to my Cheméo website. Only 4 tools.
It took me way more time than expected, I was thinking: "Just wrap the REST API, 2h, done".
The MCP payload has nothing to do with the REST API one. Because you need to make it interpretable and context efficient even so it is structured data.
It was really interesting work and I suppose very little people are taking the time to rethink what is sent over the wire while creating a MCP server. If so, we would not have MCPs with the minimal payload being 500kB of JSON soup.
If you send my MCP through your "save token filter", I can guarantee you, that you will have trash down the line.
Yeah this is why a code execution sandbox so the ai can batch calls and select from the response format what it wants and limit the number of responses with instruction to be concise and preserve its context is a really cool thing to do.
OP, I'm very interested in seeing an actual comparison ran through a common tokenizer of tool calls. I think you'll find different results than what you intended for this tool to be. You've mixed up tokens with characters on your screen.
I made an MCP proxy with a similar idea in the past: replace a ton of tools that consume tokens with just two (get_tool_schema, invoke_tool) - https://github.com/ameshkov/mcp-compress-router
One thing that I noticed is that it’s often better to return tool names with argument names, i.e. return “search_web(query)” instead of just “search_web” when listing tools. Otherwise models often tend to hallucinate argument names and an extra turn is required to correct the mistake.
One additional advantage that such tools provide is that when you use different coding agents you don’t have to set up all the MCP servers in every agent, you just set up one (or point the agent to the cli like in this project).
You're just returning the name of the tool, the rest of the information (description/input schema) is definitely lost. Cut to the LLM making mistakes in calling the tool with incorrect schema or calling the wrong tools altogether, recovering, wasting tokens and cycles.
I am not going to trust a single number thrown by these AI hustlers written in that salesman voice.
Leave alone 97%.
> Your agent calls 20 tools. Each returns 500-3,000 tokens wrapped in {"content":[{"type":"text","text":"..."}]}.
This is a problem with your tool design. Most MCPs are fully vibe coded without any thought about tool selection.
> On a 128K context window, that's 30-55% gone. Not on work. On syntax.
Tool output is not "syntax" you donkey clanker.
Again, use the code approach, let the LLM filter out the JSON using tools. This TOON thing is just vibes. Most of the time your tool output should not even be JSON. It should be well formatted markdown. In cases where it's large structured data, your LLM should have tools (code / jq) to dissect it. So TOON is pointless.
How does it work? Im building a video editor and right now it has access to nearly 100 tools. Would be good to learn the techniques you used to make tool discovery more efficient.
The readme has some examples for what it does. It doesn’t list the entire schema (noisy). Instead it uses shorthand. Perhaps a sufficiently smart agent can do this.
I really doubt that null and \n make any sense to replace with non ascii symbols. They are both most likely already a token only and for other purposes at least \n becomes larger as a symbol.
I took their example to mean an actual LF ASCII character but now Ive read your comment, maybe I was being too charitable?
https://github.com/activeing123/mcptoon/blob/main/src/mcptoo...
It took me way more time than expected, I was thinking: "Just wrap the REST API, 2h, done".
The MCP payload has nothing to do with the REST API one. Because you need to make it interpretable and context efficient even so it is structured data.
It was really interesting work and I suppose very little people are taking the time to rethink what is sent over the wire while creating a MCP server. If so, we would not have MCPs with the minimal payload being 500kB of JSON soup.
If you send my MCP through your "save token filter", I can guarantee you, that you will have trash down the line.
People want a token efficient MCP CLI client. Whether this actually is one is less relevant.
One thing that I noticed is that it’s often better to return tool names with argument names, i.e. return “search_web(query)” instead of just “search_web” when listing tools. Otherwise models often tend to hallucinate argument names and an extra turn is required to correct the mistake.
One additional advantage that such tools provide is that when you use different coding agents you don’t have to set up all the MCP servers in every agent, you just set up one (or point the agent to the cli like in this project).
Tokenization is not some black box, you can run tokenizers and check them.
You're just returning the name of the tool, the rest of the information (description/input schema) is definitely lost. Cut to the LLM making mistakes in calling the tool with incorrect schema or calling the wrong tools altogether, recovering, wasting tokens and cycles.
Leave alone 97%.
> Your agent calls 20 tools. Each returns 500-3,000 tokens wrapped in {"content":[{"type":"text","text":"..."}]}.
This is a problem with your tool design. Most MCPs are fully vibe coded without any thought about tool selection.
> On a 128K context window, that's 30-55% gone. Not on work. On syntax.
Tool output is not "syntax" you donkey clanker.
Again, use the code approach, let the LLM filter out the JSON using tools. This TOON thing is just vibes. Most of the time your tool output should not even be JSON. It should be well formatted markdown. In cases where it's large structured data, your LLM should have tools (code / jq) to dissect it. So TOON is pointless.
But, why not just use CLIs for each tool? That seems to be where things are going anyway
And using MCP as an internal communication method seems odd when you could use the APIs directly