What is MCP?
MCP (Model Context Protocol) is an open, versioned protocol introduced by Anthropic in 2024 for a Host and its Clients to discover and use capabilities exposed by Servers. It standardizes selected lifecycle and message interactions; it does not itself grant access to a user's data or actions.
Quick Facts
| Full Name | Model Context Protocol |
|---|---|
| Created | November 2024 by Anthropic |
| Specification | Official Specification |
How It Works
MCP separates a Host, the Client connections it manages, and Server processes or endpoints that expose capabilities. A Server can offer Tools, Resources, Prompts, and other features defined by the pinned specification revision. Initialization and capability negotiation let the peers determine what they both support; no Client is required to implement every feature, and Server metadata is not proof that a capability is trustworthy or appropriate for a request. Transport is deployment-specific. A local Host can launch a Server over stdio. A remote deployment should pin the MCP revision, SDK, and supported HTTP transport profile, normally evaluating the current Streamable HTTP profile first. Legacy HTTP-plus-SSE patterns can remain compatibility routes but are not a universal remote default. The size and timing of tool discovery, descriptor loading, and context injection are Host and Client implementation choices, so fixed token costs and an "eager loading" rule are not protocol facts. MCP improves interoperability, not authorization. The Server must still authenticate the caller as appropriate for its topology, enforce tenant and object-level policy for every operation, validate arguments, limit results and side effects, protect credentials, and handle cancellation, retries, audit, deletion, and incidents. Skills, catalogs, marketplaces, billing systems, and Agent frameworks may use MCP, but they are independent ecosystem or product conventions.
Key Characteristics
- Versioned lifecycle: pin the protocol revision and test the exact SDK and feature subset used by each deployment
- Clear roles: a Host manages one or more Client connections; a Server exposes declared capabilities
- Capability negotiation: initialization describes supported features, but does not require universal Client behavior
- Structured interactions: the selected revision defines JSON-RPC message, request, response, notification, and error behavior
- Transport profiles: stdio suits local processes; remote HTTP behavior must match the pinned specification and Client support
- Policy remains external: schemas, annotations, discovery entries, and model decisions are not authentication or authorization controls
Common Use Cases
- A local IDE integration that provides narrowly scoped repository or test capabilities
- A tenant-aware Server that exposes approved read-only business data with result limits
- A controlled adapter that maps stable Tool contracts to an existing API or workflow
- A document retrieval capability that applies source, permission, freshness, and retention filters
- An internal operations integration with explicit approval, idempotency, audit, and rollback behavior
Example
Loading code...Frequently Asked Questions
What problem does MCP solve for AI applications?
MCP gives compatible Hosts, Clients, and Servers a common lifecycle and capability interface, reducing repeated adapter work. It does not make every Client and Server interoperable automatically: pin and test the Host, Client, SDK, protocol revision, transport, authorization flow, and capability subset.
What are MCP Tools, Resources, and Prompts?
Tools describe invokable operations, Resources expose context addressed by a URI-like identifier, and Prompts provide reusable prompt templates. Their exact fields and optional features depend on the pinned specification revision. A Tool schema or a Resource URI never replaces server-side authorization, validation, result filtering, or side-effect controls.
How do I create my own MCP server?
Choose and pin an SDK that supports the required MCP revision, start with one narrow capability, define stable input and output contracts, and test it against the target Host and Client. For local use, constrain the stdio process. For remote use, select the supported HTTP profile and add trusted identity, object-level authorization, limits, observability, cancellation, and rollback before exposing side effects.
Does MCP require eager tool loading or a fixed token budget?
No. The specification defines discovery and capability interactions, while the Host and Client decide when to request, cache, filter, or inject descriptors into a model context. Measure actual token use, selection quality, latency, and task success in the target integration instead of relying on a universal tool count or token estimate.
Does MCP provide authentication and authorization?
MCP alone does not make a caller authorized to access data or execute an action. Deployment-specific authentication can establish a trusted principal, but the Server must still enforce tenant, object, action, purpose, approval, quota, and business-invariant checks on every request. Treat tool descriptions, annotations, prompts, and results as untrusted inputs.