Comment by rutierut | Hacker News Reader

Comment by rutierut | Hacker News Reader

In this thread I’m seeing a couple of the typical skill arguments. Skills don’t pollute the context window and, skills are more flexible and composable.

In this specific post the SQL example gets around this by being super low-level, inherently composable, and low context consumption itself. I’m not sure this works for everyone.

Looking at the Linear MCP for example, they basically just want to expose an API surface and provide 32 MCP tools as a result of that. My agents do run into composability problems here all the time and fall back to the tool they included which allows you to run arbitrary GraphQL. This takes a couple tries usually. I don’t really know what the sensible alternative to this is.

Cloudflare switched to “code mode” which basically provides 2 MCP tools: search and execute. Both take a TS arrow function, the first allows you to programmatically search a TS api spec, the second to compose and run the methods in that spec.

I think this is a very interesting approach, and certainly better than providing the ~1000 actions as MCP tools but I feel the jury is still out on exactly how well this pans out.

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.

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.

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

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.

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

Skills definitely can pollute the context window. They can be verbose. You can have a very long list of advertised skills. You can try and hack around with skill execution inside of subagents etc but there is always a trade-off.

> Skills don’t pollute the context window and, skills are more flexible and composable.

they do but more importantly model does not give a flying fuck about what you put in there in any consistent way.

ppl have been mislead by ai companies that they've invented some sort of agi that you can 'explain' to using skills. So ppl have come up with also sorts of skills that dont do jack shit.

It's still not really an either or scenario. Skills will always serve a purpose as high level on demand contextual guidance. I think of MCPS as hard tools, api contracts etc. While the initial release gave them the ability to be contextual sources as well, I think that's now better served with skills, and mcps can focus on being repositories of functionality.

Skills and tools all need their contextual descriptions to be evolved using evals in order to be effective and efficient. Sounds like the Liner MCP could use with some of that.

For an MCP used to look up data in any kind of dataset, just having a single tool that accepts an OData Query string has worked well for me.

> Skills don’t pollute the context window

Of course they do. Do you really think that there's a magical bag of holding for the potentially infinite amount of skills?

Skills don’t need to be preloaded, can be invoked by name on demand; and when you list available skills, a one-line description for each is enough.

And all those "names and one-line descriptions" live in an .md file and of course pollute your context.

And then the model will randomly decide to load the .md file that is the "skill" randomly at any point. Again polluting the context.

There's no magic.

Most people seem to mean "Skills don't pollute the context window [with their entire contents]", they just elide the part in brackets.

There is no magic and people should be more precise when discussing skills.

Yes, but I expect that the elided part is less important than people assume it is.

Token count is a less important factor in context pollution than idea count. The worst of the rot factors are when models latch onto irrelevant information, or over-index on some vague idea/suggestion as if it was a hard direction, and then go off course.

The names + one-line descriptions of 10 tools can do as much (or more!) to distract the focus and intentionality of an agent than a 30k token exhaustive API documentation of some tool.

I've seen implementations of a skill search, where instead of loading all descriptions into the initial prompt there's a tool the agent can call to search available skills and see if one might match their new task.

Search itself pollutes the context. With the need to maintain the tools, the search, the search results etc. in context. And wasting tokens while interpreting results.

Is it so unusual to just ... not ... load the file with a description of them all automatically, but have different files listing different ones for different situations, and manually point to them in prompts?

Depends on how the harness injects those files. All harnesses these days auto-discover "skills" and read them anyway, and inject their descriptions, at the very least. Which leads to this anyway: https://news.ycombinator.com/item?id=49183906

But yeah. You could have files with skills outside of the auto-discovered skill tree, and invoke them manually.

Reply on news.ycombinator.com