跪拜 Guibai
← All articles
Artificial Intelligence · MCP · AI Programming

MCP Is the USB-C That Ends Hand-Soldered AI Integrations

By 桃西西呀beverlyLee ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Without a standard interface, every agent-to-tool and agent-to-agent connection is a bespoke adapter that breaks on model or framework changes. MCP cuts that integration cost from multiplicative to additive and is already a de facto standard across major AI platforms in 2026.

Summary

Every AI agent that needs to read a database, check a calendar, or call an internal API forces developers to hand-write authentication, data parsing, retry logic, and model-specific glue code for each connection. Swap the underlying model and the whole stack breaks. MCP, proposed by Anthropic in late 2024 and now adopted across Claude, OpenAI, Google, and Microsoft ecosystems, replaces that with a client-host-server architecture where servers self-report their capabilities at runtime. Tools are discovered, not hard-coded.

The protocol runs over JSON-RPC 2.0 on either local stdio or Streamable HTTP, keeping transport details out of application code. A critical design rule: servers are isolated from each other and cannot read full conversation history; the host retains all context and enforces the security boundary. This separation is what makes the USB-C analogy hold — peripherals plug in, but they don't see each other.

MCP is not function calling. Tool calling is a model-side decision layer; MCP is the system-side transport, discovery, and isolation layer that also manages resources and prompt templates. Conflating the two degrades agent behavior because models lose the ability to reason about permissions and side effects. The protocol solves connectability, but the governance of what data to keep, compress, or isolate after it arrives remains the domain of context engineering.

Takeaways
N agents × M external systems produce N×M sets of hand-written adapter code; MCP reduces this to O(N+M) by standardizing the connection layer.
MCP's three-role architecture — Host, Client, Server — enforces that servers are isolated, cannot read full conversation history, and never see into other servers.
Capability negotiation happens at session initialization: servers declare their tools, resources, and prompts at runtime, so adding a new tool requires no integration code changes.
The protocol is transport-agnostic: the same JSON-RPC 2.0 messages run over local stdio or remote Streamable HTTP, with OAuth support on the remote path.
MCP and tool calling operate on different layers — tool calling is model-side decision-making, while MCP handles transport, discovery, permissions, resources, and prompts.
When a single agent has more than 20 tools exposed, tool-selection accuracy drops measurably; MCP solves connectability but not the context-engineering problem of choosing among too many tools.
Google's A2A protocol handles agent-to-agent collaboration, while MCP handles agent-to-tool/data connections; together they collapse both dimensions of integration complexity.
The official MCP Registry for public servers went live in preview in September 2025, and by 2026 Claude, OpenAI Agents SDK, Gemini Code Assist, Copilot Studio, LangGraph, CrewAI, and AWS Strands all support MCP.
Conclusions

The bottleneck has shifted again: first it was model intelligence, then information architecture, and now it is connection standards. An agent that cannot plug into external systems is an isolated brain regardless of how smart the model is.

MCP's isolation rule — servers cannot read the whole conversation — is underappreciated. It means the host becomes the single choke point for security and context governance, which is architecturally correct but puts a heavy burden on host implementations to get permissions right.

The protocol deliberately separates Tools, Resources, and Prompts because conflating them prevents models from reasoning about side effects. Most early MCP adopters will probably ignore this distinction and pay for it in degraded agent behavior.

MCP and context engineering are upstream-downstream siblings that most teams will adopt in the wrong order: they will plug in dozens of servers via MCP, then discover their agent drowns in context noise because they skipped the governance layer.

Concepts & terms
MCP (Model Context Protocol)
An open protocol proposed by Anthropic that standardizes how AI applications connect to external systems — tools, data sources, and workflows — using a client-host-server architecture over JSON-RPC 2.0.
Capability Negotiation
The initialization phase in MCP where a server declares its available tools, resources, and prompts to the client, allowing tools to be discovered at runtime rather than hard-coded at compile time.
Host-Client-Server Architecture
MCP's three-role model: the Host runs the AI model and manages multiple Clients; each Client maintains a 1:1 stateful session with one Server; Servers expose capabilities and are isolated from each other.
JSON-RPC 2.0
The data-layer protocol underlying MCP, defining message structure, semantics, and lifecycle for requests, responses, and notifications between client and server.
Streamable HTTP
The recommended remote transport for MCP since the 2025-11-25 spec revision, replacing the earlier HTTP+SSE approach and supporting OAuth-based authentication for remote servers.
A2A (Agent-to-Agent)
A protocol released by Google in 2025 that standardizes how multiple AI agents collaborate with each other, complementary to MCP which standardizes how a single agent connects to tools and data.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗