What is MCP?
MCP (Model Context Protocol) is an open, versioned protocol that lets AI Hosts use Clients to discover and invoke bounded capabilities exposed by Servers through self-contained JSON-RPC requests.
Quick Facts
| Full Name | Model Context Protocol |
|---|---|
| Created | November 2024 by Anthropic |
| Specification | Official Specification |
How It Works
Roles and scope
A Host is the user-facing AI application and policy boundary. It creates an MCP Client for each direct Server relationship, integrates a model, assembles context, and handles consent. The Client implements protocol exchange; the Server exposes bounded capabilities. MCP does not define the model's reasoning loop, memory, marketplace, billing, business authorization, or backend source of truth. Products may package several roles, but their responsibilities remain distinct.
Stateless current core
In protocol revision 2026-07-28, there is no initialize / initialized handshake or protocol-level Session. Every Request carries io.modelcontextprotocol/protocolVersion and relevant io.modelcontextprotocol/clientCapabilities in _meta; Client and Server identity metadata is self-reported. Servers implement server/discover for supported versions and capabilities, while Clients may call it before an operation or send a direct Request and handle a version error. Application state uses explicit, scoped handles.
Core features and extensions
Servers can expose Tools for model-controlled actions, Resources for application-controlled context, and Prompts for user-selected templates. Clients can support Elicitation for additional user input. Utilities cover progress, cancellation, errors, pagination, caching, and subscriptions. Optional Extensions such as Tasks, Skills over MCP, and MCP Apps use namespaced identifiers, independent specifications, explicit two-sided support, and graceful fallback; Core conformance does not imply extension support.
Transports and compatibility
The current standard bindings are stdio for a Host-launched local process and Streamable HTTP for a remote endpoint. Modern Streamable HTTP uses one POST endpoint and may return JSON or a request-scoped SSE response; the former standalone HTTP+SSE transport is deprecated. Revision 2025-11-25 and earlier uses a stateful lifecycle and must remain an isolated Legacy path. Pin the revision and SDK, test both ends, and never silently mix protocol eras.
Trust, authorization, and evidence
Protocol validity proves message shape, not identity, truth, necessity, or permission. Hosts should verify Server provenance, namespace capabilities, constrain context, preview consequential arguments, and keep outputs untrusted. Servers authenticate callers where applicable, enforce tenant and object policy, validate domain rules, bound results, and make retryable side effects idempotent. Remote OAuth, local process sandboxing, cancellation, observability, deletion, and incident recovery remain deployment responsibilities.
Key Characteristics
- Three logical roles: Hosts own application policy, Clients own protocol relationships, and Servers expose capabilities
- Stateless current requests: revision, Client Capabilities, and relevant identity metadata travel with each Request
- Typed capability surface: Tools, Resources, Prompts, Elicitation, utilities, and Extensions have distinct contracts
- Two standard transports: stdio for local subprocesses and Streamable HTTP for remote endpoints
- Independent optional Extensions: both peers opt in by identifier and preserve a Core fallback or explicit error
- External trust controls: authentication, authorization, consent, sandboxing, idempotency, and audit remain application duties
Common Use Cases
- Connecting an IDE to reviewed local repository and test capabilities over stdio
- Exposing a tenant-aware SaaS or internal API through scoped remote Tools
- Serving authorized documents or records as URI-addressed Resources
- Distributing user-selected Prompt templates or verified Skills to compatible Hosts
- Running long-lived operations through Tasks with approval, recovery, and effect tracking
Example
Loading code...Frequently Asked Questions
How is MCP different from Function Calling or a normal API?
Function Calling is usually a model-provider format for proposing a structured call, while an API exposes backend operations directly. MCP adds standardized roles, capability discovery, transports, results, versioning, and optional extensions between a Host and Servers. A Host may translate MCP Tools into a provider's Function Calling format, but every backend still needs its own authorization and business rules.
Does MCP 2026-07-28 still use initialize and Sessions?
No. The current Core is stateless: every Request carries its protocol version and relevant Client Capabilities, and `server/discover` is available for optional up-front discovery. Initialize, `notifications/initialized`, and protocol-level Session IDs belong to Legacy revisions. Business workflows can still persist state through explicit scoped handles.
Which MCP capabilities are in Core and which are Extensions?
Core defines the roles, JSON-RPC request model, Tools, Resources, Prompts, Elicitation, transports, and utilities. Tasks, Skills over MCP, MCP Apps, and supplementary authorization mechanisms are optional Extensions with their own identifiers and support matrices. Supporting Core MCP does not imply support for any extension.
Should an MCP deployment use stdio or Streamable HTTP?
Use stdio for a reviewed local process launched and sandboxed by the Host. Use Streamable HTTP for a remote service that needs HTTPS, optional OAuth, horizontal scaling, and request-scoped JSON or SSE responses. The standalone HTTP+SSE transport is deprecated. Choose from the target Host's actual support and test cancellation, retries, limits, and credentials.
Does MCP make Tools and Resources safe or authorized?
No. Schemas and metadata describe a contract but do not authenticate a caller, authorize an object, prove content true, or make a side effect idempotent. Hosts enforce provenance, context, consent, and model-facing policy; Servers enforce identity, tenant and object access, domain validation, effect safety, and output limits on every Request.