Hacker News Reader

Comment by Eldodi | Hacker News Reader

MCP context bloat is a solved problem since at least February. Both OpenAI and Anthropic support Client-side MCP tool search, which makes MCP context loading as efficient as the Skills one (progressive discovery).

Code mode is great but not needed anymore in 95% of use-cases.

View on HN

I can turn off auto invocation of a skill. It uses zero tokens when in this mode. I can still invoke it by calling it by name. How can I do that with MCP servers?

You can't do that with tools either. Skills are basically prompts - they're not analogous to tools or MCPs. I'm not sure what your point is

you can actually invoke an MCP App by name in both Codex and Claude using the @ handle

> you can actually invoke an MCP App by name in both Codex and Claude using the @ handle

Even when it is disabled? The point is to have the skill or mcp app to not use ANY tokens until I call it by name. I can do that with a skill. Can I do that with an mcp app?

Use an MCP proxy.

What you're describing is a harness implementation detail not something specific to the MCP protocol or even how skills behave. Both of those are effectively providing the same level of information to the harness. Harnesses have traditionally (and still generally do) exposed enabled MCP servers and their actions ahead-of-time in the system prompt directly instead of doing progressive disclosure.

And ironically skills also need a double layer of progressive discovery because having too many skills available can also bloat the context even if only the short description is included. So instead of including hundreds of skills in the initial context a search tool is provided...

Interesting, then I wonder if Pi having Skills support but not MCP support by default still makes sense

Pi does support MCP through an excellent pi-mcp-adapter plugin.

Yes, I meant the decision to not support MCP by default without plugins, like Skills, could be revisited if it’s now efficient

I don't see a reason to support MCPs by default. Pi is so extensive and has such a rich plugin ecosystem that MCP support is just one "pi install npm:pi-mcp-adapter" away.

Or you may choose another plugin that works differently.

That's the whole point of extensible systems like Pi or Emacs, you don't need to pray that maintainers will have the same vision as you, you just pick one of the many alternatives instead. Or ask pi to write one for you.

Is it also a solved problem for smaller models, as the article mentioned?

it's not a question of model size, it's a question of your model API engineering. The initial problem was that the all tools schemas needed to be loaded in the model's initial system prompt, and changing the tools list in the middle of a session was busting the cache. Any model can now overcome that with a Tool Search tool implementation

Reply on news.ycombinator.com