Show HN: Mcptoon – Token-efficient MCP CLI client
41–50 of 51 posts
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#42Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#43Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#44search_web fetch_url
~~~
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#45Been experimenting with it in the OpenCode V2 beta and it's pretty great. The combination of tool search, call chaining and field projections feels just right and saves a lot of context. LLMs are good at writing code, who would have thought that?
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#46Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#47Q: is there a measurable difference compared to harnesses with tool search?
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#48Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#49I 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 nam…
Re: Show HN: Mcptoon – Token-efficient MCP CLI client
#50I like the idea, but this seems a little too aggressive, JSON (287 tokens) — what every other MCP client returns: ~~~ [ {"name": "search_web", "description": "Search the web for information", "inputSchema": {"type": "object", "properties": {"query": {"type": "string", "description": "Search query"}, "num_results": {"type": "number", "default": 5}}, "required": ["query"]}}, {"name": "fetch_url", "description": "Fetch…