MCP Is A Protocol, Not An Answer

We love MCP at Adaly. Anthropic did something genuinely useful by giving the industry a shared standard for how models talk to tools. Standards matter. Standards reduce fragmentation. Standards let the ecosystem compound instead of fork.

That is the part everyone agrees on. The part nobody is saying out loud is what comes next.

The protocol is good. The MCPs are garbage.

We have evaluated hundreds of them. Vendor-built, community-built, the official ones, the unofficial ones, the ones with a thousand GitHub stars and the ones with twelve. The pattern is almost universal. They look complete in a demo. They fall apart the moment you ask anything that a real business needs answered.

Here is what most MCPs actually are. A thin wrapper around whatever the vendor's public API already exposed, repackaged as tool calls. If the public API was shallow, the MCP is shallow. If the API does not let you join across objects, the MCP does not let you join across objects. If the API does not give you the historical view, the MCP does not give you the historical view. If the API is read-only, you get read-only, which means your model can look at the system but cannot act on it. Most of what enterprise AI actually needs to do is act, so that alone is disqualifying for serious work.

It gets worse. The permissions model in most MCPs is the connection's permissions, not the user's. Whoever set up the integration determined what the model can see, and that grant follows every subsequent query regardless of who is asking. Your governance team did not approve that. They might not even know it is happening. The data your CFO is supposed to see and the data your intern is supposed to see flow through the same pipe, with the same scope, because the protocol implementation never made room for the entitlement model that already exists inside the source system.

The tool descriptions are often wrong. The schemas are partial. Pagination breaks at any volume that matters. The response payloads explode the model's context window with metadata nobody asked for. Errors come back as opaque blobs. Rate limits hit at exactly the moment the model needs to chain three calls together. Half the time the model has no real way to know whether a call succeeded or silently lost half the records.

This is the state of the art. Right now. In 2026. After more than a year of MCP being widely adopted.

And those are the systems that have an MCP at all. Vast amounts of enterprise data live in systems that do not have one yet and may not have one for years. The vendor that owns your most mission-critical workflow has not prioritized building one because their roadmap is full of other things. The community has not built one because nobody outside your industry cares. The integration team you might have hired to write one yourself is busy keeping the warehouse from collapsing.

So what is the path for a company that is trying to operationalize AI right now.

The path most companies are taking is to wait. Wait for the vendors to ship better MCPs. Wait for the community to fill the gaps. Wait for the standard to mature, the implementations to harden, the ecosystem to converge on something usable. In the meantime, ship something narrow that runs against the two or three MCPs that mostly work, and tell the board that the broader rollout is coming.

That is the bet that is going to cost companies the decade.

The window we have written about elsewhere does not pause for protocol maturity. The competitors who figured out how to operate on live data across every system are not waiting for Salesforce to ship a better MCP. They are not waiting for the ERP vendor to expose write capabilities through tool calls. They are not waiting for the seventeen niche systems that run their actual operations to get a community contributor interested. They are running. Every quarter they keep running, the gap they build is harder to close.

If your AI strategy depends on the MCP ecosystem catching up to your needs, your AI strategy is a queue. You are in line behind every other company waiting for the same vendors to ship the same connectors. The ones who get served first are the ones whose use cases match what the vendors decided to prioritize, which is almost never the use cases that matter most to you.

And even if the MCPs you need all shipped tomorrow, in perfect form, you would still have the deeper problem that nobody is talking about.

A model can call ten MCP servers and still be reasoning across stale fragments. Each MCP gives the model a view into one system. The model has no native understanding of how those systems relate to each other, what the same customer ID means across them, which fields are authoritative, which sources are downstream copies of which other sources. The model is stitching together a mosaic in its context window, one fragment at a time, with no substrate underneath telling it how the pieces actually fit. The protocol moves data between the model and the tool. It does not federate. It does not reconcile. It does not govern. It just routes.

The substrate is what matters. The substrate is what almost nobody is building.

This is the part we had to solve to make Adaly work, and it is the part we refused to outsource to the protocol ecosystem.

We built the connector layer that should have existed in the first place. Full depth into every system we touch. Every record, every field, every relationship, every write capability the source system supports, tuned to that system's specific architecture rather than templated from a generic wrapper. We built the query engine that runs across all of them at once, in place, honoring the permissions that already exist in each source. We built the intelligence layer that understands how the systems relate so the model is not stitching mosaics in its context window. The model asks Adaly a question. Adaly knows where the answer lives, knows how to retrieve it, knows how to compose it, knows who is allowed to see it, and returns it live.

We did this so that none of our customers ever have to wait for a vendor to ship an MCP.

We love MCPs. We expose Adaly's capabilities through MCP for the customers and builders who want to consume us that way. The protocol is fine. The protocol is useful. The protocol will get better.

But we built Adaly so that the protocol getting better is not on anyone's critical path. The companies running on Adaly are not waiting for the ecosystem to mature. They are operating right now, on every system they care about, with the depth and governance and live access that the broader MCP ecosystem will not match for years.

If you are betting your AI strategy on a queue, you are going to watch your competition lap you while you wait for a tool call schema to get fixed.

If you are betting your AI strategy on a substrate that works today, across the systems you actually run, you are not waiting at all.

That is the difference. And the companies on the right side of it are already moving.