Search

Home › Learn › What is an MCP server?

What is an MCP server?

Updated 2026-09-23

An MCP server is a program that gives an AI application a set of well-defined capabilities over a standard wire protocol. The Model Context Protocol (MCP) is an open protocol built on JSON-RPC 2.0. The specification describes it as a standardized way to share context with language models, expose tools to AI systems, and build composable integrations. If you have used the Language Server Protocol, the analogy is deliberate: the spec itself says MCP takes inspiration from LSP.

The current protocol revision is 2026-07-28. Version identifiers are dates, and the spec only bumps the date when a backwards-incompatible change lands.

Host, client, server

The spec splits the world into three roles.

One host typically runs several clients at once, one per configured server. A design principle written into the architecture page is that servers should not be able to read the whole conversation, nor see into other servers. The full conversation history stays with the host; a server only receives what it needs for the request in front of it.

The 2026-07-28 revision also made MCP a stateless protocol: every request is self-contained and carries its own protocol version and client capabilities in _meta.io.modelcontextprotocol/* fields. Servers declare what they support in response to a server/discover request.

The three server primitives

Servers provide functionality through three building blocks. The docs summarise who controls each one.

Tools are functions the model can call. Each tool has a name, a description and a JSON Schema inputSchema. The client discovers them with tools/list and invokes them with tools/call. Tools are model-controlled: the model decides when to use them, which is why hosts usually put an approval step in front of tool execution.

Resources are read-only data sources identified by a URI, such as file:///path/to/document.md, each with a MIME type. Clients list them with resources/list, read them with resources/read, and can discover parameterised URI patterns through resources/templates/list. Resources are application-controlled: the host decides which ones to pull into context.

Prompts are reusable, parameterised instruction templates, exposed through prompts/list and prompts/get. They are user-controlled: a person picks one explicitly, often through a slash command or a command palette.

A server may implement any subset of these. On the client side, the current spec defines elicitation (a server asking the user for more information mid-request) as a client feature, and optional extensions cover long-running Tasks, Skills over MCP, and MCP Apps for inline UI.

Two standard transports

Protocol semantics are the same on every transport. A transport is a binding that defines how messages are framed and delivered. The spec defines two standard bindings.

stdio

The client launches the server as a subprocess. The server reads JSON-RPC messages from stdin and writes them to stdout, one message per line, with no embedded newlines. The server may log to stderr, and clients should not treat stderr output as an error. Two rules matter for anyone writing a server: the server must not write anything to stdout that is not a valid MCP message, and it should exit promptly when stdin is closed, because closing the input stream is the portable shutdown signal.

stdio is what you get when a configuration says "command": "npx" or "command": "uvx": the host spawns the process on your machine, with your user's privileges.

Streamable HTTP

The server runs as an independent process that can serve many clients over HTTP. It exposes a single MCP endpoint, for example https://example.com/mcp, that accepts POST. Every JSON-RPC request or notification is its own POST; the client sends an Accept header listing both application/json and text/event-stream, and the server answers each request with either one JSON object or a request-scoped Server-Sent Events stream that carries progress notifications and then the final response. Each POST must also carry an MCP-Protocol-Version header that matches the version in the body.

The 2026-07-28 revision removed two mechanisms from earlier Streamable HTTP versions: the standalone GET stream and protocol-level sessions (Mcp-Session-Id). The older HTTP+SSE transport from 2024-11-05 is deprecated; new implementations should not adopt it.

The transport page also carries security requirements that come up again and again in practice: servers must validate the Origin header to prevent DNS rebinding, local servers should bind to 127.0.0.1 rather than 0.0.0.0, and servers should authenticate all connections.

Why the distinction matters when you install one

A stdio server is code that runs on your machine. A Streamable HTTP server is a URL you send requests to, usually with a token or an OAuth login attached. The Registry's server.json format records this directly: a packages entry with "transport": {"type": "stdio"} for something you run, a remotes entry with "type": "streamable-http" for something you connect to. mcpnav's Connect block reads those fields and prints the matching command or JSON snippet for each listed server.

The practical consequences of that choice, including credentials, headers and what can go wrong, are covered in Remote vs local MCP servers and the MCP server security checklist.

Sources

All pages accessed 2026-09-23.

Sources