MCP: connect agents to your tools and data

The Model Context Protocol (MCP) is an open standard for connecting AI applications to tools and data. You install or write a server once, and any MCP host that supports its transport can use it: Claude Code, the Claude apps, ChatGPT, Codex, GitHub Copilot in VS Code, Cursor, Gemini CLI and Microsoft Copilot Studio. The current protocol revision is 2026-07-28.

MCP has three roles:

• Host: the AI application you use, such as Claude Code, Claude Desktop or ChatGPT. The host holds the conversation, decides what the model sees and asks you for consent.
• Client: one connection the host opens to one server. A host runs a client per server.
• Server: a program that offers capabilities. It runs on your machine or as a web service.

A server offers three kinds of things:

A server can also ask you a question in the middle of a call (elicitation), for example to confirm an account. Servers never see the whole conversation or each other: the host passes each one only what it needs.

Messages are JSON-RPC, carried by one of two standard transports:

• stdio: the host starts the server as a child process and talks to it over stdin and stdout. Use it for local tools. The server must never print anything else to stdout.
• Streamable HTTP: every message is an HTTP POST to one endpoint, such as https://mcp.example.com/mcp. Use it for shared and hosted servers. The older HTTP+SSE transport is deprecated.

Authorization applies to HTTP servers and builds on OAuth 2.1. The server publishes OAuth Protected Resource Metadata (RFC 9728) so a client can find its authorization server. Clients should identify themselves with Client ID Metadata Documents; Dynamic Client Registration still works but is now deprecated. Tokens must be issued for that one server, travel only in the Authorization header and never be forwarded to another service. Local stdio servers read credentials from their environment instead.

The 2026-07-28 revision changed the plumbing more than the features. MCP is now stateless: there is no initialize handshake and no session ID, and every request carries its own protocol version and capabilities. Servers must answer server/discover. A server that needs input mid-call returns an "input required" result, and the client retries the request with the answer. Roots, Sampling and Logging are deprecated, and long-running tasks moved into an official extension next to MCP Apps (interactive UI inside the chat). You rarely notice: the official SDKs negotiate with older peers, so servers written for 2025 revisions keep working.

Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation on December 9, 2025. The project runs as "Model Context Protocol a Series of LF Projects, LLC", with maintainers, working groups and a public Specification Enhancement Proposal (SEP) process. Seats belong to individuals, not companies. The official MCP Registry at registry.modelcontextprotocol.io publishes metadata about public servers, with namespaces verified through GitHub or DNS. It is still in preview and does not scan code for security problems.

Use MCP when the agent needs live data or actions in a system it cannot see, and you would otherwise copy from that system into the chat:

• Read and update tickets in your issue tracker while fixing the bug they describe.
• Query a read-only replica of the analytics database during an investigation.
• Pull a production error with its stack trace into a debugging session.
• Give the same internal tool to Claude, ChatGPT and Copilot users without building three integrations.
• Let each person sign in with their own account through OAuth, so the agent acts with their permissions instead of a shared key.

Something else often fits better:

Mind the context cost. Every connected server adds tool names and descriptions to what the model reads. Claude Code defers MCP tool definitions by default and loads them through tool search when a task needs them. A host without deferred loading puts every definition in context upfront, so ten servers with 20 tools each can crowd out the code you want the model to read.

1. At session start the host connects to each server and reads its tool list: names, descriptions and input schemas.
2. You ask for something. The model reads the tool descriptions as part of its instructions and picks a tool.
3. The host checks its permission rules and, if a rule or mode requires it, asks you to approve the call.
4. The client sends tools/call with the arguments. The server validates them and runs the tool.
5. The result goes back to the model as text or structured data, and the model carries on.

Steps 2 and 5 are where the risk lives. Tool descriptions are instructions the model follows, and tool results can contain text an attacker wrote. The members section shows how to set servers up in each tool, build your own, and defend both steps.