Model Context Protocol Explained: How MCP Works

There's a specific kind of frustration that lives in the gap between what an AI model can do in theory and what it can actually access in practice. You've got a capable language model. You've got tools, databases, internal docs. And between them: a tangled mess of custom integration code, brittle system prompts, and authentication edge cases that break whenever either side gets updated. Every connection is its own little snowflake of suffering.

That's the problem the Model Context Protocol was built to solve — and in a recent Google Cloud Tech video, developer advocate Smitha Kolan walks through how MCP actually works under the hood. It's a clean explainer, and the core argument is worth digging into: not just what MCP does, but why the problem it solves is structural, not incidental.

The mismatch that made this necessary

APIs are not the villain here. They're just miscast.

As Kolan explains: "APIs were never designed for AI models. They were designed for programs that already know exactly what they want. Programs that can form precise, deterministic requests."

That's the crux of it. A traditional API call assumes the caller has fully resolved their intent before making the request. You know the endpoint, the parameters, the expected response shape — everything is specified ahead of time. The API just executes.

Language models don't work that way. They reason probabilistically over uncertain inputs. They might need to explore what's available before deciding what to do. They might chain several actions together based on intermediate results. Shoving that kind of flexible, contextual reasoning through a rigid, pre-specified API interface is like trying to have a conversation through a vending machine. Technically functional in narrow cases; structurally the wrong tool.

MCP is the answer to that mismatch. It's an open standard — introduced by Anthropic and now picking up broad industry adoption — that gives models a consistent way to discover what tools and data exist, rather than requiring them to be pre-programmed with every endpoint.

Clients, servers, and the capability advertisement

The protocol's architecture splits into two sides: clients and servers.

The client is the model or agent system doing the reasoning — Claude, Gemini, an OpenAI-based agent, whatever you're working with. The server is the environment exposing resources the model can use: a database, a file system, a CRM, internal tooling, a document search index.

Here's the part that makes MCP different from a regular API call: when the client connects, the server doesn't just sit there waiting to respond to known requests. It advertises its capabilities. It tells the client what resources exist, what actions are available, what inputs those actions expect, and what outputs they return.

"This means the model doesn't need to be pre-programmed with every API or every endpoint. It can dynamically discover them," Kolan explains.

That capability-advertisement pattern is doing a lot of work. It means you can add a new tool to an MCP server and any compliant model connecting to it will automatically see it — no retraining, no new system prompts, no custom glue code. The model can literally ask the server "what can you do?" and get a structured answer back.

The communication itself is straightforward: the client sends requests (list available resources, call this action, retrieve this data), and the server responds with structured JSON. Boring, in the best way. Boring means it works.

The four things a model can see

MCP defines four main resource types that together constitute the model's view of its environment:

Tools are actions the model can invoke — search a database, send an email, analyze a file. Resources are data and state: documents, database rows, images. Prompts are reusable templates that define how the model should behave for specific tasks. And context covers external information the model can pull into its reasoning — chat history, user preferences, company data.

Each of these comes with metadata describing what it does, what input it expects, and what it returns. So when a model connects to a GitHub MCP server, a CRM server, and a calendar server simultaneously, it can interact with all three through the same schema. Same language, different vocabularies. That consistency is what allows models to chain tools together intelligently — and what makes the whole thing composable in a way custom integrations never really are.

This composability dimension is where MCP starts to feel genuinely different rather than just tidier. It's one thing to remove glue code. It's another to enable a model to dynamically sequence tools in ways the developer didn't explicitly anticipate. That's closer to genuine agency than most "AI integration" patterns actually deliver. (The security implications of that expanded autonomy are worth thinking through carefully — a model that can discover and invoke arbitrary tools is also a model with a larger attack surface.)

MCP above APIs, not instead of them

One potential misconception worth addressing: MCP doesn't replace your existing APIs. It sits above them.

"You can think of MCP as an abstraction above APIs. APIs still exist, MCP just makes them model-friendly. Under the hood, your MCP server might still call your existing REST or GraphQL APIs, but the model never sees that."

This matters for practical adoption. You're not ripping out your infrastructure; you're adding a translation layer that makes your infrastructure legible to models. The MCP server handles discovery, validation, and execution in a standardized way. From the model's perspective, it's just interacting with the MCP schema — what's underneath is abstracted away.

Kolan's practical example makes this concrete: building a personal assistant agent that checks your calendar, pulls meeting notes, and drafts follow-up emails. In the old approach, you'd wire up Google Calendar, Notion, and Gmail separately, write custom code for each, handle auth and rate limits, and then painstakingly describe all those integrations to the model in a system prompt that would inevitably break.

With MCP, you spin up a calendar server, a notes server, and an email server. Each advertises its capabilities. The model sees list_events, get_meeting_summary, send_email as available tools, figures out the right sequence, passes data between them. "The developer doesn't have to write glue code for each new tool. The model knows how to interact because the protocol is consistent."

The fragmentation problem this solves is bigger than the calendar example suggests — it shows up anywhere models need to interact with specialized toolchains, which is essentially everywhere serious AI development is happening.

What's still an open question

MCP's rapid adoption trajectory — from an Anthropic internal standard to something Google Cloud is actively building infrastructure around — is real. The HTTP analogy Kolan uses isn't just flattering marketing copy; it reflects a genuine dynamic where a sufficiently useful standard can become load-bearing infrastructure faster than anyone expects.

But the analogy also hints at the tension worth watching. HTTP unified the web partly because it was genuinely open and nobody owned it in a way that distorted the ecosystem. MCP was introduced by Anthropic, and while it's being promoted as an open standard, the governance question — who decides how it evolves, whose interests shape its development — is less settled than the technical spec itself. Google's enthusiastic adoption via Google Cloud is good for legitimacy and ecosystem momentum; it also means multiple major players now have strong opinions about the protocol's direction.

The other open question is scope. MCP as described here connects agents to tools and data. A related protocol, A2A versus MCP, addresses agent-to-agent communication — and a realistic production AI system probably needs both. MCP solves the tool integration layer cleanly. The coordination layer between agents is a different problem.

None of this diminishes what MCP is actually doing. The core mechanic — let models discover capabilities dynamically rather than hardcoding every integration — is the right answer to a real structural problem. The developer experience improvement alone is significant. The composability gains are substantial. And the fact that it's picking up adoption from Claude to Gemini to the broader ecosystem suggests the industry has identified the same problem and landed on compatible solutions.

Whether MCP becomes the HTTP of AI infrastructure or just a very useful interim standard that something better eventually replaces — that's genuinely unclear. What's clear is that the messy, custom-integration-every-time status quo was not going to survive the agent era, and something like MCP was going to have to exist. The question now is which version of it sticks.

---

Yuki Okonkwo is Buzzrag's AI & Machine Learning Correspondent.