Live data from Hacker News

Show HN: Mcptoon – Token-efficient MCP CLI client

github.com

31–40 of 50 posts

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

#31
post #4

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?

Isn't there value to the verbose information too? Knowing what a tool does and what the inputs are increase the likelyhood of successful tool calls.

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

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

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

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

#33
post #23
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...

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.

And they need some kind of downvote. Projects needs to be able to lose a star.

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

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

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

Oh it is not returning full tool schema. You can't cut down that much by serialisation alone.

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

#37
post #24

Earlier quoted context omitted.

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

How is an LF two tokens? Or were you referring to the Unicode symbol? I took their example to mean an actual LF ASCII character but now Ive read your comment, maybe I was being too charitable?

They literally replace \n with the unicode symbol

https://github.com/activeing123/mcptoon/blob/main/src/mcptoo...

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

#39

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

I’m going to start using “donkey clanker”.

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

#40
post #24

Earlier quoted context omitted.

How is an LF two tokens? Or were you referring to the Unicode symbol? I took their example to mean an actual LF ASCII character but now Ive read your comment, maybe I was being too charitable?

They literally replace \n with the unicode symbol https://github.com/activeing123/mcptoon/blob/main/src/mcptoo...

Wow. Just “wow”.
Post reply on HN