Hacker News Reader

Comment by SyneRyder | Hacker News Reader

> Most MCP servers still bloat up my context...

Modern harnesses don't do that, MCP is also progressive disclosure now. MCP tool descriptions aren't included anymore, and have to be found via tool_search. I actually find that to be a regression. Sometimes the models will start coding a python script for something that is already available via a pre-compiled MCP tool call.

In Claude Code you can enable / disable MCP servers at will, just use the /mcp command. You can also lock down permissions in claude -p headless mode to individual tools within an MCP server (eg maybe you only want to allow the reading tools, and none of the write-enabled tools for your automated session).

View on HN

> Modern harnesses don't do that, MCP is also progressive disclosure now.

Last time I checked, and it may be different now, Claude Code used tool search only if context usage was greater than 10%.

Also, even with tool search, MCP uses about 1000 to 3000 tokens. A skill frontmatter on the other hand can be around 50.

And an mcp tool call result gets dumped into context in its entirety. A cli too can be filtered with grep/sed etc.

Skills are just a lot more efficient for most use cases.

Skills and MCP can be treated by the harness in the exact same way. What do you think is unique to skills that does not apply to how MCP servers are managed?

> What do you think is unique to skills that does not apply to how MCP servers are managed?

I have a skill that describes my database schema with hundreds of tables, stored procedures, triggers at a high level. It tells the LLM to use a specific CLI to connect to the developer database using an account with read-only permissions. This skill has auto invocation turned off and uses zero tokens when not used.

MCP apps do not have a manual invocation option. If you enable them, they are always on, eating away tokens, even if you are not using them at all. And for my simple example above, would be a lot more work to setup. And once setup would eat way more tokens when compared to a small skill file that describes a CLI tool for querying the SQL database.

Output of an MCP tool call goes straight into context. Output of a CLI tool call can be filtered by the LLM using another tool, before it enters context.

These are meaningful differences and show that skills get the work done in an efficient manner, vast majority of the time.

MCP and skills complement each other, it’s not one vs the other.

> MCP apps do not have a manual invocation option. If you enable them, they are always on, eating away tokens

This is not true of recent harnesses. They will not consume any tokens until the LLM searches for tools. Similar to how they handle skills, and that’s my point: they can and do manage tools and skills similarly. They could easily let you invoke tools explicitly as well , it’s maybe their choice not to.

> Output of an MCP tool call goes straight into context. Output of a CLI tool call can be filtered by the LLM using another tool, before it enters context.

That’s a good point, but this is not about MCP , it’s about tools in general. Tools can provide structured output which should allow for even more advanced usages by the LLM than a text-based CLI approach. However I haven’t seen that done yet and it could be a nice feature to address!

Reply on news.ycombinator.com