The MCP Debate: What Agent Infrastructure Buyers Should Ask

An argument about how AI agents call tools has a practical consequence for anyone buying agent infrastructure: how much of your operation would you have to rebuild if the interface changed?

On September 14, developer Maharshi Patel published a critique of Model Context Protocol, arguing that capable agents can often use existing APIs and command-line tools directly. His objection includes the context consumed by large tool catalogs and the extra machinery built around them. That is a reasonable concern to raise. It does not settle which interface works best in every environment.

At Mailrun, we are building for agents that need to communicate over time. A debate over MCP, APIs, and command-line interfaces matters to that work because customers will change models and tools. Their sending identity and business conversations need continuity through those changes.

What the Protocol Choice Actually Changes

MCP gives an agent client a common way to discover and use tools. A command-line interface can be convenient when an agent already has a terminal. A direct API can fit a workflow that needs explicit requests, structured results, and a conventional integration.

These options can coexist. Cloudflare's Code Mode work, published in September 2025, converts MCP tools into a TypeScript interface that an agent can call through code. It is an example of changing how a model uses tools while retaining MCP underneath.

Google offers another useful counterpoint to the argument that MCP has run its course. Its Google Home MCP documentation describes an early-access server for inspecting device states and performing supported actions. It also describes authorization, revocation, and restrictions on sensitive actions. That shows a concrete use for the protocol, without proving it is the right answer for every business application.

Test Whether the Operation Survives a Tool Change

Consider an agent handling supplier correspondence. It sends a question, waits two days, reads the reply, and asks a human to approve an order. Halfway through that conversation, the company switches its agent software.

The useful buying questions are specific. Can the replacement agent access the same conversation through an authorized interface? Does the company retain control of the address? Can the old agent's access be removed without deleting the mailbox? What happens to pending work that the old runtime held locally?

A demonstration of one successful send answers very little of that. I would ask a provider to walk through the replacement process using a sample conversation before making the purchase. Include the failure case: the original agent is unavailable and cannot export anything for you.

This exercise also exposes where state lives. A mailbox can preserve messages while the agent's task list, approval history, or reminders live somewhere else. Those separate records need their own transfer plan. Keeping an email address does not automatically preserve an entire workflow.

Where Mailrun Fits

Our Agent Identities work centers on company-controlled communication identities for AI agents, with API and MCP access. Access is coming soon; you can request it and discuss your intended workflow with us.

The standard I want customers to hold us to is practical: explain which resources the company controls, which interfaces are supported, and what a change of agent software requires. That is useful information even for a buyer who prefers a different integration method.

There is room for better tool discovery and leaner agent interfaces. Buyers should care about those improvements. They should also ask what happens to the work already in progress when the preferred tool changes.