Show HN: Mcptoon – Token-efficient MCP CLI client • Hacker News Board

Re: Show HN: Mcptoon – Token-efficient MCP CLI client

#11

Post by Loic » Tue, Aug 11, 2026, 6:37 AM UTC

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.

Re: Show HN: Mcptoon – Token-efficient MCP CLI client

#12

Post by alxhslm » Tue, Aug 11, 2026, 6:38 AM UTC

Don’t quite see the point of this. It is well known that MCP is a bit bloated for coding agents at least.

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

Re: Show HN: Mcptoon – Token-efficient MCP CLI client

#13

Post by debazel » Tue, Aug 11, 2026, 6:56 AM UTC

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...

Re: Show HN: Mcptoon – Token-efficient MCP CLI client

#14

Post by notpushkin » Tue, Aug 11, 2026, 6:57 AM UTC

Cool! Can we get a human-efficient MCP CLI while at it? I want to be able to use MCP just as well as the LLMs can.

Re: Show HN: Mcptoon – Token-efficient MCP CLI client

#15

Post by kepalabergetar3 » Tue, Aug 11, 2026, 7:03 AM UTC

[dead]

Re: Show HN: Mcptoon – Token-efficient MCP CLI client

#16

Post by AmazingTurtle » Tue, Aug 11, 2026, 7:05 AM UTC

debazel wrote: post #13

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...

↲ is also two tokens instead of a simple \n lmao

Re: Show HN: Mcptoon – Token-efficient MCP CLI client

#17

Post by kk3838368397373 » Tue, Aug 11, 2026, 7:10 AM UTC

sorry, is Headroom still a thing? What happened to it? Is anyone still using it? so many things , which one is actually working :/ idk this ai world

Re: Show HN: Mcptoon – Token-efficient MCP CLI client

#18

Post by stephantul » Tue, Aug 11, 2026, 7:28 AM UTC

I think that some of these choices (as others have commented) show that the author has not investigated how tokenization works.

Tokenization is not some black box, you can run tokenizers and check them.

Re: Show HN: Mcptoon – Token-efficient MCP CLI client

#19

Post by philipp-gayret » Tue, Aug 11, 2026, 7:29 AM UTC

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.

Re: Show HN: Mcptoon – Token-efficient MCP CLI client

#20

Post by vichle » Tue, Aug 11, 2026, 7:34 AM UTC

bobkinartem wrote: post #10

I thought Codex and Claude Code agents are already token-efficient so writing agents that saves tokens is pointless.

Are they though? Will they always be? Is it in their interest to be efficient?