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.
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
I think stateless-type MCP was already possible, eg my MCP Clock [ https://github.com/firasd/mcpclock ]: > curl -s -X POST "https://mcpclock.firasd.workers.dev/mcp" -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","id": 1,"method":"tools/call","params":{"name":"clock_get","arguments":{}}}' | grep '^data:' | sed 's/^data: //'| jq {"result": {"content": [{"type":…
The "CLI crowd" is also primarily using LLMs on their own computer. Where they have their CLI tools. This doesn't cover the case when you're talking to an LLM from web, or via Slack or Linear, etc. There, you will want MCP so the LLM can use services on your behalf as you. That's portability.
Even on your own machine with CLI tools , you really think it’s a great idea to let the LLM use the CLI as if it were you, with all permissions you have without any way to differentiate between actions you have manually taken and those that the LLM did?
I hope the answer is no and you sandbox the agent with its own permissions and user, but if you do that perhaps MCP does not look so bad anymore!?
In enterprise MCP allows users to access resources that could either be unsafe or impractical to consume via API or CLI. It is a powerful pattern, supported by virtually all clients (Cursor, Claude Code, Codex, whatever) and easily implemented in custom harnesses. If you don’t need it you don’t, but it has many useful applications. Stateless will make it a lot more practical to expand applications.
What is an example of something that is unsafe to consume via API or CLI? Isn't MCP _an API_?
Yes, MCP is an API.
Previously, it was an API with a weird stateful standard; now it is essentially a bog-standard stateless JSON-RPC API with conventions for tool discovery, long-running tasks and multi-round-trip requests
If you wrote your own JSON-RPC API for an LLM, you would probably eventually end up with something that looks very much like the standard they're describing.
The user experience for a rest api and for mcp can be the same. For MCP, you have to give the mcp server url. For REST, you could provide a url to the openapi spec. The open API spec has everything you'd need - oauth url + all the endpoints and params. Most chat products will just have a directory of connectors anyways - so for non technical folks they won't even here the term MCP or REST, they'll just "Install the G…
Yep. There's already a well-established system of `.well-known` URL paths to support things like API spec discover, auth discovery, etc. Why re-invent those wheels?
Because while an agent can indeed call a REST API directly using some other tool ( probably curl) what LLMs are good at is calling tools, and all MCP is doing is turning an API into a tool and standardizing authorization, which if you go the API route can be a nightmare as auth is not even mentioned in OpenAPI specs, usually, so the agent has to figure out how to do auth, and it will necessarily have access to your token and maybe even credentials, so it can easily leak it to attackers your agent happens to visit by just asking for it. I can’t believe anyone who has tried to give agents access to APIs in a sane manner hasn’t concluded that something on the lines of MCP is absolutely necessary.
> 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.
> 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 s…
> 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 g…
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?
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…
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.