What is MCP?

Home › What is MCP?

MCP, the Model Context Protocol, is an open protocol for connecting a client to a server that exposes tools and other capabilities. The specification encodes messages as JSON-RPC, and those messages must be UTF-8. The current transport chapter is Transports (2025-06-18). The session rules are in Lifecycle (2025-06-18). This page paraphrases those two chapters and then says what this directory records. It does not add product claims that are not in the spec or on a fact sheet.

Clients and servers

The client is the side that starts the session. In practice that is an editor, a desktop chat app, or another host that speaks MCP. The server is the side that offers capabilities. A local server is a process the client starts. A remote server is an HTTP endpoint the client connects to. The spec is transport-agnostic about the message format: implementers can add a custom transport, but they still have to keep the JSON-RPC message format and the lifecycle.

The client should not send normal requests before the server has answered initialize. The server should not send normal requests before it has received the client's notifications/initialized notification. Pings are the exception the lifecycle chapter allows during that gap, and the server may also emit logging before the initialized notification.

Initialization

Initialization is capability negotiation and protocol-version agreement. The client must send an initialize request that includes a protocol version it supports, its capabilities, and client implementation info (clientInfo with a name and version). The spec's example uses protocol version 2025-06-18 and shows client capabilities for roots, sampling, and elicitation. Those are optional features. An empty capabilities object is still a valid shape; the tester on this site sends an empty object and labels itself mcpwell-tester version 0.1.

The server must answer with its own protocol version, capabilities, and serverInfo. It may include instructions, which the spec calls optional instructions for the client. After that response, the client must send notifications/initialized with no id, because it is a notification rather than a request. Only then does the operation phase begin.

Version negotiation is explicit. The client should send the latest version it supports. If the server supports that version, it must answer with the same version. If it does not, it must answer with another version it supports, preferably the latest one it supports. If the client cannot speak the version in the response, it should disconnect. On HTTP, later requests must include the MCP-Protocol-Version header set to the negotiated version. The transport chapter says that if that header is missing and the server has no other way to know the version, the server should assume 2025-03-26. An unsupported header value is a 400.

Capabilities

Capabilities decide which optional features exist for the rest of the session. Both sides must use only what was negotiated. The lifecycle chapter lists client capabilities roots (filesystem roots), sampling (LLM sampling requests), elicitation (the server asking the user for more information), and experimental. Server capabilities are prompts, resources, tools, logging, completions, and experimental. Sub-capabilities include listChanged on prompts, resources, and tools, and subscribe on resources.

A server that did not negotiate tools is not offering tools. A registry entry on MCPwell often does not include the live capability list. The fact sheet then says the entry did not publish a tool list, instead of guessing one. The tester can show the capabilities object a live endpoint returns, and that result is from your browser, not from the registry.

stdio

In the stdio transport the client launches the server as a subprocess. The server reads JSON-RPC from standard input and writes JSON-RPC to standard output. Messages are newline-delimited and must not contain embedded newlines. The server may write UTF-8 logs to standard error. It must not write anything to stdout that is not a valid MCP message, and the client must not write anything to the server's stdin that is not a valid MCP message. The spec says clients should support stdio whenever possible.

Shutdown for stdio has no special MCP message. The client should close the input stream, wait for the process to exit, send SIGTERM if it does not, and SIGKILL if it still does not. The server may shut down by closing its output stream and exiting. A fact sheet that says "stdio (local)" means the registry package or the reference README describes that kind of local process. For those servers, the schema on the fact sheet uses operating system "Windows, macOS, Linux" because a local stdio process is what the client launches on the machine where the client runs. That string is not a claim that the vendor tested a specific OS version.

Streamable HTTP

Streamable HTTP replaces the HTTP+SSE transport from protocol revision 2024-11-05. The server is an independent process and exposes one HTTP endpoint that supports POST and GET, for example https://example.com/mcp. Every JSON-RPC message from the client is a new POST. The client must send Accept with both application/json and text/event-stream. A request can be answered with one JSON object or with an SSE stream that eventually carries the JSON-RPC response. A notification or response, as opposed to a request, is answered with HTTP 202 and an empty body when the server accepts it.

The client may also GET the endpoint to open an SSE stream for server-initiated messages. If the server does not offer that, it returns 405. The server may assign a session id in the Mcp-Session-Id header on the initialize response. The id should be globally unique and cryptographically secure, and it may only contain visible ASCII from 0x21 to 0x7E. If the server assigned one, the client must send it on later requests. The server may end a session at any time and then answer that id with 404, which tells the client to initialize again without a session id. The client should send HTTP DELETE with the session id when it is done, and the server may answer 405 if it does not allow the client to end the session.

The transport chapter's security warning says servers must validate the Origin header, should bind to localhost rather than all interfaces when they run locally, and should authenticate connections. Those are requirements on implementers. This directory does not test whether a given endpoint does them.

Older HTTP+SSE servers can still be reached. A client that wants compatibility posts initialize first. If that fails with an HTTP 4xx such as 405 or 404, the client GETs the URL and looks for an SSE endpoint event, which is the older transport. Fact sheets on this site use the words "SSE (remote)" only when the registry entry says the remote type is SSE.

Operation and shutdown

During operation, both sides respect the negotiated version and capabilities. The spec does not define a shutdown RPC. For HTTP, shutdown is closing the connection. Implementations should set timeouts on requests. On timeout, the sender should cancel the request and stop waiting. A progress notification may reset a timeout clock, but the spec says there should still be a maximum timeout. Error cases called out in the lifecycle chapter include a protocol version mismatch, a failure to negotiate a required capability, and request timeouts.

What this directory adds

MCPwell lists a server when the official MCP Registry namespace is the vendor's (a domain they verified, or their GitHub organization) or when the server is a reference server from the modelcontextprotocol/servers repository or Microsoft MarkItDown. Unofficial wrappers are not given the vendor's name. Each fact sheet shows transport, declared credentials, the source URL, and the date that record was checked. Install snippets are built only from packages and remotes on that record. Descriptions are our wording. Listings are not ranked by traffic or by payment. Sponsorship, when a placement exists, is labelled and does not change those facts.

Client setup pages for Claude, Cursor, and VS Code quote the config shape from each vendor's docs and, separately, show a command or URL taken from a registry entry. The two sources are named on those pages.

FAQ