Dropping MCP

Last week, Perplexity announced that they were dropping MCP and going back to plain old APIs and a command-line tool. 

I love MCP. I used it frequently to connect my local systems to my agent frameworks. It makes LangGraph and Strand a joy. However, MCP is a hack, a naive protocol that should never leave your local network. It can’t be fixed. You cannot retrofit into good architecture.

Simplicity is its selling point, an API for people who don’t want to worry about APIs; a sort of USB for agents to universally connect to other applications. It is a great solution for exposing your local services to your local agents. It is fast to wire up and resilient to change. If you are trying to do something quickly and not for production, it’s perfect. 

But the internet is not, and cannot be built on USB connections. Distributed agent networks, at least for now, cannot be built by people who don’t worry about APIs. MCP is not internet or enterprise-grade. However, in the land of the naive, the easy-to-understand answer becomes the answer, creating an inevitable time bomb.

Doomed By Naivety

MCP follows a long tradition of failed software. Somewhere in the past, some powerful enterprise technology already solved all of these problems and has been battle-tested at internet scales. However, these frameworks are complex and have high barriers to entry.

Some clever team realized that they didn’t have all the features and scale of an enterprise solution. Instead, they needed speed and simplicity. Some well-meaning trade-offs later, and you have a very clever, quick, and easy-to-implement solution that can get your proof of concept up and running. It’s great for a demo, perfect for that internal tool, or automating that weekly task. 

Everything is good until it gets popular or someone decides to ship it, masquerading as a mature piece of technology. The hard-won lessons in security, scale, and encapsulation from previous generations of APIs have all been ignored. It is like watching engineers reinventing the wheel in isolation, unaware that a manufacturing plant already exists down the road. They could just come to the factory and get a big head start, but they are seduced by the building instead of onboarding. It FEELS more productive. Breaking things is framed as being disruptive. Rebuilding the wheel is positioned as innovation.

What Enterprise APIs Actually Solve

All software at scale is built on software you don’t control. Every internet service calls out to other services, other companies, other teams, or other strangers. The fundamental problem enterprise APIs solve is not how to connect; it is how to connect to systems that you cannot trust, that you do not control.

It’s a hard problem. It took thirty years of painful lessons in security breaches, cascading failures, and audit disasters to build the patterns we now call enterprise architecture. Authentication, authorization, rate limiting, versioning, separation of concerns, audit trails, and quality of service contracts are not bureaucracy. They are the solution.

MCP ignores it all because it was never designed to cross a trust boundary. It didn’t need to. It was designed for calling local apps, an agent talking to tools on the same machine, inside a safe perimeter. That is fine for what it is. The problem is mistaking MCP for something it was never designed to be.

You cannot run a bank the way a family business runs a cash till. The till works because everyone in the room is known and trusted. The bank works because no one is.

The Advantages of MCP.

Like USB, MCP offers simple plug-and-play. Agents don’t have to learn new APIs for each tool. As long as a tool can speak MCP, it can be plugged into any agent.

The natural language layer creates automated discoverability and API mapping. If you add a new tool, upgrade a version, or swap one tool out for another, there is no change to the agent. It will dynamically figure it out.

For example, if you had an MCP server that connected to your email and your calendar, you could create an agent that checks for meeting requests and schedules them on your calendar. If you add Slack to your MCP server, it will be instantly available to your agent. Now it can take meeting requests and answer questions via Slack.

This would be much more difficult with classic Enterprise APIs. Each change is a new contract. Each new tool is yet another integration. MCP leverages LLMs to automate a lot of the plumbing and turn months-long Enterprise projects into plug-and-play add-ons. It solves a real problem. 

So What’s the Problem with MCP?

For quick, internal integrations, there isn’t much of one. But we have all seen the spreadsheet turned into a business-critical database. We’ve all seen the tool someone made over a weekend that is now processing millions of dollars in transactions, backed only by fervent prayers that an auditor never spots it.

MCP is broken. It cannot be trusted. It cannot scale. It cannot handle failure. It cannot be secured.

Flexibility is its first problem. The thing that makes MCP so easy to deploy is also why it cannot be trusted. There are no contracts. It is a non-deterministic system that makes no promises on what it will do.  If you are in a low-risk situation, then the low trust is probably fine. If you expect each request to be reviewed by a responsible human, why waste time locking down a system that will have a human in the loop anyway?

Context scale is its second problem. Perplexity found that the MCP server schema overhead consumes 72% of the agent’s context window before even the first request is made. Human language is great for a chatty conversation, but terrible for effective use of bandwidth and CPU. Enterprise APIs often separate discovery, command, and data into different channels; each optimized for its role. Discovery and commands don’t change often and can be cached or even compiled by the client. You don’t need to dynamically query what tools and commands are available each session, or generate client code on the fly each time you repeat the request with different data.

MCP’s strength is its discovery automation, but dynamic discovery and data binding have been addressed for more than 30 years by established protocols such as CORBA and SOAP. MCP didn’t need to reinvent the wheel, let alone be so naive about how APIs work. You don’t need to burn tokens to automate discovery. You can easily point an agent to an OpenAPI endpoint and generate and cache a client tool that your local agent can reuse until something changes.

Third, MCP is not ready for internet scale. The protocol is built on a chat model over HTTPS. The client sends messages over simple HTTPS connections, but the server replies over a static, stateful connection. Each session consists of two connections, one of which must remain open for the whole session. No server scales this way. Servers cannot waste a network port on an idle client. There is no provision for reconnection. The server cannot drop it and migrate the connection to another server. You cannot fail over. You cannot rebalance the load. You cannot drop an idle connection and recover on a reconnect.

Fourth, MCP treats Security as an optional bolt-on. There is no concept of authentication or authorization. MCP is not built on a stack of complementary protocols, as OpenAPI or A2A are. They leverage the security, scalability, and reliability of the underlying layers to build APIs that enable remote calls on an enterprise-ready foundation. MCP does not build on HTTPS. It is a chatbot built to use local tools that has been lifted and shifted from local standard I/O to the network over HTTPS.

Teams will try to solve by wrapping their calls in OAuth, SAML, or some other HTTPS-friendly standards, but there is no MCP standard. These flavors will fracture the plug-and-play ease of use and will be worked around more often than not. Knostic, a company that specializes in AI security, identified 1,862 internet-exposed MCP servers and manually verified 119, finding that all 119 allowed access to internal tool listings with no authentication.

What to Do?

Local MCP still makes sense. It is what it is built for and what it does well.

The good news is that Enterprise APIs are a well-solved problem. The bad news is you might have to upskill your team of disruptive inventors. If you are looking to use agents across trust barriers, have them available via systems on the internet, or as part of any commercial system that requires trust and/or audits, then look beyond MCP. 

Google’s Agent-to-Agent (A2A) is an agent-specific API built for this domain. My teams have had good success with plain old OpenAPI REST endpoints. It is well understood by our clients and has allowed us to build on our existing infrastructure rather than create a whole new shadow stack.

My team is an enterprise-scale organization. We already have Enterprise skills and the stacks in place. It wasn’t a big leap to bring our best practices into the world of agents and leapfrog past MCP. For companies or teams that don’t have that background, the faster you stop trying to fix MCP, the faster you can get into Enterprise agents.

It isn’t that Enterprise Architecture hasn’t caught up to autonomous agents yet. We are starting to realize how agents fit into our Enterprise systems. Unfortunately, the people building the agents are often not the ones who have built Enterprise systems. But you don’t need to be perplexed, it’s time to move on from MCP as the one-size-fits-all connector.