Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Model: openai/gpt-5.4
Generated: 2026-04-01
Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead
Chapter: 7 — MCP: The USB-C of AI
Token Usage: ~11,000 input + ~1,900 output (estimated)

7.1 Why MCP Changes Everything

When Anthropic introduced MCP, the Model Context Protocol, in November 2024 under the MIT license, the announcement sounded modest: here is an open standard for connecting AI systems to tools, data, and prompts. In practice, it marked a deep architectural shift. MCP matters for agents in the same way USB-C mattered for hardware ecosystems. Before USB-C, every device family invented its own cable, power profile, and negotiation quirks. Before MCP, every AI framework invented its own tool format, transport assumptions, and integration layer. The result in both worlds was the same: fragmentation, duplicated work, and poor composability.

The “USB-C for AI” analogy is more than marketing. USB-C is valuable not because it is a cable, but because it standardizes the interface between many independent producers of capability. A laptop vendor, a monitor vendor, and a charger vendor can all move faster because they share the same connector and negotiation model. MCP does the same for software capabilities. It standardizes how an AI host discovers what an external server can do, how it invokes those capabilities, how it reads structured resources, and how it receives reusable prompt templates. Once that interface is stable, ecosystems can grow without every integration being custom.

At a high level, the architecture is simple:

Host → MCP Client ←→ JSON-RPC 2.0 ←→ MCP Server

graph TB
    subgraph "Host Application"
        H["Agent Runtime<br/>(OpenCode / Claude Code)"]
        MC1["MCP Client 1"]
        MC2["MCP Client 2"]
        MC3["MCP Client 3"]
    end
    
    H --> MC1
    H --> MC2
    H --> MC3
    
    MC1 -->|"stdio"| S1["🗄️ PostgreSQL<br/>MCP Server"]
    MC2 -->|"HTTP/SSE"| S2["🔍 GitHub<br/>MCP Server"]
    MC3 -->|"stdio"| S3["📁 Filesystem<br/>MCP Server"]
    
    S1 -.->|"Tools + Resources"| MC1
    S2 -.->|"Tools + Resources"| MC2
    S3 -.->|"Tools + Resources"| MC3
    
    style H fill:#4a9eff,color:#fff
    style S1 fill:#51cf66,color:#fff
    style S2 fill:#51cf66,color:#fff
    style S3 fill:#51cf66,color:#fff

The host is the user-facing application: Claude Desktop, Cursor, VS Code, Zed, ChatGPT, or an agent runtime such as OpenCode. Inside the host sits an MCP client, which knows how to speak the protocol. On the other side is an MCP server, which exposes three primary capability classes:

  • Tools: executable actions, such as search, file access, browser automation, or API calls
  • Resources: readable data objects, such as documents, memory entries, schemas, or generated artifacts
  • Prompts: reusable prompt templates supplied by the server

This split is important. Many early agent systems flattened everything into “tools.” MCP is more expressive. Some things are actions, some are data, and some are structured instructions. That distinction reduces friction. A documentation server, for example, may expose search as a tool, individual pages as resources, and task-specific prompt templates for summarization or migration guidance.

The wire protocol underneath MCP is usually JSON-RPC 2.0. JSON-RPC is a standardized remote procedure call protocol where messages are encoded as JSON objects. Remote procedure call, often abbreviated RPC, is not always emphasized in mainstream CS curricula, but the idea is simple: call a function that lives somewhere else as if it were local, by packaging the method name, arguments, and response in a structured message format. JSON-RPC gives MCP a widely understood request-response envelope: method name, params, id, result, or error. That choice matters because it makes the protocol predictable, debuggable, and transport-agnostic.

Transport-agnostic is the next major idea. MCP does not force a single deployment model. It supports multiple transport styles because agent environments differ:

  • stdio for local servers: the host spawns a subprocess and communicates over standard input/output
  • HTTP + SSE for remote servers: the client sends requests over HTTP and receives server-sent events for streaming updates
  • WebSocket for web and long-lived bidirectional environments

This flexibility is a big part of why MCP took off. A local SQLite assistant, a remote documentation server, and a browser-based collaborative IDE can all participate in the same capability ecosystem without pretending they have the same runtime constraints. The protocol stays stable while deployment changes.

The most famous structural benefit of MCP is the N+M advantage. Without a shared protocol, if you have N agent frameworks and M tool providers, you need N × M integrations. Every host must write a custom adapter for every tool family. That scales terribly. With MCP, a host implements MCP once and a tool provider implements MCP once. The total work approaches N + M instead of N × M. This is the key economic argument for standards. Standards are not just elegant; they change the cost curve.

That cost curve explains adoption. By 2026, MCP support had spread far beyond Anthropic’s own products. Claude Desktop gave the protocol its first major home, but adoption quickly broadened to Cursor, VS Code, Zed, and eventually ChatGPT and many third-party agent shells. At the community layer, there are now 1,000+ MCP servers, ranging from GitHub search and browser control to documentation retrieval, databases, design tools, Slack, local memory systems, and internal enterprise connectors. The exact count matters less than the pattern: MCP became the default packaging format for “capabilities that an agent can use.”

That packaging standard changes how agent architectures are designed. Before MCP, tool integration was often a private implementation detail hidden inside each agent product. A company shipping an agent had to decide not only how to reason, plan, and act, but also how to define tool schemas, how to launch local processes, how to handle auth, how to expose data sources, and how to normalize errors. This meant every agent product became part runtime, part app platform, part integration SDK. MCP unbundles that problem. The host can focus on reasoning, UX, permissions, and orchestration; the server can focus on a domain capability.

This is why MCP changes not just interoperability, but division of labor. It lets specialized teams build specialized servers without needing to own an entire agent runtime. A documentation company can ship a docs MCP server. A search company can ship a search MCP server. A design tool vendor can ship a design MCP server. Meanwhile, agent frameworks can compete on context engineering, tool selection policy, safety, and user experience. That is a healthier ecosystem because it creates modular competition instead of monolithic duplication.

There is also a subtler benefit: MCP improves conceptual hygiene. In agent design, many failures come from mixing layers. We confuse the model with the tool runtime, the host UI with the data provider, or prompt templates with executable actions. MCP draws cleaner boundaries. The client is where model-facing adaptation happens. The server is where capability exposure happens. The transport is just transport. JSON-RPC is just message framing. That separation makes systems easier to reason about, test, secure, and swap.

Of course, MCP does not solve every problem. It does not magically make tools safe, nor does it eliminate the need for strong permission models, schema validation, output truncation, or contextual grounding. A bad host can still expose dangerous tools badly. A bad server can still return enormous or misleading outputs. But standards do not need to solve everything to be transformative. They only need to stabilize the interfaces that were previously slowing everyone down.

The long-term significance of MCP is therefore architectural. It turns tool access from a product-specific feature into a shared substrate. Once that substrate exists, ecosystems compound. Open-source communities can build on it. commercial vendors can extend it. agent platforms can differentiate above it. That is exactly what happened with USB, HTTP, JSON, and OAuth: once a common interface became trustworthy enough, innovation moved up the stack.

For AI coding agents, this is the turning point. Models may still vary in quality, context windows may still expand, and orchestration patterns may still evolve. But MCP establishes something more durable than a model release cycle: a common language for capability exchange. That is why it changes everything.