Quick Answer: MCP, or Model Context Protocol, is an open standard that lets AI apps connect to external tools, data, and prompts through a common interface. A server declares what it can do, the host app shows that list to the model, and when the model wants something, the app calls the server and returns the result. It's built on JSON-RPC 2.0, but the protocol itself defines the methods, capability negotiation, transports, and auth.
Most explanations of MCP start with a diagram and stop there. The diagram looks simple: an AI app talks to a small program, which talks to a database or API. The hard part is everything the diagram hides. Who decides which tool gets called? What happens when a server changes its tools mid-session? Why does a "simple" protocol need a spec with dated versions? If you're wiring up Claude, Cursor, or your own agent, these details decide whether your integration works on the first try or breaks on the fifth. Here's what actually matters.
The three roles you need to keep straight
MCP has three roles, and most confusion comes from mixing them up. The host is the AI application you actually use, such as Claude Desktop, Cursor, ChatGPT, or a custom agent. The host owns the user session, the model, and the permission prompts. The client is a connector that lives inside the host and keeps a one-to-one session with each server. The server is a program that exposes capabilities, often a few hundred lines of code wrapping an API, a database, or a local file system.
The model never talks to a server directly. It only sees what the host passes along. That separation is deliberate: the host can filter, log, or ask the user before any tool runs. It also means that when a tool misbehaves, you debug the host's handling as well as the server's code.
What a server actually exposes
A server offers three core primitives. Tools are functions the model can invoke, such as create_issue or run_query, each with a JSON Schema describing its inputs. Resources are read-only data the host can fetch by URI, like a log file or a database row. Prompts are reusable templates the user can select, which is useful for standardized workflows.
The discovery mechanism is what makes this more than a function list. At runtime, the host calls tools/list, resources/list, and prompts/list, so the server describes itself on connection rather than being hard-coded into the app. Add a tool to your server and any compliant host can see it the next time it reconnects. Here's the catch: the model decides what to call based on the descriptions you write, so vague descriptions produce wrong tool choices. Treat each description as a prompt, not as documentation.
Why MCP isn't just REST, and why that matters
This is the part most guides skip. The popular shorthand is "MCP is an API standard for AI," and that's incomplete in a way that causes real design mistakes. MCP uses JSON-RPC 2.0 messages, which is closer to a remote procedure call than a resource-oriented REST API. More important, it's a two-way protocol. A server can send requests back to the host through features like sampling, where the server asks the host's model to generate a completion, and elicitation, where it asks the user for structured input mid-task.
Compare the options directly:
| Aspect | REST API | MCP | Provider function calling |
|---|---|---|---|
| Capability discovery | OpenAPI doc or human-written docs | tools/list, resources/list, prompts/list at runtime | Schemas supplied in each model request |
| Message format | HTTP verbs with JSON bodies | JSON-RPC 2.0 messages | Vendor-specific JSON |
| Server can call back | Not natively (webhooks are a workaround) | Yes, via sampling and elicitation | No |
| Reuse across apps | Client SDK per API | One server works in any compliant host | Re-implemented per vendor |
The practical takeaway: if your use case is a single app calling a single API, plain function calling is simpler. MCP earns its complexity when you want one server to serve many hosts, or when the tool needs to ask the model or user for help partway through a task.
How one tool call actually flows
Understanding the sequence removes most of the mystery. Here's what happens when you ask an assistant to check open pull requests:
- The host starts each configured server and performs initialization, where both sides exchange their supported protocol version and capabilities.
- The host calls
tools/listand passes the returned tool schemas to the model alongside your message. - The model decides it needs
list_pull_requestsand emits a structured tool-use request. - The host checks permissions, then sends a
tools/callmessage to the server with the arguments. - The server queries the upstream API and returns a result, which the host feeds back to the model as context.
- The model writes the answer you see.
Step 4 is where safety lives. The host should confirm sensitive actions with you before executing them, not after. Here's where most guides go wrong: they show the happy path and never mention that the host, not the server, is the enforcement point.
Transports: stdio versus Streamable HTTP
MCP messages travel over a transport, and the choice shapes your deployment. The stdio transport launches the server as a local subprocess and exchanges messages over standard input and output. It's fast, requires no network setup, and inherits the user's local privileges, which is exactly why it's risky if you run untrusted servers. The Streamable HTTP transport, introduced in the 2025-03-26 revision of the spec, runs the server as a remote HTTP endpoint and can stream responses back over the same connection.
Use stdio for local developer tools where the user already trusts the code. Use Streamable HTTP for shared, remote services that multiple users connect to. That said, remote servers bring authentication into scope, and the spec's authorization flow, based on OAuth 2.1, is where teams most often cut corners. Don't ship a remote server without it.
Where MCP implementations break
Real failures tend to cluster in a few places. The first is tool sprawl. A server that exposes 60 tools forces the model to choose among 60 overlapping schemas, and selection accuracy drops. Cut the surface to the tools people actually use, and merge near-duplicates.
The second is prompt injection through tool output. A resource or tool result can contain text that looks like instructions to the model. Hosts should treat returned content as data, and you should never assume a server's output is safe to act on without a check. The third is stale assumptions about versions. Because the spec is versioned by date, a host and server can negotiate down to an older protocol version. If you rely on a newer feature, verify it's actually negotiated rather than assuming both sides support it.
Frequently Asked Questions
What is MCP in simple terms?
MCP, or Model Context Protocol, is an open standard for connecting AI apps to outside tools and data. The app discovers what a server offers, shows that list to the model, and routes the model's requests to the server. It was announced by Anthropic in late 2024, and its first spec version is dated 2024-11-05. Think of it as a shared plug shape for AI integrations.
How does MCP work step by step?
The host starts or connects to each server and negotiates capabilities. It then fetches the server's tools, resources, and prompts. When the model requests a tool, the host checks permissions and sends a JSON-RPC tools/call message. The server runs the action and returns the result, which the host passes back to the model. The model never contacts the server directly.
Why is MCP not just a REST API?
REST describes resources and HTTP verbs, and clients usually learn endpoints from documentation. MCP uses JSON-RPC messages, discovers capabilities at runtime, and lets servers send requests back through sampling and elicitation. Those two-way features are the main difference. A REST API can't ask the model for a completion mid-task without extra plumbing.
When should I use MCP instead of function calling?
Use MCP when one server should serve several AI hosts, or when the tool needs to request input from the model or user during execution. If you're building a single app against a single API, provider function calling is simpler and has less moving parts. The added complexity of MCP pays off mainly through reuse across clients.
Try this before you build anything
The fastest way to learn MCP is to connect one existing server to a host you already use, then read the messages in the log. Watch the tools/list response and the tools/call request for a single prompt. That 10-minute exercise will show you more than any diagram, including how little the model actually sees. Pass this to someone who keeps asking whether MCP is "just an API," and show them the JSON.