An MCP server is a small program that hands an AI model a list of real actions it can take in another system, and then carries those actions out. The AI decides what to do; the MCP server is how it actually gets done.
That’s the whole idea. Everything below is detail.
The one-sentence version
Before MCP, a language model could describe how to update your database. It couldn’t update your database. An MCP server closes that gap by exposing a set of tools the model is allowed to call, each one a real function with real inputs and real effects.
MCP stands for Model Context Protocol. It’s an open standard, originally published by Anthropic in late 2024 and now supported across a growing list of AI clients. The “protocol” part matters: it’s a shared format, so any compliant client can talk to any compliant server without either side knowing about the other in advance.
Why it exists
Connecting an AI to a real system used to mean writing custom glue for every pairing. Your AI app needed bespoke integration code for GitHub, and different code for Slack, and different code again for your database. Every new client meant redoing the work.
MCP is often described as “USB-C for AI”, and the analogy holds up. USB-C didn’t make devices more capable; it meant one cable worked with everything. MCP does the same for AI integrations: write a server once, and every compliant client can use it.
What an MCP server actually exposes
Three things, though tools are the one people mean in practice.
| What it is | Who drives it | |
|---|---|---|
| Tools | Actions the model can call, like create_issue or run_query. Each declares its inputs as a schema. | The model decides when to call them |
| Resources | Readable data the model can pull in as context, like a file or a record. | The application decides what to attach |
| Prompts | Reusable prompt templates the server offers for common jobs. | The user picks them |
A tool definition is mostly a name, a description, and an input schema. That description matters more than people expect: it’s how the model decides whether to call the tool at all. A tool called update_record with a vague description gets ignored or misused. The description is a UX surface aimed at a machine.
How a tool call actually flows
Nothing here is magic, and no code executes on its own.
- You ask for something in plain language.
- The client sends the model your request plus the list of available tools.
- The model picks a tool and produces arguments matching its schema.
- The server validates, authorises, and runs it, then returns a result.
- The result goes back as context, and the model continues, often chaining several calls.
Step 4 is the one worth internalising. The model doesn’t reach into your system; it asks the server to. The server decides whether that’s allowed.
What people get wrong about it
“MCP means the AI can do anything on my system.” No. It can call the tools the server exposes, with the permissions the server enforces, and nothing else. A well-built server checks authorisation on every single call. If a tool doesn’t exist, there’s no way to ask for it.
“It’s a Claude thing.” It started at Anthropic, but it’s an open specification with an active ecosystem of clients and servers. Writing a server ties you to a protocol, not a vendor.
“It’s just an API wrapper.” Related but not the same. An API is built for a programmer who reads documentation. An MCP server is built for a model that reads tool descriptions at runtime and decides on its own which to call. That changes the design: fewer, clearer, well-described tools beat a faithful one-to-one mapping of every endpoint.
“More tools is better.” The opposite, usually. Every tool definition consumes context on every request, and a long, samey list makes the model’s choice harder. Some clients cap how many tools they’ll load at all. Curation is a feature.
Where servers run, and what that means for security
MCP servers run in two shapes:
- Local (stdio) — the server runs on your machine as a subprocess. Nothing crosses the network. Common for file access and developer tooling.
- Remote (HTTP) — the server runs elsewhere and the client connects over the network, with real authentication.
Either way the security question is the same: an MCP server should never be able to do more than the person using it. The good ones bind every tool to an existing permission system rather than inventing their own, run destructive actions behind an explicit confirmation, and default anything risky to off.
If you’re evaluating a server, that’s the thing to check first. Ask what happens when the model calls the most dangerous tool it exposes.
A concrete example
Say you want a stale draft cleaned up and published on your site. With an MCP server connected, the exchange looks like:
You: Find posts still in draft from last year and publish the finished ones.
AI: list-posts({ status: "draft", before: "2026-01-01" }) → 7 drafts
AI: get-post({ id: 4412 }) → complete, has a featured image
AI: update-post({ id: 4412, status: "publish" }) → publishedThree tool calls, no code written, no admin screens. The model handled the reasoning about which drafts were “finished”; the server handled permissions and the actual writes.
Should you use one?
An MCP server earns its place when you find yourself describing work to an AI that it can’t perform, and doing it by hand afterwards. If you keep asking for instructions you then follow yourself, that’s the gap MCP fills.
It’s less useful when the task is pure thinking, writing, or analysis. A model doesn’t need tools to draft your copy.
Related reading
- What is a WordPress MCP server? — the same idea applied to a WordPress site
- Tools overview — how a real server organises 200+ tools without overwhelming the model
- Compact tool mode — what to do when a client caps tool counts
- The official specification — the protocol itself