I'm getting tired of everyone saying "MCP is dead, use CLIs!".
Yes, MCP eats up context windows, but agents can also be smarter about how they load the MCP context in the first place, using similar strategy to skills.
The problem with tossing it out entirely is that it leaves a lot more questions for handling security.
When using skills, there's no implicit way to be able to apply policies in the sane way across many different servers.
MCP gives us a registry such that we can enforce MCP chain policies, i.e. no doing web search after viewing financials.
Doing the same with skills is not possible in a programatic and deterministic way.
There needs to be a middle ground instead of throwing out MCP entirely.
It is a weird trend. I see the appeal of Skills over MCP when you are just a solo dev doing your work. MCP is incredibly useful in an organization context when you need to add controls and process. Both are useful. I feel like the anti-MCP push is coming from people who don't need to work in a large org.
Isn’t it possible to proxy LLM communication and strip out unwanted MCP tool calls from conversations? I mean if you’re going to ban MCPs, you’re probably banning any CLI tooling too, right?
> I feel like the anti-MCP push is coming from people who don't need to work in a large org.
Any kind of social push like that is always understood to be something to ignore if you understand why you need to ignore it. Do you agree that a typical solo dev caught in the MCP hype should run the other way, even if it is beneficial to your unique situation?
Skills are just prompts, so policy doesn't apply there. MCP isn't giving you any special policy control there, it's just a capability border. You could do the same thing with a service mesh or any other capability compartmentalization technique.
The only value in MCP is that it's intended "for agents" and it has traction.
> Yes, MCP eats up context windows, but agents can also be smarter about how they load the MCP context in the first place, using similar strategy to skills.
I have been keeping an eye on MCP context usage with Claude Code's /context command.
When I ran it a couple months ago, supabase used 13.2k tokens all the time, with the search_docs tool using 8k! So, I disabled that tool in my config.
I just ran /context now, and when not being used it uses only ~300 tokens.
I have a question. Does anyone know a good way to benchmark actual MCP context usage in Claude Code now? I just tried a few different things and none of them worked.
I agree, and it's context-dependent when to use what (the author mentions use cases for other solutions). I'm glad there are multiple solutions to choose from.
The real issue isn't MCP vs Skills/CLIs, it's that most MCP servers dump their entire schema into context on init regardless of whether you'll actually use those tools. Lazy loading tool definitions based on what the agent is actually doing would solve like 80% of the bloat problem without throwing out the protocol entirely.
The security/registry point in the thread is underrated too. Being able to enforce policies at the protocol level is something you lose completely with ad hoc skill files.
This matches my experience building in-house MCP servers. The mechanism I prefer on load is something like a quick FTS5 with BM25 ranking lookup to find what it needs, and then serve those. I think a lot of these things are implemented pretty naively - for instance, we ran into the huge context problem with Jira, so we just built our own Jira MCP interface that doesn't have all the bloat. If the agent finds it needs something it doesnt have, it can ask again.
Measurable responses to the environment lag, Moore's law has been slowing down (e: and demand has been speeding up, a lot).
From just a sustainability point, I really hope that the parent post's quote is true, because otherwise I've personally seen LLMs used over and over to complete the same task that it could have been used for once to generate a script, and I'd really like to be able to still afford to own my own hardware at home.
10 years from now: "The next big thing: HENG - Human Engineers! These make mistakes, but when they do, they can just learn from it and move on and never make it again! It's like magic! Almost as smart as GPT-63.3-Fast-Xtra-Ultra-Google23-v2-Mem-Quantum"
I've always wanted a better way to test programmers' debugging in an interview setting. Like, sometimes just working problems gets at it, but usually just the "can you re-read your own code and spot a mistake" sort of debugging.
Which is not nothing, and I'm not sure how LLMs do on that style; I'd expect them to be able to fake it well enough on common mistakes in common idioms, which might get you pretty far, and fall flat on novel code.
The kind of debugging that makes me feel cool is when I see or am told about a novel failure in a large program, and my mental model of the system is good enough that this immediately "unlocks" a new understanding of a corner case I hadn't previously considered. "Ah, yes, if this is happening it means that precondition must be false, and we need to change a line of code in a particular file just so." And when it happens and I get it right, there's no better feeling.
Of course, half the time it turns out I'm wrong, and I resort to some combination of printf debugging (to improve my understanding of the code) and "making random changes", where I take swing-and-a-miss after swing-and-a-miss changing things I think could be the problem and testing to see if it works.
And that last thing? I kind of feel like it's all LLMs do when you tell them the code is broken and ask then to fix it. They'll rewrite it, tell you it's fixed and ... maybe it is? It never understands the problem to fix it.
I am kind of already at that point. For all the complaining about context windows being stuffed with MCPs, I am curious what they are up to and how many MCPs they have that this is a problem.
One of the MCP Core Maintainers here, so take this with a boulder of salt if you're skeptical of my biases.
The debate around "MCP vs. CLI" is somewhat pointless to me personally. Use whatever gets the job done. MCP is much more than just tool calling - it also happens to provide a set of consistent rails for an agent to follow. Besides, we as developers often forget that the things we build are also consumed by non-technical folks - I have no desire to teach my parents to install random CLIs to get things done instead of plugging a URI to a hosted MCP server with a well-defined impact radius. The entire security posture of "Install this CLI with access to everything on your box" terrifies me.
The context window argument is also an agent harness challenge more than anything else - modern MCP clients do smart tool search that obviates the entire "I am sending the full list of tools back and forth" mode of operation. At this point it's just a trope that is repeated from blog post to blog post. This blog post too alludes to this and talks about the need for infrastructure to make it work, but it just isn't the case. It's a pattern that's being adopted broadly as we speak.
CLIs are great for some applications! But 'progressive disclosure' means more mistakes to be corrected and more round trips to the model - every time[1] you use the tool in a new thread. You're trading latency for lower cost/more free context. That might be great! But it might not be, and the opposite trade (more money/less context for lower latency) makes a lot of sense for some applications. esp. if the 'more money' part can be amortized over lots of users by keeping the tool definitions block cached.
[1]: one might say 'of course you can just add details about the CLI to the prompt' ... which reinvents MCP in an ad hoc underspecified non-portable mode in your prompt.
This is a fair trade-off and the post should probably be more explicit about it. You're right that progressive disclosure trades latency for cost and context space. For some workloads that's the wrong trade.
The amortization point is interesting too. If you're running a support agent that calls the same 5 tools thousands of times a day, paying the schema cost once and caching it makes total sense. The post covers this in the "tightly scoped, high-frequency tools" section but your framing of it as a caching problem is cleaner.
On the footnote: guilty as charged, partially. The ~80 token prompt is a minimal bootstrap, not a full schema. It tells the agent how to discover, not what to call. But yeah, the moment you start expanding that prompt with specific flags and patterns, you're drifting toward a hand-rolled tool definition. The difference is where you stop. 80 tokens of "here's how to explore" is different from 10,000 tokens of "here's everything you might ever need." But the line between the two is blurrier than the post implies. Fair point.
The industry is talking in circles here. All you need is "composability".
UNIX solved this with files and pipes for data, and processes for compute.
AI agents are solving this this with sub-agents for data, and "code execution" for compute.
The UNIX approach is both technically correct and elegant, and what I strongly favor too.
The agent + MCP approach is getting there. But not every harness has sub-agents, or their invocation is non-deterministic, which is where "MCP context bloat" happens.
Fair point on tool search. Claude Code and Codex do have it.
But tool search is solving the symptom, not the cause. You still pay the per-tool token cost for every tool the search returns. And you've added a search step (with its own latency and token cost) before every tool call.
With a CLI, the agent runs `--help` and gets 50-200 tokens of exactly what it needs. No search index, no ranking, no middleware. The binary is the registry.
Tool search makes MCP workable. CLIs make the search unnecessary.
Those bigger windows come with lovely surcharges on compute, latency, and prompt complexity, so "just wait for more tokens" is a nice fantasy that melts the moment someone has to pay the bill. If your use case is tiny or your budget is infinite, fine, but for everyone else the "make the window bigger" crowd sounds like they're budgeting by credit card. Quality still falls off near the edge.
Context windows getting bigger doesn't make the economics go away. Tokens still cost money. 50K tokens of schemas at 1M context is the same dollar cost as 50K tokens at 200K context, you just have more room left over.
The pattern with every resource expansion is the same: usage scales to fill it. Bigger windows mean more integrations connected, not leaner ones. Progressive disclosure is cheaper at any window size.
It helps with cost, agreed. But caching doesn't fix the other two problems.
1) Models get worse at reasoning as context fills up, cached or not. right?
2) Usage expansion problem still holds. Cheaper context means teams connect more services, not fewer. You cache 50K tokens of schemas today, then it's 200K tomorrow because you can "afford" it now. The bloat scales with the budget...
Caching makes MCP more viable. It doesn't make loading 43 tool definitions for a task that uses two of them a good architecture.
We built a unified API with a large surface area and ran into a problem when building our MCP server: tool definitions alone burned 50,000+ tokens before the agent touched a single user message.
The fix that worked for us was giving agents a CLI instead. ~80 tokens in the system prompt, progressive discovery through --help, and permission enforcement baked into the binary rather than prompts.
The post covers the benchmarks (Scalekit's 75-run comparison showed 4-32x token overhead for MCP vs CLI), the architecture, and an honest section on where CLIs fall short (streaming, delegated auth, distribution).
I'm getting tired of everyone saying "MCP is dead, use CLIs!".
Yes, MCP eats up context windows, but agents can also be smarter about how they load the MCP context in the first place, using similar strategy to skills.
The problem with tossing it out entirely is that it leaves a lot more questions for handling security.
When using skills, there's no implicit way to be able to apply policies in the sane way across many different servers.
MCP gives us a registry such that we can enforce MCP chain policies, i.e. no doing web search after viewing financials.
Doing the same with skills is not possible in a programatic and deterministic way.
There needs to be a middle ground instead of throwing out MCP entirely.
It is a weird trend. I see the appeal of Skills over MCP when you are just a solo dev doing your work. MCP is incredibly useful in an organization context when you need to add controls and process. Both are useful. I feel like the anti-MCP push is coming from people who don't need to work in a large org.
Not sure. Our big org, banned MCPs because they are unsafe, and they have no way to enforce only certain MCPs (in github copilot).
Isn’t it possible to proxy LLM communication and strip out unwanted MCP tool calls from conversations? I mean if you’re going to ban MCPs, you’re probably banning any CLI tooling too, right?
But skills where you tell the LLM to shell out to some random command are safe? I'm not sure I understand the logic.
You can control an execution context in a superior manner than a rando MCP server.
MCP Security 2026: 30 CVEs in 60 Days - https://news.ycombinator.com/item?id=47356600 - March 2026
(securing this use case is a component of my work in a regulated industry and enterprise)
We only allow custom MCP servers.
> I feel like the anti-MCP push is coming from people who don't need to work in a large org.
Any kind of social push like that is always understood to be something to ignore if you understand why you need to ignore it. Do you agree that a typical solo dev caught in the MCP hype should run the other way, even if it is beneficial to your unique situation?
Id agree solo devs can lean toward skills. I liken skills to a sort of bash scripts directory. And for personal stuff I generally use skills only.
Skills are just prompts, so policy doesn't apply there. MCP isn't giving you any special policy control there, it's just a capability border. You could do the same thing with a service mesh or any other capability compartmentalization technique.
The only value in MCP is that it's intended "for agents" and it has traction.
> Yes, MCP eats up context windows, but agents can also be smarter about how they load the MCP context in the first place, using similar strategy to skills.
I have been keeping an eye on MCP context usage with Claude Code's /context command.
When I ran it a couple months ago, supabase used 13.2k tokens all the time, with the search_docs tool using 8k! So, I disabled that tool in my config.
I just ran /context now, and when not being used it uses only ~300 tokens.
I have a question. Does anyone know a good way to benchmark actual MCP context usage in Claude Code now? I just tried a few different things and none of them worked.
Towards the end of the article, they do write about some things that MCP does better.
Tool search pretty much completely negates the MCP context window argument.
I agree, and it's context-dependent when to use what (the author mentions use cases for other solutions). I'm glad there are multiple solutions to choose from.
MCPs are handy in their place. Agents calling CLI locally is much more efficient.
https://github.com/RhysSullivan/executor
The real issue isn't MCP vs Skills/CLIs, it's that most MCP servers dump their entire schema into context on init regardless of whether you'll actually use those tools. Lazy loading tool definitions based on what the agent is actually doing would solve like 80% of the bloat problem without throwing out the protocol entirely.
The security/registry point in the thread is underrated too. Being able to enforce policies at the protocol level is something you lose completely with ad hoc skill files.
The real issue isn't MCP, it's these fucking bots posting here every day.
This matches my experience building in-house MCP servers. The mechanism I prefer on load is something like a quick FTS5 with BM25 ranking lookup to find what it needs, and then serve those. I think a lot of these things are implemented pretty naively - for instance, we ran into the huge context problem with Jira, so we just built our own Jira MCP interface that doesn't have all the bloat. If the agent finds it needs something it doesnt have, it can ask again.
This is becoming a solved problem with tool search; MCP is back.
10 years from now: "Can you believe they did anything with such a small context window?"
More likely: "Can you believe they were actually trying to use LLMs for this?"
OSes and software engs did not end up using less RAM.
Measurable responses to the environment lag, Moore's law has been slowing down (e: and demand has been speeding up, a lot).
From just a sustainability point, I really hope that the parent post's quote is true, because otherwise I've personally seen LLMs used over and over to complete the same task that it could have been used for once to generate a script, and I'd really like to be able to still afford to own my own hardware at home.
10 years from now: "The next big thing: HENG - Human Engineers! These make mistakes, but when they do, they can just learn from it and move on and never make it again! It's like magic! Almost as smart as GPT-63.3-Fast-Xtra-Ultra-Google23-v2-Mem-Quantum"
Imagine believing humans don’t make the same mistakes. You live in a different universe than me buddy.
Sometimes we repeat mistakes. But humans are capable of occasionally learning. I've seen it!
I've always wanted a better way to test programmers' debugging in an interview setting. Like, sometimes just working problems gets at it, but usually just the "can you re-read your own code and spot a mistake" sort of debugging.
Which is not nothing, and I'm not sure how LLMs do on that style; I'd expect them to be able to fake it well enough on common mistakes in common idioms, which might get you pretty far, and fall flat on novel code.
The kind of debugging that makes me feel cool is when I see or am told about a novel failure in a large program, and my mental model of the system is good enough that this immediately "unlocks" a new understanding of a corner case I hadn't previously considered. "Ah, yes, if this is happening it means that precondition must be false, and we need to change a line of code in a particular file just so." And when it happens and I get it right, there's no better feeling.
Of course, half the time it turns out I'm wrong, and I resort to some combination of printf debugging (to improve my understanding of the code) and "making random changes", where I take swing-and-a-miss after swing-and-a-miss changing things I think could be the problem and testing to see if it works.
And that last thing? I kind of feel like it's all LLMs do when you tell them the code is broken and ask then to fix it. They'll rewrite it, tell you it's fixed and ... maybe it is? It never understands the problem to fix it.
I mean, that is not what they are writing buddy.
10 years from now: “what’s a context window?”
10 years from now: “come with me if you want to live”
Terminator 2 Clip: https://youtu.be/XTzTkRU6mRY?t=72&si=dmfLNDqpDZosSP4M
I am kind of already at that point. For all the complaining about context windows being stuffed with MCPs, I am curious what they are up to and how many MCPs they have that this is a problem.
"That was back when models were so slow and weighty they had to use cloud based versions. Now the same LLM power is available in my microwave"
“640K ought to be enough for anybody”
I dunno why you're getting down voted. This is funny.
One of the MCP Core Maintainers here, so take this with a boulder of salt if you're skeptical of my biases.
The debate around "MCP vs. CLI" is somewhat pointless to me personally. Use whatever gets the job done. MCP is much more than just tool calling - it also happens to provide a set of consistent rails for an agent to follow. Besides, we as developers often forget that the things we build are also consumed by non-technical folks - I have no desire to teach my parents to install random CLIs to get things done instead of plugging a URI to a hosted MCP server with a well-defined impact radius. The entire security posture of "Install this CLI with access to everything on your box" terrifies me.
The context window argument is also an agent harness challenge more than anything else - modern MCP clients do smart tool search that obviates the entire "I am sending the full list of tools back and forth" mode of operation. At this point it's just a trope that is repeated from blog post to blog post. This blog post too alludes to this and talks about the need for infrastructure to make it work, but it just isn't the case. It's a pattern that's being adopted broadly as we speak.
> modern MCP clients do smart tool search that obviates the entire "I am sending the full list of tools back and forth" mode of operation
How, "Dynamic Tool Discovery"? Has this been codified anywhere? I've only see somewhat hacky implementations of this idea
https://github.com/modelcontextprotocol/modelcontextprotocol...
Or are you talking about the pressure being on the client/harnesses as in,
https://platform.claude.com/docs/en/agents-and-tools/tool-us...
CLIs are great for some applications! But 'progressive disclosure' means more mistakes to be corrected and more round trips to the model - every time[1] you use the tool in a new thread. You're trading latency for lower cost/more free context. That might be great! But it might not be, and the opposite trade (more money/less context for lower latency) makes a lot of sense for some applications. esp. if the 'more money' part can be amortized over lots of users by keeping the tool definitions block cached.
[1]: one might say 'of course you can just add details about the CLI to the prompt' ... which reinvents MCP in an ad hoc underspecified non-portable mode in your prompt.
This is a fair trade-off and the post should probably be more explicit about it. You're right that progressive disclosure trades latency for cost and context space. For some workloads that's the wrong trade.
The amortization point is interesting too. If you're running a support agent that calls the same 5 tools thousands of times a day, paying the schema cost once and caching it makes total sense. The post covers this in the "tightly scoped, high-frequency tools" section but your framing of it as a caching problem is cleaner.
On the footnote: guilty as charged, partially. The ~80 token prompt is a minimal bootstrap, not a full schema. It tells the agent how to discover, not what to call. But yeah, the moment you start expanding that prompt with specific flags and patterns, you're drifting toward a hand-rolled tool definition. The difference is where you stop. 80 tokens of "here's how to explore" is different from 10,000 tokens of "here's everything you might ever need." But the line between the two is blurrier than the post implies. Fair point.
The industry is talking in circles here. All you need is "composability".
UNIX solved this with files and pipes for data, and processes for compute.
AI agents are solving this this with sub-agents for data, and "code execution" for compute.
The UNIX approach is both technically correct and elegant, and what I strongly favor too.
The agent + MCP approach is getting there. But not every harness has sub-agents, or their invocation is non-deterministic, which is where "MCP context bloat" happens.
Source: building an small business agent at https://housecat.com/.
We do have APIs wrapped in MCP. But we only give the agent BASH, an CLI wrapper for the MCPs, and the ability to write code, and works great.
"It's a UNIX system! I know this!"
Getting LLMs to reliably trigger CLI functions is quite hard in my experience though especially if it’s a custom tool
While I generally prefer CLI over MCP locally, this is bad outdated information.
The major harnesses like Claude Code + Codex have had tool search for months now.
Can you explain how to take advantage. Is there any specific info from anthropic with regards to context window size and not having to care about MCP?
Fair point on tool search. Claude Code and Codex do have it.
But tool search is solving the symptom, not the cause. You still pay the per-tool token cost for every tool the search returns. And you've added a search step (with its own latency and token cost) before every tool call.
With a CLI, the agent runs `--help` and gets 50-200 tokens of exactly what it needs. No search index, no ranking, no middleware. The binary is the registry.
Tool search makes MCP workable. CLIs make the search unnecessary.
There's already an open source tool that does exactly the same thing: https://github.com/knowsuchagency/mcp2cli
Great tool, however we went to a dedicated CLI client (think gh, aws, stripe) in Go.
The trend is obviously towards larger and larger context windows. We moved from 200K to 1M tokens being standard just this year.
This might be a complete non issue in 6 months.
Those bigger windows come with lovely surcharges on compute, latency, and prompt complexity, so "just wait for more tokens" is a nice fantasy that melts the moment someone has to pay the bill. If your use case is tiny or your budget is infinite, fine, but for everyone else the "make the window bigger" crowd sounds like they're budgeting by credit card. Quality still falls off near the edge.
Context windows getting bigger doesn't make the economics go away. Tokens still cost money. 50K tokens of schemas at 1M context is the same dollar cost as 50K tokens at 200K context, you just have more room left over.
The pattern with every resource expansion is the same: usage scales to fill it. Bigger windows mean more integrations connected, not leaner ones. Progressive disclosure is cheaper at any window size.
Context caching deals with a lot of the cost argument here.
It helps with cost, agreed. But caching doesn't fix the other two problems.
1) Models get worse at reasoning as context fills up, cached or not. right? 2) Usage expansion problem still holds. Cheaper context means teams connect more services, not fewer. You cache 50K tokens of schemas today, then it's 200K tomorrow because you can "afford" it now. The bloat scales with the budget...
Caching makes MCP more viable. It doesn't make loading 43 tool definitions for a task that uses two of them a good architecture.
We built a unified API with a large surface area and ran into a problem when building our MCP server: tool definitions alone burned 50,000+ tokens before the agent touched a single user message.
The fix that worked for us was giving agents a CLI instead. ~80 tokens in the system prompt, progressive discovery through --help, and permission enforcement baked into the binary rather than prompts.
The post covers the benchmarks (Scalekit's 75-run comparison showed 4-32x token overhead for MCP vs CLI), the architecture, and an honest section on where CLIs fall short (streaming, delegated auth, distribution).
With context windows starting to get much larger (see the recent 1M context size for Claude models), I think this will be a non-issue very soon.
The thing with CLIs is that you also need to return results efficiently. It if both MCP and CLI return results efficiently, CLI wins
Let me guess - another article about how CLI s are superior to MCP?
At this point, I feel like MCP servers are just not feasible at the current level of context windows and LLMs. Good idea, but we're way too early.