is this post old? MCP context poisoning was fixed like months ago

i personally was anti-MCP but they just work better in terms of tool search than a CLI, especially with the idea of tool nudging

I've thought that skills and small scripts > MCP for quite a while now, tried out MCP in the early days (official ones, ones i made for scripts i already had), but they always end up using more tool calls/tokens than if i had just written a script + skill for claude.

I'll kick myself for not remembering, but there was a fantastic article which suggested that MCP works at org level when unified, safe, access to internal utility APIs need to be given to non-technical staff who do use internal agent tools. Codify your workflow(s) via skills and share across instances, anything that needs context aware API access should be mcp...

These AI slop articles about AI are getting especially boring to read.

> Problem 1: It Devours the Context Window

Don't harnesses support progressive discovery these days?

Claude (200K).... GPT-4o..........?

> every MCP server adds a process layer between the LLM and the underlying API

But a CLI doesn't?

------------------

> Measurement: Tool Definition Sizes

> MCP Server: Linear, Notion, Slack, Postgres

Oh, so these are the MCP servers that are examples of context bloat we're going to replace! Later in the article:

> At Quandri we use all three approaches side by side...

> MCP for services without a strong CLI (Slack, Linear, Notion)

So what's this saying? Rather than trust the llm to query external tools via mcp you should handle the external queries yourself? Otherwise the llm wastes a bunch of queries?

My mental model for MCPs is that it's like a Swagger/OpenAPI spec for LLMs. Point 2 doesn't make much sense in that context as it's describing MCP as a Swagger endpoint that's unstable.

Chrome/Ghidra MCP does have a tendency of crashing, but I'm not sure why this is. Is my way of thinking of MCP incorrect? If it really is a descriptor of how to talk to another tool, then why do they seem fragile at times? I feel like there's a gap in my knowledge somewhere.

I think those are solvable problems. E.g. wrap mcp in skill or seperate forked (non context eating) call to smaller model to ask which mcps are applicable. Iet probably does this. Honestly I have not had issues with MCPs where I felt compelled to debug them.

MCPs are very useful when you don't have a CLI or you do but the MCP can handle auth like a proxy to something (e.g. Splunk). Or just for the USB-C analogy she gave.

I was writing MCP servers, now I just write tools for agents to consume. It's often easier to simply write the tool you need and suggest to it to look at the tool to do that thing.

I was also surprised to find out Claude knew how to use the gitlab api with pointing it at the token var in the environment. But for corporations it might make more sense to use a cli to keep the secrets separate from the agent.

> Using existing CLI directly: No context wasted on tool definitions

Can someone explain this to me? I've seen claude code try to run a not-well-known package and it basically shot in the dark a command, noticed that failed, then ran the help command for the cli tool to get a list of commands and what they do.

How is that different than passing the tools with an MCP? Like how are we saving context?

The article has no date on it, but says deferred tool loading is a recent update that occurred after the article was written. Deferred tool loading was added in Nov 2025: https://www.anthropic.com/engineering/advanced-tool-use

So these numbers are at least 7 months out of date. Why is this being posted now?

Edit: Just noticed at the top they reference an article from Feb 2026. So they wrote this article after Feb 2026, then when they realized it was already fixed in Claude Code, posted the notice at the top pretending it was fixed after the article was written. Nice.

Was this written by AI?

MCP is essentially just JSON RPC with a few special fields that must be included. I have reservations about JSON RPC, but there needs to be some 'service discovery' layer for LLMs to interface with.

It needs to be available in places like websites, desktop applications, backend services, etc. The CLI is only one place that these systems interface with.

Whatever you replace MCP with will be in a similar shape even if you specify a different communication protocol or different fields for tool discovery.

MCP is still great if you're running AI in an environment that precludes a shell while needing dynamic tool discovery, but that's a narrow set. People are learning how useful it is to give AI access to a shell. If you're giving them a shell, may as well give them a CLI.

However, I don't think that's what is really hurting MCP, because it could evolve. What really killed it was the standards process and enterprise groups getting ahold of it. It went into spec writing and got adjudicated into uselessness all while enterprise authentication groups were figuring out the best angle to make money on it. I listened to a pitch from Okta on MCP and they wanted to charge out the nose for it for no good reason.

I run the team at OpenAI that's responsible for the ChatGPT App Store, Codex plugins, and all things MCP.

The thing that all these "MCP is dead" posts are missing is that whether or not MCP is used as a transport protocol is actually completely irrelevant.

The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. I know this because we interact with all of them. Most of these companies don't have a CLI. Many of these companies don't even have an external API! And yet, they're all building MCP servers.

And that's why MCP is not only not dead, but more important than ever.

Maybe we will turn every MCP server into a CLI under the hood. Maybe we'll use code mode. Maybe we'll implement tool search.

All of those are just implementation details to the much more important point: our AI agents are getting access to services they otherwise would never have had access to.[0] That's what matters.

So, is MCP dead as a direct communication layer for models to speak to? Maybe, maybe not. Is MCP dead as a protocol? Hell no, couldn't be further from the truth.

[0]: Although I will say the Codex app's computer & browser use features have made this statement a lot weaker than it used to be. If you haven't tried them yet—they're mindblowing.