We Stopped Treating MCP Like Core Infrastructure

There is a familiar rhythm to integration work. A protocol arrives, it promises to be the universal socket, and every builder spends a quarter wiring their stack to it. The Model Context Protocol is the current one. We built against it. We shipped client work on it. And over the last stretch of building agentic Cystems for operators, we quietly stopped treating it as core technology and moved it to the edge of the estate, where it belongs.

This is not a complaint about the spec. The spec is fine. The issue is the assumption underneath it.

The Socket Assumes a Weaker Agent

MCP exists because a model could not reach a tool by itself. It could reason about your CRM, describe your CRM, write a poem about your CRM, but it could not touch it. So the industry built a standard socket: a server per capability, a handshake, a schema, a registry of what the model is allowed to call. Given a model that can only emit text into a chat window, that architecture is exactly right.

That constraint has been dissolving. A frontier model with a shell, a repository, and a place to put credentials is no longer a mind in a jar asking to be handed things. It is a builder. And when a builder needs to reach an API, it does not wait for someone to publish a server for it. It reads the docs and writes the client.

Give It a Terminal and It Writes Its Own Wire

Here is what actually happens in our lanes. An agent needs to pull bookings from a scheduling platform. There is no MCP server for it, or there is one and it is stale. The agent fetches the API reference, writes a small script that authenticates and returns the three fields the task needs, runs it, watches it fail on a pagination edge, fixes it, runs it again, and commits the file with a test beside it.

The whole detour takes less time than evaluating whether a third-party server is safe to install. And what you are left with afterwards is materially better than a connection. You have a file. It lives in your repository. It has a diff, a blame history, a test, and a shape that matches the job rather than the vendor's idea of the job. When the API changes, the test fails loudly in your own CI instead of the agent silently receiving a malformed response from someone else's server.

That asymmetry is the whole argument. A protocol connection is a dependency you rent. A generated integration is an asset you own, and the thing that generated it will happily regenerate it.

The Tax Is Paid in Context, Not in Code

The cost of a connected server is invisible until you are running real work. Every server you attach pushes its tool definitions into the context window before the agent has read a single line of the actual task. Attach enough of them and a meaningful slice of the model's attention is spent on a catalogue of capabilities it will not use on this run. Attention spent on a menu is attention not spent on the problem.

Then there is the failure surface. When a generated script breaks, the agent reads the stack trace and fixes the line. When a server breaks, the agent gets a protocol-level error with no view into the process that produced it, no ability to patch it, and no way to distinguish a transient network fault from a permanent schema change. It has been handed an opaque box and told to keep working. That is the worst position you can put a capable agent in, and it is structurally what the socket model does.

Add the supply-chain question. Every installed server is third-party code running with your credentials on your machine. We gate those the way we gate any external binary, and most do not survive the gate. A script your own agent wrote against a documented public API has a far narrower blast radius than a community server with a wide permission surface and an unread changelog.

Where the Protocol Genuinely Earns Its Place

None of this makes MCP useless. It makes it a peripheral rather than a foundation, and there is real work at the periphery.

When the surface is a chat box and the operator is not an engineer, the socket is correct. Nobody in a client's marketing channel is going to write an API client, review it, or own it. They need a hosted assistant that can already see the calendar. In that world the protocol is doing exactly what it was designed to do: give a constrained runtime access it cannot build for itself. The same holds for vendor-published servers where the vendor is the one carrying the maintenance and the auth flow is genuinely hard to reproduce.

The distinction is simple. If the agent can write code, execute it, and keep the result, it does not need a socket. If it cannot, it does.

Audit Your Connections This Week

Open the list of servers your agent stack currently loads. For each one, ask a single question: could this agent write and maintain the integration itself, given the docs and a place to put the file? Wherever the answer is yes, the server is costing you context, opacity, and a dependency you did not need to take. Cut it, let the agent build the replacement, and put the result in the repository with a test.

Keep the ones that serve humans in chat surfaces. Keep the ones where a vendor is carrying real maintenance you would otherwise inherit. Everything else is scaffolding you erected around a limitation your agents no longer have.

The operators who compound fastest are not the ones with the most connections. They are the ones whose Cystems can build a new connection on demand and then own the thing they built. That is a different posture entirely, and it starts by deciding the protocol is a convenience rather than a foundation.