What Is MCP? The Model Context Protocol Explained (2026)

TL;DR. MCP (Model Context Protocol) is an open standard that lets an AI application such as Claude, ChatGPT, Cursor or VS Code talk to outside software in one agreed format. A server exposes tools, resources and prompts; a client inside the AI app calls them over JSON-RPC, either through a local process (stdio) or over HTTP (Streamable HTTP). Remote servers that need a sign-in use OAuth 2.1. The current spec revision, 2026-07-28, made the protocol stateless: no handshake, no session IDs, and a server/discover call that every server must answer. Registries and server cards describe servers so that people and clients can find them, which is where mcp.tc sits.

What MCP is#

The official definition is short: "MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems" (modelcontextprotocol.io). The same page compares it to a USB-C port: one connector that works with many devices.

Before MCP, every AI product wrote its own integration for every service. A GitHub plugin for one assistant did nothing for another. MCP replaces that with a single wire format: a vendor writes one MCP server, and any client that speaks the protocol can use it. Anthropic published the protocol in November 2024; it now has official SDKs in several languages and support in most mainstream AI clients. For you, it means an assistant can read your calendar and open a pull request in the same conversation, as long as you connect the right servers.

Hosts, clients and servers#

The architecture overview names three participants.

The host is the AI application itself: Claude Desktop, Claude Code, VS Code, Cursor, and so on. The host decides what the model sees and when a tool may run.

The client is a component the host creates for each server it connects to. One host can have many clients. The client talks to exactly one server.

The server is a program that provides context and actions. Where it runs does not change what it is. The filesystem server runs on your own machine as a subprocess; the GitHub server runs on GitHub's infrastructure at https://api.githubcopilot.com/mcp/. Both are MCP servers. The first is usually called local, the second remote.

Underneath, every message is JSON-RPC 2.0; the transport only decides how the messages travel.

Tools, resources and prompts#

A server offers three kinds of things, each with a different owner (server concepts).

Tools#

Tools are functions the model can decide to call. Each has a name, a description and a JSON Schema for its input. The client lists them with tools/list and runs one with tools/call. A tool can read, write or delete, so hosts usually ask the user before running one that changes anything; tool definitions can carry hints (read-only, destructive) that help the host decide how loudly to ask.

Resources#

Resources are data the application can read and feed to the model as context: a file, a database schema, an API response. Each has a URI such as file:///projects/app/config.json and a MIME type. Resource templates such as weather://forecast/{city}/{date} cover whole families of URIs. The application, not the model, chooses which resources to load.

Prompts#

Prompts are reusable templates with arguments, exposed through prompts/list and prompts/get. The user picks one, often as a slash command. They are the server author's way of saying "this is how you get the most out of this server."

A tool call on the wire looks like this under the current revision. Note the _meta block: every request carries the protocol version and the client's capabilities, which is what makes the protocol stateless.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "Seattle, WA" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "ExampleClient", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Transports: stdio and Streamable HTTP#

MCP defines two standard transports. They carry the same messages; they differ in where the server lives.

stdio#

With stdio, the client launches the server as a child process and writes JSON-RPC lines to its stdin, reading replies from its stdout. One message per line. Anything the server prints to stdout that is not an MCP message breaks the connection, so logs go to stderr. When the client closes stdin, the server exits. This is the transport for anything that needs your machine, such as the filesystem server.

Streamable HTTP#

Streamable HTTP is the transport for remote servers. The server exposes one endpoint, say https://example.com/mcp, that accepts POST. Every request is its own POST. The server answers either with a single JSON object or with a Server-Sent Events stream scoped to that request, which lets it send progress notifications before the final result. Under the 2026-07-28 revision, each POST must carry the MCP-Protocol-Version, Mcp-Method and, for tool calls, Mcp-Name headers, mirroring values from the body so that load balancers and gateways can route without parsing JSON.

The older HTTP+SSE transport from the first spec revision is deprecated; the spec asks new implementations not to use it.

Adding each kind to Claude Code looks like this (Claude Code docs):

# remote server over Streamable HTTP
claude mcp add --transport http notion https://mcp.notion.com/mcp

# local server over stdio; everything after -- is the server command
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
  -- npx -y airtable-mcp-server

Our connect guide has the same steps for claude.ai, Claude Desktop, ChatGPT, Cursor and VS Code, and the post on adding an MCP server to Claude, Cursor and VS Code walks through each one with examples.

Authentication: OAuth and API keys#

Local stdio servers take credentials from the environment: an API key in an environment variable, a config file, whatever the server documents. The spec explicitly says stdio servers should not use the HTTP authorization flow (authorization spec).

Remote servers are a different matter, because anyone on the internet can reach them. The spec's answer is OAuth 2.1. When a client calls the server without a token, the server replies 401 Unauthorized with a WWW-Authenticate header pointing at its protected resource metadata (RFC 9728), which names the authorization server. The client discovers that server's endpoints, identifies itself, sends the user to a browser to approve, and comes back with an access token. From then on every request carries Authorization: Bearer <token>. Tokens never go in the URL.

In 2026-07-28, clients are expected to identify themselves with Client ID Metadata Documents (an HTTPS URL that serves the client's own metadata); the older Dynamic Client Registration is deprecated and kept only for authorization servers that lack the newer method.

Plenty of remote servers still accept a plain API key in a header. The architecture docs say Streamable HTTP "supports standard HTTP authentication methods including bearer tokens, API keys, and custom headers" and recommend OAuth for obtaining the token. GitHub's server takes both: a browser sign-in, or a personal access token sent as a Bearer header.

What the 2026-07-28 revision changed#

The 2026-07-28 revision is the current one, after a release candidate locked on 21 May 2026 and ten weeks of validation (release post). The changelog lists everything; these changes matter most day to day.

The initialize handshake is gone. Earlier revisions opened a session: the client sent initialize, the server answered with its capabilities, and the Mcp-Session-Id header tied later requests to that exchange. Now every request carries its version and capabilities in _meta, usually with the client's identity too, so in the release post's words each call is "a single self-contained request that any server instance can handle", behind a plain round-robin load balancer. Servers that need state across calls return explicit handles that the model passes back as tool arguments.

server/discover is new and mandatory for servers. It returns supported protocol versions, capabilities, identity and optional instructions in one reply (spec). Calling it is optional for clients: a client can send any request directly and handle an UnsupportedProtocolVersionError, which lists the versions the server does support. On stdio, clients that also support older servers should send server/discover first; if a server answers with something that is not a modern error, it is a legacy server and the client falls back to initialize (versioning).

The HTTP GET stream and resource subscriptions were replaced by subscriptions/listen, a single long-lived POST whose response stream carries only the notifications the client opted in to, such as notifications/tools/list_changed.

Servers no longer send their own JSON-RPC requests. When a server needs user input, it returns a result with resultType: "input_required" and the client retries the original request with the answers attached. The spec calls this Multi Round-Trip Requests.

Roots, Sampling and Logging are deprecated under a new feature lifecycle policy, which normally keeps a deprecated feature for at least twelve months before it can be removed. Tasks, for long-running work, moved out of the core into an official extension, next to MCP Apps and the authorization extensions (extensions overview). List results now carry ttlMs and cacheScope, so a client can cache a tool list instead of polling for it.

A server written against 2025-11-25 or earlier still works with clients that support both eras; the spec's compatibility matrix covers every combination.

Registries and server cards#

A protocol tells clients how to talk to a server. It says nothing about how to find one. Two mechanisms fill the gap.

The official MCP Registry, still labelled preview, is a metadata catalogue backed by Anthropic, GitHub, PulseMCP and Microsoft. Each entry is a server.json that names the server, points to its package or remote URL, and lists its arguments and environment variables. The registry hosts no code. Names are namespaced: io.github.alice/weather requires a GitHub login as alice, while com.example/weather requires proof that you control example.com, through a DNS TXT record or a file at /.well-known/mcp-registry-auth (authentication). The TXT record looks like this:

example.com. IN TXT "v=MCPv1; k=ed25519; p=<base64 public key>"

Publishing is a short sequence with the mcp-publisher CLI (quickstart):

mcp-publisher init
mcp-publisher login github
mcp-publisher publish

The registry's own docs say host applications should not read it directly; downstream directories and marketplaces consume it, add curation, and expose a compatible API.

A server card is the other mechanism: a JSON document the server publishes about itself, so a client that only knows a domain can find the endpoint and learn what it offers. Two conventions exist and have not converged. The earlier proposal, SEP-1649, put the card at /.well-known/mcp/server-card.json; the later SEP-2127 is still an open pull request, now proposed as an extension, and its location has changed several times (the linked revision uses /.well-known/mcp-server-card; the current one recommends {endpoint}/server-card, with domain-level discovery through /.well-known/ai-catalog.json). Neither is part of the core spec. Publishing a card costs little and helps every directory that reads them.

Where mcp.tc fits#

mcp.tc is one of those downstream directories. It listed 536 public MCP servers on 4 October 2026, each with a page at a link like https://mcp.tc/i/github. To build a page, our robot connects to the server the way a client would, lists the tools, checks how sign-in works, and reads the server card, the registry entry and the GitHub, npm or PyPI page when they exist. The page then shows install steps for nine clients plus a generic config for any other, and every install button uses the vendor's own URL or package. Nothing connects through us.

Browse the directory by category. If you maintain a server, the server owners guide explains how a listing is created and kept accurate, and the verification page shows how to earn the checkmark with a DNS record on the server's domain.

Glossary#

Host

The AI application that runs the model and manages clients.

Client

The host's connection to one server.

Server

A program that exposes tools, resources and prompts over MCP, locally or remotely.

Tool

A function the model may call, described by a JSON Schema.

Resource

Read-only data identified by a URI, loaded by the application as context.

Prompt

A reusable template with arguments that the user invokes.

stdio

The transport for local servers, run as a subprocess.

Streamable HTTP

The transport for remote servers, one POST per message, with optional SSE streaming of the reply.

server/discover

The request every server must answer with its supported versions, capabilities and identity.

Protected resource metadata

The document (RFC 9728) a remote server points to in its 401 response so the client can find the authorization server.

Registry

A catalogue of server metadata. The official one is at registry.modelcontextprotocol.io.

Server card

A JSON description a server publishes about itself so clients and directories can discover it.