What is MCP? The Model Context Protocol explained for people who just want things done
MCP is an open protocol that lets AI assistants call real tools on your machine, create sites, edit content, deploy, instead of just talking about it.
MCP — the Model Context Protocol — is an open standard that lets AI assistants like Claude call real tools instead of just generating text. A program on your machine (an MCP server) publishes a list of things it can do; the assistant reads that list and calls the tools directly. That is the whole idea: the model stops describing work and starts doing it.
If you have ever pasted a wall of instructions into ChatGPT and then executed them by hand, MCP is the protocol that removes the “by hand” part.
The problem MCP solves
Language models are good at deciding what should happen and bad at making it happen. Out of the box, a model can write you a shell command, a WordPress post, or a deploy script — but you still have to run it, paste it, and debug it when the model guessed wrong about your environment.
Every AI vendor used to solve this with proprietary plugins. Each plugin worked with one assistant, one API shape, one auth story. MCP replaces that with a single protocol: any MCP client (Claude Desktop, Claude Code, Cursor, and a growing list) can talk to any MCP server. Write the server once, and every assistant that speaks the protocol can use it.
How it actually works
An MCP server is just a program that answers a few structured questions:
- “What tools do you have?” The server returns a list — each tool has a name, a description, and a typed input schema.
- “Call this tool with these arguments.” The server does the work and returns a result the model can read.
The transport underneath is unglamorous: JSON messages over stdio or HTTP. The interesting part is the contract. Because each tool declares its inputs and describes what it does in plain language, the model can pick the right tool and fill in the arguments itself. No prompt engineering, no copy-paste. If you want the wire-level detail, we walk through it in MCP over HTTP explained.
A concrete example: a whole app as MCP tools
Abstract protocols are easier to grasp with a real server. ReDock is a native macOS app that runs local websites — WordPress, Astro, Next.js, Node.js, Bun — each at a real https://name.test domain with a locally trusted certificate. The entire app is exposed as MCP tools on localhost:47200.
That means an assistant connected to ReDock can:
- create a new site and start or stop it
- write WordPress content through real Gutenberg blocks and patterns, not raw HTML
- magic-login to wp-admin without hunting for a password
- share a site through a Cloudflare tunnel
- deploy a static site to Cloudflare Workers
Every one of those was a click-around-the-UI task. Under MCP, each is a tool call the model makes on your behalf. You can see the practical difference in our Claude MCP tutorial, where a website goes from “doesn’t exist” to “published” in one conversation. The full tool reference lives in the MCP docs.
MCP vs. an ordinary API
You might ask: isn’t this just an API? Close, but the differences matter. An API is designed for programmers who read documentation and write integration code. MCP tools are designed for models: the description is part of the interface, discovery is built in, and the client never needs bespoke glue code. A model handed a REST API needs someone to write a wrapper; a model handed an MCP server just asks it what it can do. We compare the two properly in MCP vs plain APIs.
What MCP is not
Some honest boundaries. MCP is not an agent — it is the socket agents plug into. It does not make a model smarter; it makes a model’s decisions executable. And an MCP server is only as safe as the tools it exposes: a good server reports real state rather than optimistic guesses. (ReDock calls this “honest state” — the status you see is mapped from real process state, never invented.)
MCP is also not tied to any one vendor. Anthropic published it as an open protocol, and clients beyond Claude already speak it.
FAQ
Do I need to write code to use MCP?
No. You need an MCP client (Claude Desktop, Claude Code, or Cursor all qualify) and an MCP server. Apps like ReDock ship the server built in — you connect the client and start asking for things.
Is MCP only for Claude?
No. Claude popularized it, but MCP is an open protocol. Cursor and other clients support it, and any client that implements the spec can talk to any conforming server.
What can go wrong?
The usual: a tool can fail, a server can be down, a model can call the wrong tool. Good servers return clear errors and truthful state so the model can recover. Treat tool descriptions and permissions the way you treat any automation — read what you are granting.
If you want to feel the difference rather than read about it, ReDock gives Claude a full local web stack as MCP tools, free — download ReDock.