What MCP Standardizes and Why It Won the Tool-Connection Wars
The Model Context Protocol (MCP) is an open standard for how AI apps discover and call external tools, data, and prompt templates.
It does not replace your agent loop or your model provider. It replaces the one-off connectors that used to sit between every host and every integration.
Summary
- MCP standardizes the client-server contract for capability discovery, invocation, and results using JSON-RPC 2.0 over pluggable transports.
- Insight: Before MCP, each assistant or framework invented its own tool plug-in shape. Servers had to be rewritten per client. MCP makes "build once, connect many hosts" realistic.
- Key Concepts: host, client, server, tools / resources / prompts, capability negotiation, JSON-RPC methods, stdio vs Streamable HTTP, ecosystem registry.
- When to Use This Model: Evaluating whether to expose internal APIs as MCP servers, choosing frameworks with native MCP clients, or explaining why vendor tool marketplaces converged on one protocol.
- Limitations/Trade-offs: MCP standardizes connection and discovery, not business authz, evals, or multi-agent handoffs. You still own least privilege, budgets, and policy. Enterprise auth/audit pieces remain host- and product-specific (verify roadmap at build).
- Related Topics: three primitives, transports, governance under the Linux Foundation, building servers, A2A for agent-to-agent work.
Foundations
The problem MCP solved
Early agent stacks repeated the same N×M integration pain:
| Before MCP | Cost |
|---|---|
| Custom plugin per host (IDE, chat app, framework) | Rewrites for every new client |
| Ad hoc JSON or free-form "Action:" text | Brittle parsing and weak schemas |
| In-process-only tools | Hard to share across runtimes |
| Vendor-private connectors | Lock-in and incomplete coverage |
MCP's bet is simple: servers speak one protocol; clients adapt once.
Think of it as USB-C for agent tools: the physical/logical plug is standard even if devices differ.
What sits where
User → Host (Claude, Cursor, your agent runtime)
→ MCP Client (in-process library)
↔ MCP Server (stdio subprocess or remote HTTP)
→ real APIs, files, DBs, SaaS- Host owns UX, model calls, policy, and approvals.
- Client owns MCP session lifecycle and message framing.
- Server owns tools, resources, prompts, and side effects.
Function calling still happens between the host and the model. MCP sits between the host and external capability packages.
What the wire actually standardizes
MCP messages are JSON-RPC 2.0 request/response (and notifications).
Typical server-facing capabilities include:
| Primitive | Rough job | Model role |
|---|---|---|
| Tools | Actions with args and results | Model may choose to call |
| Resources | Readable context (files, records, docs) | Often user- or host-selected context |
| Prompts | Named templates / workflows | Usually user- or host-invoked |
Clients and servers negotiate capabilities at session start. A server can expose only tools, or tools plus resources and prompts.
Transports (how bytes move) are separate from the message schema:
- stdio - client spawns server as a local process
- Streamable HTTP - remote single-endpoint HTTP (optional SSE streaming)
- Legacy HTTP+SSE - older two-channel design; prefer Streamable HTTP for new work
See stdio vs HTTP vs SSE for the trade-offs.
Mechanics & Interactions
Discovery then invocation
A healthy session looks like this:
- Connect (stdio spawn or HTTP session).
- Initialize and negotiate protocol version + capabilities.
- Client lists tools (and optionally resources/prompts).
- Host converts tool schemas into the model's tool list.
- Model emits a structured tool call.
- Host/client routes
tools/call(or equivalent) to the MCP server. - Server returns a structured result; host appends it as a tool observation.
- Loop continues until the host stops or the model answers in text.
MCP did not invent the agent loop. It standardized steps 1-3 and 6-7 so every server looks the same to every compliant client.
Why "standard format" beat boutique connectors
MCP won adoption for pragmatic reasons, not pure elegance:
- Shippable SDKs in TypeScript and Python lowered server authoring cost.
- Major hosts adopted the same surface (Claude, ChatGPT, VS Code, Cursor, Copilot-class products, and agent SDKs). Verify current client lists at build.
- Reference servers and public registries gave demos and real SaaS coverage early.
- Transport flexibility covered laptop subprocess tools and remote enterprise services.
- Open governance path reduced the "Anthropic-only standard" objection (see MCP Governance Under the Linux Foundation).
Competing patterns still exist (vendor plugin APIs, OpenAPI-only tool gen, proprietary connector stores). They lost mindshare when hosts and labs agreed that one discovery/invocation contract was worth more than another branded plugin format.
What MCP deliberately does not standardize
| Not MCP's job | Still your job |
|---|---|
| Choosing a model | Routing, cost, fallbacks |
| Multi-agent handoffs | A2A or custom orchestration |
| Perfect tool naming | Descriptions, enums, non-overlap |
| Authorization policy | Scopes, approvals, sandboxes |
| Eval quality | Golden trajectories and CI gates |
If you treat MCP as "automatic security," you will over-expose tools. If you treat it as "USB for tools," you will design better boundaries.
Advanced Considerations & Applications
Mapping MCP tools into provider function calling
Almost every production host does this transform:
MCP tools/list → provider tool schemas
model tool_call → MCP tools/call
MCP result → role=tool / observation messageFrameworks (OpenAI Agents SDK, LangGraph adapters, Pydantic AI, Vercel AI SDK MCP helpers) hide the transform. The ownership split remains: model proposes, host authorizes and executes via MCP.
Multi-server agents
Hosts often attach many MCP servers at once (docs, tickets, code search, CRM).
Watch for:
- Name collisions across servers (prefix or namespace tools)
- Token bloat from always-on huge catalogs
- Privilege mixing (read-only docs server next to write-capable CRM)
Filter tools per role rather than dumping every server's full surface into every agent.
When a custom connector is still fine
| Approach | Strength | Weakness | Best fit |
|---|---|---|---|
| MCP server | Reusable across hosts | Spec/version discipline | Shared internal tools, partner ecosystem |
| In-process function tools | Lowest latency, simplest auth | Not portable to other hosts | Single-app private logic |
| Direct OpenAPI client | Good for pure REST without MCP | No standard prompts/resources layer | Thin service wrappers inside one runtime |
| Vendor proprietary plugin | Deep product integration | Lock-in | Only when the host is fixed forever |
Ecosystem scale as a network effect
Public counts moved from "hundreds of demos" to 10,000+ published servers around the Linux Foundation / AAIF handoff era, with continued growth into 2026 (verify registry numbers at build).
Network effects matter: more servers attract more clients; more clients justify more servers. That flywheel is a large part of "why MCP won" relative to earlier plugin experiments.
Common Misconceptions
- "MCP runs the model." No. The host runs the model. MCP connects tools and context.
- "MCP replaces function calling." MCP feeds the tool list and executes calls; the model still uses structured tool calling.
- "Any MCP server is safe to install." Servers are code with credentials and side effects. Review, pin, and scope them.
- "HTTP MCP is always better than stdio." Local stdio is still ideal for laptop agents and sandboxed subprocess tools.
- "MCP is only for Anthropic." Broad multi-lab and multi-IDE adoption plus foundation governance moved it past single-vendor status.
- "Resources and prompts are optional fluff." Tools alone miss read-only context and reusable workflows many products need.
FAQs
What does MCP stand for?
Model Context Protocol: an open standard for connecting AI applications to external tools, data, and prompt templates.
Is MCP an agent framework?
No. It is a protocol between hosts/clients and servers. Frameworks may embed MCP clients.
What wire format does MCP use?
JSON-RPC 2.0 messages over transports such as stdio and Streamable HTTP (verify current spec version at build).
Do I need MCP for a simple agent?
No. In-process tools are fine for a single app. Adopt MCP when you want portable, multi-host tool packaging.
How is MCP different from OpenAPI?
OpenAPI describes HTTP APIs. MCP describes AI-oriented primitives (tools, resources, prompts) with session negotiation and host-mediated invocation.
Can one agent use multiple MCP servers?
Yes. Hosts commonly attach several servers and merge or filter their tools.
Who executes side effects?
The MCP server process (or remote service) executes them after the host routes an approved call.
Does MCP include authentication?
Transports and ecosystems support auth patterns (headers, OAuth-style flows in products). Exact enterprise SSO/audit details are product- and roadmap-specific; verify at build.
Why did competing tool protocols lose?
Insufficient multi-host adoption, weaker open ecosystems, or narrower scope. MCP combined usable SDKs, host buy-in, and a growing server registry.
Where do A2A and MCP fit together?
MCP connects agents to tools/context. A2A-style protocols connect agents to agents. See What A2A Solves That MCP Doesn't.
Is the protocol stable enough for production?
Yes for many teams already shipping servers, with the usual caveat: pin protocol and SDK versions, and re-verify on upgrades.
What should I standardize first internally?
A small set of high-value internal tools as MCP servers, with least-privilege scopes and a shared client config pattern.
Does MCP help with prompt injection?
It does not remove injection risk. Treat tool outputs as untrusted context and keep deny rules in the host.
Where do I go next after this explainer?
Hands-on connect path: Model Context Protocol Basics. Primitive reference: MCP's Three Primitives.
Related
- Model Context Protocol Basics - first client connection walkthrough
- MCP's Three Primitives: Tools, Resources, and Prompts - primitive cheatsheet
- stdio vs HTTP vs SSE: MCP's Transport Options - transport comparison
- MCP Governance Under the Linux Foundation - institutional oversight
- The MCP Server Ecosystem: 10,000+ Servers in Production - ecosystem map
- Model Context Protocol Best Practices - adoption checklist
- How Function Calling Actually Works Under the Hood - model tool-call loop
- Anatomy of an MCP Server: Handlers, Schemas, and Transport - server structure
- The Broader Protocol Stack: MCP, A2A, ACP, and WebMCP - layer map
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.