Systems Design Meditation · Edition 2
After APIs
Why MCP Signals a New Infrastructure Layer
Edward Calderón
Software Architect
APIs connected software. Agents introduce software that must decide what software to connect to.
A conventional integration begins with knowledge: the developer selects an endpoint, studies its schema and writes deterministic code around it. The caller knows the service and usually knows the operation. Agentic software changes that assumption. It may need to discover capabilities, understand their descriptions, choose among them and carry context across the boundary.
From invocation to discovery
REST, RPC and event streams remain essential. MCP does not make them obsolete. It addresses a different layer: presenting tools, resources and prompts to model-driven clients through a shared interface. The underlying operation may still be an API call, a database query or a local process.
That distinction matters. Discovery is not merely a nicer SDK. A machine selecting a capability needs names and descriptions that support correct reasoning, schemas that constrain inputs, and explicit security boundaries. An ambiguous tool description is an architectural defect because it changes selection behavior.
MCP's specification defines a client-host-server architecture and capability negotiation. It also warns implementers to preserve consent, data privacy and tool safety. Those are clues about the new layer: context exchange cannot be separated from authority.
What interests me is not whether MCP becomes the final protocol. It is that agent-to-system interaction has become important enough to require a protocol layer at all. The protocol may change. The need will remain.
The control plane around tools
A useful agent tool ecosystem needs more than a catalog. It needs lifecycle and governance. Who registered a tool? Which version is active? Which tenant can see it? Does discovery imply permission, or merely awareness? How are results marked as untrusted? What happens when a server disappears halfway through a workflow?
These are distributed-systems questions. Services fail independently. Schemas evolve. Retries can duplicate side effects. The agent may hold stale context. A tool call that appears atomic to the model may span several non-atomic operations underneath it.
Imagine an operations agent choosing between tools for reading telemetry, creating an incident and changing capacity. Discovery should expose all three capabilities, but authorization should not be uniform. Reading can be broad. Creating an incident should be idempotent. Capacity changes should require stronger policy and include a bounded range. A shared protocol helps describe the interface; the platform must still enforce the boundary.
Vendor boundaries make this more important. Organizations will use multiple model providers and hundreds of internal and external services. Bespoke adapters create coupling in both directions. A protocol layer can let a tool evolve without every client learning its private integration, and let a client change without each service being rewritten.
Standardization without mythology
Important ecosystems often accelerate when interfaces become predictable. But analogies can hide more than they explain. MCP is not simply “the new HTTP.” HTTP transports representations between networked components. MCP defines conventions for model-facing context and capabilities, commonly using existing transports underneath.
The useful architectural claim is narrower. Standard interfaces reduce the number of bilateral agreements required for components to cooperate. They create space for tooling: registries, gateways, policy engines, testing harnesses and observability. They also make failures comparable.
Standardization does not automatically create interoperability. Two servers can implement the same protocol while using incompatible semantics. A tool named `search` may search a customer's documents, the public web or an operational database. Semantic quality, provenance and trust remain system concerns.
This suggests a layered design. Use protocols for discovery and exchange. Use identity and policy for authorization. Use domain contracts for meaning. Use tracing and audit records for accountability. Use ordinary APIs and queues for reliable execution. No single layer should pretend to solve the others.
For builders, the immediate value of MCP is therefore not a promise of universality. It is a practical pressure toward decoupling model clients from tool implementations. That makes experimentation less expensive and replacement more reversible.
Protocols matter because they let systems evolve independently.