3 ms·

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 thi

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.

Eldodi 2mo ago
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.
- cheema33 2mo ago
  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?
  - Eldodi 2mo ago
    you can actually invoke an MCP App by name in both Codex and Claude using the @ handle
    - cheema33 2mo ago
      > 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?
      - deleted 2mo ago
        [deleted]
  - afro88 2mo ago
    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
    - cheema33 2mo ago
      [dead]
  - block_dagger 2mo ago
    Use an MCP proxy.
  - TrueDuality 2mo ago
    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.
- msdz 2mo ago
  Is it also a solved problem for smaller models, as the article mentioned?
  - Eldodi 2mo ago
    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
- deleted 2mo ago
  [deleted]
- mi_lk 2mo ago
  Interesting, then I wonder if Pi having Skills support but not MCP support by default still makes sense
  - miroljub 2mo ago
    Pi does support MCP through an excellent pi-mcp-adapter plugin.
    - mi_lk 2mo ago
      Yes, I meant the decision to not support MCP by default without plugins, like Skills, could be revisited if it’s now efficient
      - miroljub 2mo ago
        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.
- Ferret7446 2mo ago
  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...
troupo 2mo ago
> 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?
- ricardobeat 2mo ago
  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.
  - troupo 2mo ago
    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.
    - CrompyBlompers 2mo ago
      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.
      - NiloCK 2mo ago
        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.
    - simonw 2mo ago
      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.
ra 2mo ago
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.
codebolt 2mo ago
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.
alansaber 2mo ago
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.
dominotw 2mo ago
> 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.
smrtinsert 2mo ago
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.

Eldodi 2mo ago

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.

cheema33 2mo ago
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?
- Eldodi 2mo ago
  you can actually invoke an MCP App by name in both Codex and Claude using the @ handle
  - cheema33 2mo ago
    > 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?
    - deleted 2mo ago
      [deleted]
- afro88 2mo ago
  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
  - cheema33 2mo ago
    [dead]
- block_dagger 2mo ago
  Use an MCP proxy.
- TrueDuality 2mo ago
  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.
msdz 2mo ago
Is it also a solved problem for smaller models, as the article mentioned?
- Eldodi 2mo ago
  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
deleted 2mo ago
[deleted]
mi_lk 2mo ago
Interesting, then I wonder if Pi having Skills support but not MCP support by default still makes sense
- miroljub 2mo ago
  Pi does support MCP through an excellent pi-mcp-adapter plugin.
  - mi_lk 2mo ago
    Yes, I meant the decision to not support MCP by default without plugins, like Skills, could be revisited if it’s now efficient
    - miroljub 2mo ago
      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.
Ferret7446 2mo ago
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...

troupo 2mo ago

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

ricardobeat 2mo ago
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.
- troupo 2mo ago
  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.
  - CrompyBlompers 2mo ago
    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.
    - NiloCK 2mo ago
      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.
  - simonw 2mo ago
    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.

ra 2mo ago

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.

codebolt 2mo ago

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.

alansaber 2mo ago

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.

dominotw 2mo ago

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

smrtinsert 2mo ago

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.