A plain-English guide to MCP, the standard that connects AI agents to tools

The charger problem for AI apps

As dev.to reported in the first part of an MCP series, the idea is easiest to grasp through phone chargers. Once every brand had its own plug, and a missing charger meant a dead phone even in a room full of cables. AI software has had a similar mess: each app that wanted to reach a file, a database or a web service needed a connector built just for that pairing.

The Model Context Protocol, or MCP, is meant to be the single shared port. It is an open standard describing how AI applications find and use outside tools, data and ready-made prompt templates through one common interface.

The word protocol matters here. MCP is not a program you install. It is a set of agreed rules, in the same way HTTP is the agreed set of rules for web pages.

Why a standard saves work

On its own, a language model only knows what it absorbed in training. It cannot check today's exchange rate or look at your project board. Before MCP, the common fix was function calling, also known as tool use: you tell the model which functions exist, it asks for one to be run, your own code runs it, and you hand back the answer. All the plumbing for that stays inside a single app.

The author then does the arithmetic. Imagine a company with four AI apps and five services they all need, such as GitHub, Slack and a billing system. Without a standard, that could mean up to 20 separate integrations, each maintained by hand.

With MCP, each app learns the protocol once and each service learns it once. That is 9 pieces of work instead of 20, and the gap widens as either list grows.

Host, client and server

MCP has three roles. The host is the AI app a person actually uses, like Claude Desktop, Cursor, VS Code or an agent you built yourself. Inside it live clients, small connectors, with one client per server and a strict one-to-one link. The server is the program that exposes something useful, such as a database, a file system or a company's own web interface.

In the charger picture, the host is the phone, each client is a port, and each server is the gadget plugged in.

One detail is easy to miss: the model never speaks to a server directly. It tells the host what it wants, and the host's client makes the call. That gap is deliberate, because it is where the user's consent and security checks can sit.

What a server can offer

A server shares its abilities in three forms, and the key difference is who decides when each is used.

• Tools are actions the model can choose to run, like creating an invoice or searching issues.
• Resources are read-only material the application supplies, such as a file or a customer record.
• Prompts are reusable templates the user picks, often as slash commands.

Tools are the most common. When a team says it built an MCP server for its service, it usually means a set of tools that sit on top of that service's existing endpoints. A server can also ask the user for missing details mid-task, a feature called elicitation.

The source also flags a change: three older client-side features, roots, sampling and logging, were deprecated in the 2026-07-28 revision. They keep working for at least twelve months, but new projects should avoid them.

Following one request

The article uses a calculator server with one tool. The server describes that tool to the client with a name, a plain-language explanation and a list of the inputs it needs. The model sees only that description, never the code, so a vague description leads to wrong calls.

Ask the agent for 1,250 times 12 and this happens: you connect the server; the client asks what it offers; the host shows the tool to the model alongside your question; the model fills in the inputs; the host can ask you to approve; the client sends the call; and the server returns 15,000, which the model turns into a reply. The specification expects hosts to keep a person able to refuse a call.

Failures are handled gently. If the model asks to divide by zero, the server sends back an ordinary result marked as an error, with a readable note, so the model can adjust and retry rather than crash.

Many users, one server

Each client talks to one server, but one server can serve many clients. Picture a company billing server used by two employees in different apps and by a support agent running in the cloud. That is three hosts and one server.

How this works depends on the transport, meaning how messages travel. A local server over stdio is launched by the host itself, so each user gets a private copy on the same machine. A remote server over Streamable HTTP is a shared web service at one address that everyone calls, and it uses an OAuth-based framework for access.

The newest revision made the remote case simpler. Every request now carries what the server needs, and the old opening handshake and session ID are gone, so any server instance can answer any request. Tools that need memory, like a shopping cart, pass an explicit handle back and forth instead. The series promises deeper looks at MCP versus ordinary APIs, the changes in this revision, and running MCP on AWS.