How MCP Works And Why Agents Use It

Every few years, a problem gets solved, and the whole industry moves faster. USB-C did this for chargers. REST did this for web APIs. In late 2024, Anthropic built something similar for AI. It's called the Model Context Protocol, or MCP.

The problem was, an AI model needs to use outside tools like your database, your email, your project tracker, but every tool is different, every AI app is different. Without a shared standard, someone has to build a custom bridge for every single pair.

MCP is that shared standard. This article explains how it works, piece by piece. We'll also cover the newest version of MCP, called 2026-07-28. It came out just a few days ago, and it changed a lot of things. So if you read about MCP before, some of it is now out of date. This article covers both the old way and the new way.

1. The problem MCP solves

Before MCP, connecting an AI to a tool meant writing custom code. That code had to talk to the tool's API. It also had to match whatever format the AI model needed. If you switched to a different AI model, you often had to rewrite that code.

Let's say you have N different AI apps. Maybe that's Claude Desktop, a coding assistant, and a Slack bot. And you have M different tools they need to use. Maybe that's GitHub, a database, and Jira. Without a shared standard, you need custom code for every single pairing. That's N × M pieces of code. It grows fast.

MCP fixes this. Each tool only needs to build one MCP server. Each AI app only needs to build one MCP client. Now any app can talk to any tool, because they all speak the same protocol. That turns N × M pieces of code into just N + M.

Code editors solved the same kind of problem years ago with something called LSP (Language Server Protocol). MCP borrowed that same idea and built on it.

2. What MCP is

MCP is not an app. It's not a tool you install and run. It's a set of rules for how messages get sent back and forth. Under the hood, it uses a simple message format called JSON-RPC. On top of that, MCP adds a few building blocks made just for AI: tools, resources, and prompts. We'll explain those soon.

There are always three parts involved:

• Host — the app the person is actually using. This could be Claude Desktop, a coding tool, or your own app. The host holds the AI model and the conversation. It also decides what is allowed to happen. If a tool wants to do something risky, the host is what can stop it or ask for approval.
• Client — a small connector that lives inside the host. There's one client for every server it talks to. If the host connects to five different tools, it runs five clients. The client's job is simple: pass messages back and forth. It doesn't make decisions on its own.
• Server — the thing that actually offers tools or data. Most servers are simple wrappers around something that already exists, like an API or a database. The server doesn't know or care which AI model is using it.

The key point is, the AI model never talks to the server directly. The host always sits in the middle. When a tool sends back a result, the host is the one that adds it to the conversation. This matters a lot. It means the host can check things, ask the person for approval, or block something risky before it happens.

3. How the messages actually travel

MCP supports two main ways to send messages:

stdio — the server runs as a small program right on your computer. Messages are just plain text, sent back and forth. This is the easiest option, and it's what most "install this on your laptop" guides use. There's no network involved, so it's simple and safe by default.

Streamable HTTP — this is used when the server lives somewhere else, like a company's cloud server. The client sends a request over the internet, and the server sends back a reply. Sometimes the reply comes all at once. Sometimes it streams back a little at a time. This is the option used for tools that many people share, not just one person on one laptop.

Starting with the newest version of MCP, every HTTP message also includes two extra pieces of information in its header: which method is being called, and which tool it's for. It means a company's security system can check and control requests just by reading these two header values. It doesn't need to open up and read the entire message first.

POST /mcp HTTP/1.1
Host: api.example-mcp.com
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_issue
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

{"jsonrpc":"2.0","id":42,"method":"tools/call",
 "params":{"name":"create_issue","arguments":{"title":"Bug: nav bar overflow"}}}

4. The "handshake" that used to be required

If you read an older MCP guide, it starts with something called a handshake. The client says hello first, and tells the server what it can do. The server replies, and says what it can do. Then the client says "okay, we're ready." The server would also give the client a special ID number, and the client had to include that ID on every single message after that, so the server would remember who it was talking to.

This worked fine when the server was just a small program on your own computer, but it caused real problems for servers running in the cloud, shared by lots of people. The server had to remember which person was "who," and every request from that person had to be routed back to the exact same server machine.

The newest version of MCP removes all of this. There's no more hello message, and no more special ID to remember. Every single message now carries everything it needs, all on its own. Because of this, any message can be handled by any available server machine. If a client really wants to know what a server can do ahead of time, it can still ask, but it's optional now.

But if a tool genuinely needs to remember something between steps, the tool hands back a kind of "ticket" or reference number, and the AI model passes that ticket back on the next request. The memory lives in the conversation itself, where everyone can see it.

5. The building blocks a server can offer

MCP only allows a server to offer a few specific kinds of things. Keeping this list short and simple makes it much easier for both AI models and apps to understand what's happening.

Building block	Who starts it	Who allows it	What it's for
Tools	The AI model decides to call it	The host decides if it's allowed	Doing something: sending an email, running a search, creating a ticket
Resources	The app decides to use it	The app decides if it's allowed	Reading something: a file, a database row, a log
Prompts	The person picks it directly	The person chooses it	A ready-made template, like a saved shortcut
Sampling (being phased out)	The server asks for it	—	The server asks the AI model to write something mid-task
Roots (being phased out)	The client tells the server	—	Telling a server which folders it's allowed to touch

A tool is described with a name, a short explanation of what it does, and a list of the information it needs:

{
  "name": "create_issue",
  "description": "Create a new issue in the project's issue tracker.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "title": { "type": "string" },
      "body": { "type": "string" },
      "labels": { "type": "array", "items": { "type": "string" } }
    },
    "required": ["title"]
  }
}

6. How a server can still ask you something, even without memory

Sometimes a tool needs to check with you before it finishes. Maybe it wants to confirm something risky, like "are you sure you want to delete this?" But we just said servers don't remember anything between messages anymore. So how does that work?

The answer is called MRTR, short for Multi Round-Trip Requests. Instead of the server waiting and holding the line open, it just replies right away and says "I need more information first."

There's no open connection the whole time. The client just asks the same question again, this time with the answer included. This is simple, and it works well even though the server has no memory at all.

7. A full tool call, from start to finish

Let's walk through one complete example.

1. The host prepares the available tools. It already knows which tools the server offers and converts them into the format the AI model expects.

2. The AI model decides to call a tool. It chooses create_issue and fills in the required arguments.

3. The client sends the request:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_issue
Authorization: Bearer eyJhbGciOi...

{"jsonrpc":"2.0","id":17,"method":"tools/call",
 "params":{
   "name":"create_issue",
   "arguments":{"title":"Bug: nav bar overflow","labels":["frontend"]}
 }}

4. The server does the real work by creating the issue and returning the result.

{"jsonrpc":"2.0","id":17,"result":{
  "resultType":"success",
  "content":[{"type":"text","text":"Created issue #4821: Bug: nav bar overflow"}],
  "structuredContent":{"issueId":4821,"url":"https://tracker.example.com/issues/4821"}
}}

5. The host adds the result back into the conversation. The AI model now knows the issue was created and continues its reasoning.

That's the whole loop: model, host, client, server, and the real tool being used. This repeats as many times as needed until the AI model has everything it needs to answer.

8. Why AI agents need this

You might ask: why not just give the AI model direct access to a normal API? People tried that in the early days, but it ran into real problems:

Every AI model expects a slightly different format. With MCP, the tool only needs to describe itself once. Each app then translates that into whatever format its own AI model needs. The tool author doesn't need to learn the details of every AI model out there.

Tools need to be discovered on the fly. An AI agent often doesn't know ahead of time which tools it will need. Being able to ask "what tools do you have?" at any time, and get a clear answer, matters a lot.

Reading data and taking action are very different things, and mixing them up is dangerous. MCP keeps them separate on purpose. Reading a file is treated differently than deleting one. This lets the host set a simple, clear rule: reading things can happen quietly, but taking action needs a check first.

Someone needs to enforce the rules in one place. If every tool has its own custom code, safety checks can easily get missed somewhere. With MCP, every single tool call passes through the same host, so the same safety rules apply every time, no matter which tool is being used.

Not needing memory matches how these systems are actually used. A company might have thousands of people using an agent at the same time, hitting many different tools. Not needing to remember each person's exact connection makes this much easier to run at a large scale.

9. Trust and safety: what can go wrong, and how MCP handles it

This is one of the most important parts, and it's often skipped in simple guides.

MCP treats three sides as possibly untrustworthy toward each other: the person, the AI model and host, and the server. That might sound harsh, but here's why it matters:

A bad server could try to trick the AI model. A tool's description is just text, and that text becomes part of what the AI model reads. A dishonest tool could hide sneaky instructions inside its own description, hoping the AI model follows them without the person knowing. This is called prompt injection. The lesson: never fully trust text that comes from a tool, the same way you wouldn't fully trust a random file someone sent you.

A careless client could give a tool too much power. If an app hands over a very powerful access key without limiting what it's for, and something goes wrong, the damage could be much bigger than it needed to be. The fix is simple: always give tools the smallest amount of access they actually need, nothing more.

Never blindly pass one access key to a different tool than it was meant for. This sounds obvious, but it's a common mistake. The newest version of MCP adds stronger checks around this, making sure access keys are only used exactly where they were meant to be used.

The newest version also improves how login and access approval work, closing a few tricky security gaps that experts had found. The overall advice stays the same as always: give every tool the smallest access it needs, don't trust text from a server blindly, and keep a person in the loop for anything risky or hard to undo.

10. How MCP grows without breaking older tools

The newest version also introduces a cleaner way for MCP to grow over time. Instead of stuffing every new idea into the core rules, new features can now be added as separate, optional "extensions." Each one has its own name and its own version number, so it can grow and change without breaking everything else.

Two extensions launched alongside this update:

• MCP Apps — lets a tool show an actual visual interface, not just text, inside a safe, boxed-off area of the app. Even though it looks different, anything the person does inside that interface still follows the exact same safety and approval rules as a normal tool call.
• Tasks — built for work that takes a long time to finish, like a big data job. Instead of waiting the whole time, the app can check back later to see if it's done.

The bigger idea here is, keep the core of MCP small and simple, and let fancier features grow on the outside, as optional add-ons. This is a common pattern in long-lasting technology.

11. Where MCP is heading next

MCP is moving toward a smaller core protocol with optional extensions. Enterprise management, long-running tasks, and newer capabilities are being built as add-ons instead of becoming part of the core standard.

Older features that are being phased out will continue working for at least a year, giving developers time to migrate. At the same time, support for MCP has grown quickly across the industry, making it increasingly likely to become the standard way AI applications connect to external tools.

The short version

MCP is a shared standard that lets AI apps and outside tools talk to each other safely. It has three parts: the host (which runs the AI model and enforces the rules), the client (a simple messenger), and the server (which offers tools, data, or templates). The newest version removed the need for servers to remember anything between messages, which makes everything easier to run at a large scale. It also added a smart way for tools to ask for confirmation without needing to stay connected the whole time. AI agents need something like MCP because they must discover tools on the fly, keep reading and doing separate, and never fully trust anything a tool sends back without checking it first.

For more such developer content on multiple formats, visit:
https://vickybytes.com