An MCP server is a program that gives AI applications something to work with through the Model Context Protocol: tools they can call, resources they can read and prompts users can pick. The application connects through an MCP client, and both sides exchange JSON-RPC 2.0 messages over stdio locally or Streamable HTTP remotely.
| Primitive | What it is | Who decides to use it | Main methods |
|---|---|---|---|
| Tools | Functions that perform an action, with a JSON Schema for their input | The model | tools/list, tools/call |
| Resources | Read-only data addressed by a URI, such as a file or a schema | The application | resources/list, resources/read |
| Prompts | Reusable instruction templates with arguments | The user | prompts/list, prompts/get |
Updated
Step through a real exchange below. Each step shows the JSON a client sends and what the server answers, using the message shapes from the current specification (version 2026-07-28). Reading the raw messages is the fastest way to stop thinking of a server as magic.
{
"jsonrpc": "2.0",
"id": 1,
"method": "server/discover",
"params": {
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": { "name": "demo-client", "version": "1.0.0" },
"io.modelcontextprotocol/clientCapabilities": {}
}
}
}{
"jsonrpc": "2.0",
"id": 1,
"result": {
"resultType": "complete",
"supportedVersions": ["2026-07-28"],
"capabilities": { "tools": { "listChanged": true }, "resources": {} },
"_meta": {
"io.modelcontextprotocol/serverInfo": { "name": "notes-server", "version": "1.0.0" }
}
}
}server/discover is optional for the client but every server must answer it. The capabilities object says which primitives exist; listChanged means the server can notify about tool changes.
| Stdio | Streamable HTTP | |
|---|---|---|
| Where the server runs | Same machine, started by the host | Anywhere reachable over the network |
| How messages travel | Standard input and output streams | HTTP POST, optional Server-Sent Events |
| Typical clients per server | One | Many |
| Authentication | Not needed, it is a local process | Bearer tokens, API keys, custom headers; OAuth recommended |
| Where to log | stderr (stdout carries protocol messages) | Your normal server logs |
Clients find templates with resources/templates/list, fill in the braces and read the result with resources/read.
{
"uriTemplate": "notes://by-tag/{tag}",
"name": "notes-by-tag",
"title": "Notes by tag",
"description": "All notes carrying one tag",
"mimeType": "application/json"
}
Three roles appear in every setup. The host is the AI application the person uses. For each server it connects to, the host creates one client, and each client keeps a dedicated connection to exactly one server.
So a host linked to a file server and a database server holds two clients. The server is simply the program that answers, wherever it runs.
The data layer defines the messages: JSON-RPC 2.0 requests, responses and notifications for discovery, tools, resources and prompts. The transport layer moves those messages and handles connection setup and authorization.
There are two standard transports. Stdio pipes messages through standard input and output between processes on one machine. Streamable HTTP uses HTTP POST from client to server, with optional Server-Sent Events for streaming, and supports bearer tokens, API keys and OAuth.
Servers can also ask the client for things. Elicitation lets a server request more information or a confirmation from the user through the elicitation/create method.
Sampling, where a server asks the host for a model completion, and protocol-level logging are deprecated as of version 2026-07-28. New servers should log to stderr on stdio or use OpenTelemetry.
It usually wraps one. A typical server calls an existing API or database and describes those operations in a standard way, so any MCP-aware application can discover and call them without custom integration code.
Either. A local server is started by the application and talks over standard input and output. A remote server runs elsewhere and is reached over Streamable HTTP, where it can serve many clients.
No. The server only offers tools, resources and prompts. The host application owns the model and decides what to send it. The specification marks server-requested sampling as deprecated as of version 2026-07-28.
The protocol became stateless: every request carries the protocol version and capabilities in its _meta field, and servers answer a mandatory server/discover request. Change notifications are now opt-in through a subscriptions/listen stream.
The host. The protocol documentation suggests approval dialogs, permission settings and activity logs, but enforcing them is the application's job, so a server should never assume a person checked a call.
Related: How to build an MCP server, How to build an AI agent, Connect MCP in We.Inc, JSON Schema generator, Webhook vs API.
Start for free or see all free tools. We.Inc is free to start, with no card needed. AI building is on paid plans from $20 a month.
We.Inc is an AI-powered website builder you can resell under your own brand. Launch a branded client dashboard, bill on Stripe Connect, and deliver AI-generated websites in minutes. White-label plans start at $99 a month for 25 client sites, with a 7-day free trial and no per-site fees.