This article is part of our MCP Guide: what the Model Context Protocol is, how to use it safely, and how to choose servers, tools and help. Want a second opinion on your setup? Request a free MCP readiness review.
MCP works by giving an AI app a standard way to discover what another program can do, and then to ask it to do those things. The AI app is the host. Inside it, one client connects to each MCP server. Each server exposes tools (actions), resources (data) and prompts (templates).
Every message follows JSON-RPC 2.0, a simple format for one program to call functions in another. Messages travel over one of two transports: standard input/output for servers on your own computer, or HTTP for servers on the internet.
This guide walks through each part in plain English. It follows the MCP specification dated 2026-07-28, the latest version as of October 2026.
Key Takeaways
- An MCP setup has three roles: the host (the AI app), clients (one connector per server) and servers (programs that expose tools and data).
- Servers offer tools the model can call, resources the app can read, and prompts the user can pick.
- Local servers usually run over stdio on your machine; remote servers use Streamable HTTP and typically OAuth for sign-in.
- Since the July 2026 spec, MCP is stateless: every request carries its own version and capability details.
- When a server needs more input, it returns an "input required" result and the client retries with the answer.
- The spec expects a human in the loop who can approve or deny tool calls.
The three roles: host, client and server
The MCP architecture overview defines three participants:
| Role | Definition from the docs | Plain-English version |
|---|---|---|
| MCP host | "The AI application that coordinates and manages one or multiple MCP clients" | The app you type into, such as Claude Desktop or VS Code |
| MCP client | "A component that maintains a connection to an MCP server" | A connector the host creates for each server |
| MCP server | "A program that provides context to MCP clients" | The bridge to a tool, such as GitHub, Stripe or a database |
The host creates one client for each server. If you connect three servers, the host runs three clients. Each client keeps a dedicated link to its server.
The docs give a concrete example. When VS Code connects to the Sentry MCP server, it creates one client. When it also connects to a local filesystem server, it creates a second client.
Two layers: data and transport
MCP separates what is said from how it travels.
- Data layer: the JSON-RPC messages themselves. This covers discovery, tools, resources, prompts and notifications.
- Transport layer: the channel that carries those messages, including connection setup and authorization.
So a tool call looks the same whether the server is on your laptop or in the cloud.
Local vs remote: the two transports
The spec defines two standard transports:
| Transport | How it works | Typical use |
|---|---|---|
| stdio | The client launches the server as a subprocess and talks through standard input and output | Local servers, such as a filesystem tool |
| Streamable HTTP | Each message is an HTTP POST to one MCP endpoint; replies come back as JSON or a short-lived event stream | Remote servers hosted by a vendor |
A local stdio server typically serves one client. A remote server can serve many. For HTTP servers, the authorization spec is based on OAuth 2.1, the same family of standards behind "Sign in with Google" style flows. Local stdio servers instead read credentials from their environment.
The three server building blocks
The server concepts page describes three primitives. Each one has a different "owner" who decides when it is used.
| Building block | What it is | Who controls it | Example |
|---|---|---|---|
| Tools | Functions the model can call to take actions | The model | Search flights, send a message, create an event |
| Resources | Read-only data that gives context | The application | A document, a calendar, a database schema |
| Prompts | Reusable instruction templates | The user | "Plan a vacation," "Summarize my meetings" |
Tools
A tool has a name, a description and an input schema. The schema lists the inputs the tool expects, such as a city and a date. The AI reads these descriptions and decides when a tool fits the user's request.
Tools can also return structured data checked against an output schema. Optional annotations hint at behavior, such as whether a tool is read-only or destructive. The schema warns these are only hints. Clients should not trust them from untrusted servers.
Resources
Each resource has a unique URI, such as file:///path/to/document.md, and a MIME type. Resource templates use placeholders, such as weather://forecast/{city}/{date}, for flexible lookups. The host app decides how to use a resource: show it in a picker, search it, or pass it to the model.
Prompts
Prompts are templates a user picks on purpose, often through slash commands or menus.
A request, step by step
Here is what happens when you ask an AI app, "What's the weather in San Francisco?" with a weather server connected. It follows the walkthrough in the architecture docs.
- Discovery (optional). The client can send
server/discoverto learn the server's supported versions and capabilities. Every server must answer this request. - List tools. The client sends
tools/list. The server replies with each tool's name, description and input schema. - Combine tools. The host merges tools from all connected servers into one list the model can see.
- Model picks a tool. Reading your question, the model decides to call
weather_currentwithlocation: "San Francisco". - Approval. The host can show the call and ask you to approve it. The spec says there should always be a human able to deny tool calls.
- Call the tool. The client sends
tools/callwith the tool name and arguments. - Return the result. The server replies with content, such as text. The host passes it back to the model, which writes your answer.
Every request carries the protocol version and the client's capabilities in a _meta field. That is what "stateless" means: the server needs no memory of earlier requests.
When a server needs more information
Sometimes a server cannot finish without asking the user something. MCP handles this with a pattern called multi round-trip requests.
The server replies with an "input required" result that lists what it needs. The client gathers the answer and retries the original request with it attached. The most common case is elicitation, where the server asks the user for details or a confirmation.
The client concepts page describes two elicitation modes. Form mode collects structured answers in the app. URL mode sends the user to a web page, which suits sensitive steps like entering credentials. The docs say servers must not use form mode for passwords, API keys or payment details.
Staying up to date: notifications
Servers can change. A tool may appear, disappear or update. Clients that care can open a long-lived subscriptions/listen stream and choose which change notices they want, such as "tool list changed." The server then pushes notices on that stream.
Servers can also tell clients how long a list stays fresh. The July 2026 changelog added ttlMs and cacheScope fields for this.
Extensions: optional extra features
Beyond the core protocol, MCP defines opt-in extensions. Both the client and server must support an extension for it to be used.
- Tasks: lets a server return a durable task ID for long jobs, which the client polls until done.
- MCP Apps: lets a server show interactive UI, such as charts or forms, inside the chat in a sandboxed frame.
- Skills over MCP: lets a server share packaged workflow instructions that the host loads on demand.
See MCP Apps, Tasks and Skills explained for more.
What changed from earlier versions
If you read older guides, you will see an "initialize" handshake and server-assigned session IDs. The 2026-07-28 changelog removed both. It also deprecated three client features: roots, sampling and logging. They still work during a deprecation window but new builds should avoid them. Our summary of the July 2026 spec changes has the full list.
Where security fits
MCP itself cannot enforce safe behavior. The specification puts that duty on the apps and servers, built on user consent, data privacy and tool safety.
For remote servers, the authorization spec requires the server to accept only tokens issued for it. This blocks a risky shortcut called token passthrough. Read MCP security risks and MCP authentication and OAuth 2.1 for the details.
Next step
Now that you know how the parts fit, the next question is usually how MCP compares with the APIs your tools already have. Read MCP vs API to see when each one makes sense. For a hands-on view of real servers, browse MCP examples by department.
Frequently asked questions
What is the difference between an MCP host and an MCP client?
The host is the AI app you use, such as Claude Desktop or VS Code. A client is a component the host creates to talk to one specific server. One host can run many clients at once, one per connected server.
Does MCP use REST or JSON-RPC?
MCP messages use JSON-RPC 2.0. On remote servers, those messages travel inside HTTP POST requests to a single endpoint. So HTTP is the transport, but the message format is JSON-RPC rather than a REST design.
What is the difference between a tool and a resource?
A tool is an action the AI model can choose to run, such as creating an invoice. A resource is read-only data the app can pull in as context, such as a file. Tools are controlled by the model; resources are controlled by the app.
Is MCP stateful or stateless?
As of the 2026-07-28 specification, MCP is stateless. Each request includes its protocol version and the client's capabilities, so servers do not keep session state between calls. Servers that need state, like a shopping cart, return an explicit ID the AI passes back on later calls.
Do MCP servers run on my computer or in the cloud?
Both are possible. Local servers usually run on your machine over stdio. Remote servers run on the vendor's infrastructure and connect over Streamable HTTP, usually with an OAuth sign-in.
Can the AI take actions without asking me?
That depends on the app and your settings. The specification says hosts must get explicit user consent before invoking tools and should keep a human able to deny calls. Many apps let you pre-approve safe actions, so review those settings carefully.
