An AI assistant, on its own, can only produce text. It cannot check an inbox, query a database, or deliver a message. Everything beyond conversation requires a connection to an outside system — and every connection needs plumbing. MCP, the Model Context Protocol, is an open standard for that plumbing: one interface through which any AI application can use any tool that speaks it. The protocol itself is open and documented at modelcontextprotocol.io.
One protocol instead of a hundred integrations
Without a shared protocol, every AI app needs its own integration for every capability. Five apps and twenty tools means a hundred separate integrations, each written and maintained by someone. That math is why a given tool so often works in one assistant and not another.
MCP collapses the grid. A server written once works from any client that speaks the protocol. The people building a tool build it once; the people using an AI app can reach any MCP server, not just the ones their vendor got around to. Think of a universal port: one connector shape, many devices.
That is the entire pitch. The rest is detail.
Clients and servers, in plain terms
MCP has two roles.
The client is the AI application — the thing you type into. Chat apps like Claude and ChatGPT are MCP clients, and so are most agent frameworks.
The server is a capability: a database, a calendar, a code repository, a messaging service. It describes what it can do in a form any client understands.
When the two connect, the client asks the server what it offers. The server answers with a list of tools. The client hands that list to the model, and from then on the model can use those tools mid-conversation, reading the results back as context the way it reads anything else. The protocol covers more than tools — servers can also expose data and reusable prompts — but tools are the part you will meet first.
Tools are named verbs
A tool is a named action with a plain-language description and defined inputs. A tool called search_files takes a query and returns matches; one called create_event takes a date and a title. The model reads the descriptions like documentation, decides when a tool is relevant, and calls it with arguments.
Two consequences follow, and they matter more than any wire format.
First, descriptions carry real weight. The model decides what to call based on what the words say, so a vague description produces vague behavior.
Second, the tool list is the contract. A model can only do what some server has named. A server that exposes delete_all_records has made a decision; so has the server that doesn't. Scope is set on the server side, where the model cannot negotiate it.
Remote servers: a URL and a header
Some MCP servers run locally alongside the client. But a server can also run remotely, over plain HTTP, the way a website does. You add its URL in the connector section of your app's settings — menus move around, but the shape is constant — and authenticate with a header the server gives you. Nothing to install, nothing running on your machine, and the server's operator maintains one deployment for everyone.
A worked example: nine tools that carry correspondence
RelayLink is a remote MCP server. It carries correspondence between AI assistants owned by different people. Its endpoint is /mcp; its auth header is X-RelayLink-Key: your-key. Its entire surface is nine tools:
check_inbox, get_package, draft_package, confirm_send, cancel_draft, list_drafts, thread_status, list_threads, list_contacts.
The list is worth reading as a design artifact. There is no send_message — composing and delivering are deliberately different verbs. draft_package creates a draft on the server; the human reviews the rendered package exactly as it will arrive; confirm_send, a separate call from the same account, releases it. The approval step lives in the gap between two tools, where no amount of model enthusiasm can skip it. And the consent rules — who can be reached at all, how often someone new can be approached — are enforced by the server, not requested in a prompt.
That is the general lesson hiding in the example: MCP defines how tools are called. What the tools are, and what they refuse to do, is the server's character. A small, legible surface is easier to trust than a sprawling one, because you can hold all nine verbs in your head and know exactly what a connected model can and cannot cause.
What MCP doesn't do
A protocol makes capabilities available; it does not make them safe. A model connected to a badly scoped server can do damage fluently. MCP also does nothing about prompt injection — a model can still be steered into calling the wrong tool by hostile content it reads, which is why agents that can act need their own checklist. Those problems are answered by server design and human approval gates, not by the wire format.
What the protocol does do is remove the plumbing excuse. Once any tool can reach any assistant, the interesting questions move up a level: which verbs should exist, and which ones should require a human. If you want to see the client side firsthand, adding a connector takes a URL and a key — and a nine-tool server is a good first one to read.