Where MCP came from and the problem it solves
Anthropic open-sourced Model Context Protocol on November 25, 2024. The goal was to replace fragmented one-off integrations with an open way for AI assistants to connect to content repositories, business tools, and development environments. [1]
MCP does not replace databases or REST APIs. An MCP server normally sits on top of an existing system and exposes capabilities in a form a compatible AI host can understand. [1][4]
What MCP standardizes and what it does not
MCP standardizes discovery and invocation of tools, exposure of resources, and reusable prompt templates. A host therefore does not need custom knowledge of every private API. [4][5][6][7]
The protocol does not define your business logic, application data model, or company permission policy. Those remain implementation responsibilities. [5][8]
Architecture in practice: host, client, and server
| Element | Role |
|---|---|
| Host | AI application coordinating the model, user, and MCP connections. |
| MCP client | Protocol communication layer for a specific server. |
| MCP server | Exposes capabilities and maps them to external data or systems. |
| Tools | Actions invoked by the model. |
| Resources | Data and context identified by URI. |
| Prompts | Reusable prompt templates. |
The classic MCP architecture separates host, client, and server. The host is the AI application, the client implements protocol communication, and the server exposes data and operations. The current release keeps this practical separation while HTTP protocol state no longer has to persist between requests. [15][2]
A single host can connect to multiple MCP servers, for example GitHub, a ticketing platform, and an internal knowledge base. The host decides which capabilities are made available to the model and user. [12][15]
Tools, resources, and prompts: the core server primitives
`Tools` are actions the model can invoke, such as searching an order, creating an issue, or running a calculation. The specification defines a tool name, description, and input schema. [5]
`Resources` expose data identified by URIs, such as files, database schemas, or documentation. `Prompts` expose reusable prompt templates. [6][7]
STDIO, Streamable HTTP, and the old SSE transport
| Transport | Typical use |
|---|---|
| STDIO | Local process, CLI, IDE, developer tooling. |
| Streamable HTTP | Remote server, SaaS service, production infrastructure. |
| HTTP+SSE | Legacy HTTP transport; deprecated in 2026-07-28. |
STDIO is a natural choice for local servers launched as processes by a client application. Streamable HTTP is intended for remote network deployments. [4][2]
In specification `2026-07-28`, the remote core is stateless. Legacy HTTP+SSE is officially deprecated with at least a twelve-month transition window. [2]
What a tool call looks like in current MCP
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": {"q": "invoice 2026"}
}
}Since `2026-07-28`, there is no mandatory `initialize` exchange or `Mcp-Session-Id`. Each request can carry protocol version, client information, and capabilities, while optional `server/discover` lets a client inspect server capabilities first. [2]
For Streamable HTTP, `Mcp-Method` and `Mcp-Name` headers allow gateways, WAFs, and rate limiters to route or meter traffic without parsing the full JSON body. [2]
Practical example: an agent working with a ticketing system
Suppose a company has an internal ticketing platform. Its MCP server can expose `search_tickets`, `get_ticket`, and `update_ticket` as tools, process documentation as resources, and a reusable incident-analysis prompt. The AI host discovers the catalog, the model chooses a tool, and the server maps the call to the private API. [5][6][7]
The architectural benefit is reuse: the same MCP server can later serve multiple compatible hosts instead of reimplementing the integration for each one. [4][12]
Authorization: OAuth 2.1, Bearer tokens, and Client ID Metadata Documents
For HTTP transports, MCP authorization is based on OAuth 2.1 concepts and discovery standards. A protected MCP server acts as a resource server, the MCP client acts as an OAuth client, and access tokens are sent in the `Authorization: Bearer` header. Tokens must not be placed in query strings. [8]
The specification requires audience validation and PKCE where technically capable. In 2026 Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents, while remaining available for compatibility. [2][8]
Security: MCP should not mean full trust
The tools specification requires servers to validate tool inputs, enforce access control, rate limit invocations, and sanitize outputs. Clients should support confirmation for sensitive operations, show tool arguments, use timeouts, and log calls for audit. [5]
The safest production model is least privilege. A documentation-reading server should not receive credentials that can delete production data, and production-changing operations should have additional controls. [5][8][13]
MCP Apps: when a tool result needs an interface
MCP Apps is an official extension that lets tools return interactive interfaces such as forms, dashboards, and visualizations. A tool references a `ui://` resource, which a compatible host can render in a sandboxed iframe. [9]
UI communication remains structured and auditable, and hosts can require consent for tool calls initiated from the interface. [9]
Tasks: long-running operations without holding a connection
MCP Tasks handles operations that take seconds, minutes, or hours. Instead of blocking a connection, a server can return a durable task handle that a client later polls for status and result. [10]
The extension fits CI pipelines, batch jobs, deployments, external queues, and human approval workflows. Current task support requires explicit capability support on both sides. [10][2]
Adoption: Anthropic, OpenAI, GitHub, and developer tooling
OpenAI added remote MCP server support to the Responses API in May 2025 and joined the MCP steering committee. [11]
GitHub Copilot supports MCP across IDEs, Copilot CLI, the Copilot app, and cloud agent workflows. GitHub also provides registry and enterprise management mechanisms for MCP servers. [12][13][14]
MCP vs REST APIs and function calling
A REST API describes a system interface for general clients. Function calling describes how a particular model or API asks for functions. MCP adds a shared discovery, schema, and communication layer between an AI host and a tool server. [4][5]
If you have one model and three private backend functions, MCP may be unnecessary overhead. If the same capabilities must work across multiple hosts or be published as an independent integration, MCP becomes much more useful. [4][11][12]
Production MCP server checklist
A production rollout should start with a small, explicit tool surface. Every tool needs a clear name, precise description, validated input schema, and permissions limited to what it actually requires. [5][8]
For a remote server, build for current Streamable HTTP, implement authorization, metrics, rate limiting, and tracing, and make backward compatibility an explicit decision rather than an accident. [2][8]
- Build for specification `2026-07-28`.
- Keep the tool surface and permissions minimal.
- Validate every argument and result.
- Require confirmation for sensitive operations.
- For HTTP, implement correct OAuth and audience validation.
- Use rate limits, timeouts, audit logs, and tracing.
- Never give a server secrets it does not need.
- Test host compatibility and failure behavior.
What changed in 2026 and where MCP is heading
The major `2026-07-28` changes are the stateless core, removal of the handshake and protocol sessions, cacheable list responses, header-based routing, a formal extension system, and authorization hardening. Roots, Sampling, and Logging are deprecated for new implementations. [2]
The August 2026 roadmap prioritizes agent messaging, webhooks and events, HTTP transport unification, agent identity, enterprise security, and improved SDK developer experience. These are roadmap directions, not all current-spec features. [3]
