Show HN: Mcptoon – Token-efficient MCP CLI client
1–10 of 50 posts
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#2How 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.
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#3How 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.
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#4I 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?
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#5I 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.
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#6Sorry, isnt this just compression? Lookups burn tokens just on the other end?
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#7I 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.
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#8Sorry, isnt this just compression? Lookups burn tokens just on the other end?
I really think we’ve missed a trick using JSON instead of SExpressions as the default marshaller for AI tool use.
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#9I 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).
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#10I thought Codex and Claude Code agents are already token-efficient so writing agents that saves tokens is pointless.