MCP vs. APIs: Why AI Agents Needed Their Own Protocol
Understanding the "USB-C for AI" standard that OpenAI, Google, and thousands of developers have now bought into
For as long as software has talked to other software, it's done so through APIs. You read the docs, hardcode the endpoint, parse the response, and if the API changes, you go fix your code. That's worked fine for two decades of human-written integrations. It falls apart once the thing calling the API is a language model instead of a developer.
That's the gap the Model Context Protocol (MCP) was built to close. Anthropic open-sourced MCP on November 25, 2024, as "a new standard for connecting AI assistants to the systems where data lives." (Anthropic) A year later, it's no longer just an Anthropic experiment: OpenAI adopted MCP in its Agents SDK in March 2025 and has since rolled it out across ChatGPT and its Responses API, Google DeepMind added support to Gemini, and companies including GitHub, Block, Replit, Sourcegraph, and Zapier have built it into their platforms. Over 16,000 MCP servers now exist in the wild. (Zuplo)
The problem: N models × M tools
Imagine building an AI support chatbot for an e-commerce platform. A customer asks where their order is — that's a Postgres query. They ask about product availability — that's an Elasticsearch call. They want a refund — that's Stripe, plus a Slack notification to finance. Each integration needs its own auth, error handling, and response parsing. Now your manager wants to try GPT-4 alongside Claude, and every integration needs duplicating. Add a third model later, and you're maintaining a matrix of glue code that grows multiplicatively with each new model or data source.
Traditional REST APIs weren't built for this because they weren't built for AI consumers at all. A raw Kubernetes API response for a pod's status can run to hundreds of nested JSON fields — fine for a developer who knows what they want, noisy for a model that has to infer relevance. MCP sits between the model and the API, translating a sprawling native response into something like "pod my-app: 3/3 containers ready, no restarts" — only what the model needs.
What MCP actually defines
Architecturally, MCP has three pieces: a host (the AI application — Claude Desktop, Cursor, a custom backend), an MCP client inside that host, and one or more MCP servers, each exposing a tool or data source. Communication runs over JSON-RPC 2.0, using stdio for local processes or Streamable HTTP for remote services — the latter having replaced an earlier HTTP+SSE transport in the March 2025 spec revision. The current dated spec is 2025-11-25.
Servers expose capabilities through standardized primitives: tools (callable functions with a JSON Schema input, like create_refund), resources (read-only, URI-addressable data such as file contents), and prompts (templates suggesting how to use the server). Newer revisions added client-side primitives too, like elicitation, which lets a server ask the user a structured follow-up question mid-task instead of guessing.
What makes this useful in practice is dynamic discovery. On startup, an MCP client sends tools/list to each server and gets back a machine-readable catalog — names, descriptions, schemas. Add a new tool to a server later, and the client picks it up on the next connection, with no client-side code change required. A traditional REST integration needs a developer to update the calling code before a new endpoint can be used at all.
Not the same as function calling
If you've built with a model provider's SDK, you've used function calling — describing a function in JSON Schema so the model can decide when to invoke it. MCP doesn't replace this; function calling is how a model expresses intent to call something, while MCP standardizes how tools are discovered and invoked consistently across servers and providers, so you're not rewriting that glue layer for every model and every API.
One claim worth being precise about: MCP is often described as "stateful" where REST is inherently "stateless." More accurately, it's the host application that retains conversation history and prior tool results — MCP standardizes that pattern rather than the wire protocol having some property REST categorically lacks. You could build stateful orchestration on top of plain REST yourself; MCP just means you don't build it from scratch per integration.
Security: keeping secrets out of the model
A genuinely useful design decision is where credentials live. Naively, an AI agent would need its own API key for every service it might call — uncomfortable given how unpredictable model behavior can be. MCP servers hold those secrets instead: the model requests an action, the server authenticates and executes it, and the model never sees a key or token.
This is formalized in the spec, not just convention. The March 2025 release added an OAuth 2.1-based authorization framework with mandatory PKCE, and MCP servers are explicitly categorized as OAuth Resource Servers, discoverable via a standard metadata endpoint — letting a server plug into existing enterprise SSO rather than inventing bespoke auth. That layer applies to remote, HTTP-based servers specifically; local stdio servers (still common for filesystem or local-database access) pull credentials from the environment instead, a meaningfully different trust model worth knowing before deciding where to run a server.
Real limits, rarely mentioned
MCP is an interface standardizer, not a capability multiplier. If your Postgres integration only has read access, wrapping it in MCP won't make it writable — the underlying API is still the contract.
Dynamic discovery cuts both ways, too. The same property that lets a client pick up new tools automatically also means it can adopt modified tool definitions from a server at runtime without a human necessarily reviewing them. Security researchers have flagged this over the past year as "tool poisoning" — a compromised server altering a tool's description after a client has already trusted it, or using tool outputs to smuggle in prompt injection. That's a real trade-off against the convenience of "just ask the server what it can do," and worth a security review before exposing any MCP server beyond your own machine.
Aggregators: one server, many tools
Not every team wants a separate server per API. Zapier runs a single MCP server connecting to more than 9,000 apps and 40,000+ actions. (Zapier docs) It doesn't hand a client all 40,000 action definitions upfront — that would overwhelm most context windows. Instead, its "Agentic" mode exposes around 14 static meta-tools, and the agent uses functions like discover_zapier_actions and enable_zapier_action to find and enable specific actions mid-conversation — a cleaner illustration of dynamic discovery than a flat tool count suggests.
Where it's headed
Anthropic recently donated MCP to the Linux Foundation's new Agentic AI Foundation, joining Block's goose and OpenAI's AGENTS.md as founding projects. (Anthropic) That's a deliberate move to keep MCP vendor-neutral — a meaningful signal given that OpenAI and Google now depend on it too.
The takeaway
MCP doesn't replace the APIs you already have — Stripe still has its REST API. What it replaces is the custom glue code you'd otherwise write for every model-and-tool pairing: one client speaking one protocol to any number of servers, runtime discovery instead of hardcoded endpoint lists, standardized OAuth instead of ad hoc credentials. A year in, that's proven compelling enough that Anthropic's two biggest competitors adopted it rather than build their own.
Top comments (1)
Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support