MCP is Deprecated

I believe the MCP standard should be deprecated and its use should stop. Many people have asked me to explain why Builder doesn’t support MCP and why I’m so against using them. There are several reasons - let’s go through each one.

Reason 1: Zero Flexibility

The first and main reason: all the functionality MCP provides is delivered to the model exclusively as tools it can call. This was designed back in 2024, in an era when people didn’t even know that agents could run with access to Bash, to a CLI, to the command line. So tools were the only way to extend agent functionality - they were supported in the API.

Now, most coding agents and even general-purpose agents run on real machines with command-line access. So the tools MCP provides have gone from a feature to a liability.

Why? Because agents are exceptionally good at working with the command line. They use commands better than any Linux power user, and they can write and execute any scripts they need. So it costs them nothing to implement whatever functionality they need using a convenient CLI interface or even hitting the API directly.

For example, if you connect the GitHub MCP, your agent gets tools loaded into its context whose output it can’t post-process in any way, and it can’t create reusable scripts for repetitive tasks. Atlassian MCP will dump massive JSON blobs of tens of thousands of tokens into the agent’s context on every tool call - with no way to pipe through jq for filtering, parse it and strip garbage escape characters, write it to a file and process it in chunks, run scripts, or write a custom utility for convenient reuse. Even composing multiple calls costs you sequential round-trips to the API.

If the agent were calling this through the CLI, it could write a reusable script that fires all of the required commands and immediately processes their results - one API request, and the agent gets exactly what it needs as output. This is the biggest problem with MCP for me - the complete lack of flexibility in how tools are used and reused.

Reason 2: Context Pollution and No Progressive Disclosure

Second reason: the definition of all MCP functionality - all tools, all features, output format, and input arguments - is fully loaded into the model’s context at the start of every session, and there’s no getting rid of it.

We moved out of the prompt engineering era into context engineering, and now into harness engineering, a long time ago. But MCP is stuck in place because of a fundamentally broken design that has no mechanism for progressive disclosure of information to the agent.

If your agent needs to leave a comment on a GitHub ticket, it can’t just look up the request format for that specific action. Along with the tool it needs, it gets 45 others that take up 50,000 context tokens - just because it wanted to leave a comment. And you have no way to disable the extra MCP tools. This is a fundamental flaw in the architecture: if you start a session and realize a particular tool isn’t needed, you can’t just turn it off - doing so would fully invalidate caches. Result: 50,000 context tokens wasted.

You might argue: who cares, we have plenty of tools anyway? The thing is, every extra tool in context doesn’t just add tokens. Even if you write minimalist tool descriptions and design your MCP perfectly, you’re still expanding the agent’s decision surface.

Imagine that, as a human, every time you want to screw the next bolt in, you have to first re-decide and find the right one among 50 tools in the garage. The exact same thing happens with agents. If you have 50 tools in an MCP server, the model’s attention gets spread across all 50, with some fraction of it going to each one. Roughly speaking, the model runs through every tool like a checklist: do I need create_github_comment? do I need search_github_issues? do I need edit_github_pull_request_description right now? - and so on through every tool in context. And this happens not just before calling the right tool, but literally on every step the agent takes, even when it’s doing something completely different.

Some will say: “But Anthropic made tool search - now Claude can discover tools.” First, this doesn’t fully solve the problem: Claude still gets a list of all tools from all MCPs in context at startup, just in a more minimal format. This only reduces context usage but doesn’t eliminate the need to make decisions - Claude still sees create_github_issue, it just now needs an extra get_tool_schema call to get the details. In some ways this makes things even worse. Second, it’s just a band-aid fix: people complained, and Anthropic shipped the first thing that came to mind. It doesn’t solve the progressive disclosure problem at the root - it treats the symptom, and now the agent needs an extra step just to learn tool descriptions.

Worth mentioning separately: MCP, by its standard, is required to provide usage context alongside the tools - what they’re for, when and how to use them. And there’s nowhere to put this except in the tool’s description or in a separate tool that burns the agent’s turns. Which means you don’t even know what you’re actually adding when you connect an MCP. You can connect an MCP that will tell your model to never make commits, or exfiltrate your credentials to a third-party server - and the model will comply, because all of this lands in the system block and carries nearly the same authority as the system prompt. This is exactly why malicious MCPs are so widespread: the moment a user enables one, the attacker can do whatever they want with the model.

Compare this to CLI: the agent only gets instructions when it calls a command’s help. If the agent needs to leave a comment on GitHub, it calls gh --help, learns the relevant commands right before using it - and this has zero impact on the session until the GitHub CLI is actually needed. Instructions are revealed immediately before using the tool, exactly as they should be - since the model’s attention is significantly more focused on the end of the context window. The agent gradually “forgets” instructions from the beginning of the context. So with MCP you’ll see constant degradation in tool usage quality, whereas with CLI the agent receives instructions later - which increases how long it actually follows them.

Reason 3: Strange Architecture and an Unstable Standard

Let’s talk about MCP’s architecture. First, if an MCP runs locally, it must spin up a server that agents communicate with over STDIO. It’s unclear why they couldn’t make them stateless and store auth credentials elsewhere. Why STDIO transport - essentially a hack for passing data through terminal I/O - rather than any other approach? Now Claude users have 56 node processes eating up gigabytes of data just because they needed to look up maven artifacts.

The MCP standard started with SSE events, and in early 2025 the authors of every single MCP had to migrate to HTTP transport and rework their implementations. With CLI you can count on decades of stability - terminals aren’t going anywhere anytime soon - but with MCP every standard change brings another round of refactoring.

And guess who designed the MCP standard almost single-handedly? Anthropic. You are dependent on one company’s decisions for your agent tooling. Meanwhile, CLI is a seventy-year-old standard for working with terminals.

CLI as an Alternative

In laying out all these flaws, I’ve already been bringing up CLI and bash tooling - and not by accident. For agents with filesystem access, this is the best option right now, at least until something better comes along.

CLI interfaces have always existed and always will. Almost all the functionality you need is already available through the console: agents with terminal access can automate tasks on a computer, write code, deploy projects, manage auth in Google Cloud, Amazon, DevOps, convert media files to any format, edit documents - all exclusively through console commands. This is vividly illustrated by OpenClaw’s popularity boom: people realized that an agent with command-line access and broad privileges can do an enormous amount of useful work.

Imagine if every piece of OS functionality were another MCP tool - you’d have not hundreds but thousands of tools that the agent would have to dig through, that would have to be built from scratch, and whose results would have to be shuttled through ill-fitting protocols. Let’s not reinvent the wheel and instead keep building on what Linux power users have been doing for decades.

Counterarguments to CLI

The one thing I can’t argue against: if your agent doesn’t have command-line access, you can’t call CLI tools and will have to hit the API directly. However, solutions for virtual filesystems and virtual CLI environments are already emerging - you can use those instead of continuing to add MCPs.

These are still rough, so the only real use case where you genuinely can’t avoid MCP right now is agents without filesystem access and no other way to interact with an external resource.

But MCP is, at the end of the day, a lazy hack instead of a real harness. We do harness engineering, and the first rule of a good agent is building a good harness. If you just plugged in an MCP with 50 tools for all possible tasks without trying to specialize the agent or configure its environment, performance on complex tasks will reflect that. Think about it: maybe you’re adding MCP just to save time and avoid doing real harness design?

On Authorization

Some people ask: “What about authorization in MCP?” The thing is, the MCP standard doesn’t actually help much with authorization. STDIO servers that run locally didn’t support authorization at all the last time I checked - so you can’t make them secure. Remote MCPs support OAuth, which is a reasonable standard in principle. But what part of that doesn’t CLI support?

With CLI you can securely store keys in your operating system’s Keychain, and the CLI accesses them when the relevant commands are called. You don’t need to spin up a separate server, you don’t need harness-level integration just to store keys properly - every CLI handles its own auth data storage.

In the MCP standard, Anthropic specified that the harness should handle storing and providing authorization data for MCP - a task that’s completely foreign to it. I think this is a wrong separation of responsibilities. If a CLI requires authorization, the CLI should own that from A to Z, not delegate it to a harness that has no defined way of implementing that authorization. Some agents were storing all keys in a flat directory on the host machine - and you didn’t even know, because it looked transparent through the harness. If a CLI has poor auth, you can isolate that CLI. But if your entire harness does - what then?

Documentation and Prompts in MCP

MCP also assumes that if you don’t want to pack everything directly into tool schemas, you need to attach some kind of skill on top - the standard supports custom prompts and instructions (which, in my experience, almost nobody uses). Meaning you have to rely twice on the provider or your own wrapper, process everything according to the standard, because nothing works out of the box if you want to contextually surface knowledge to the agent.

This just locks you further into a walled garden. With CLI you always have --help, and every subcommand has a place to add a description. As the author of both an MCP and a CLI, I know how hard it is to maintain documentation spread across disconnected locations, and how many security holes there are in the MCP standard.

What to Do Instead of MCP?

Let’s say you agree that MCP should be deprecated, but you have 25 MCPs with no equivalent CLI. How do you work with Figma, for instance?

The solution already exists. Providers are actively building CLIs for their popular tools. As a temporary solution, I recommend using tools that port MCPs to CLIs, such as mcporter.

And in general - try to find an existing CLI or build a CLI for your tooling yourself. It’s not as hard as it sounds.