Model Context Protocol (MCP) Explained
A practical guide to Model Context Protocol: how MCP connects AI applications to tools and data, what changed in the 2026-07-28 spec, and how to use it safely.
Model Context Protocol (MCP) is an open protocol connecting AI applications to external tools and data. Developers can implement an MCP client or server and reuse standard concepts for discovery and invocation.
MCP is not an AI model, database, or agent framework. It is a communication layer. The host application still decides which model to use, which servers to trust, what the user can authorize, and how results are validated.
If you are new to agents, read how agentic AI works. Developers can also browse AI coding tools and implementation guides.
MCP in plain English
Think of MCP as an adapter between an AI host and outside capabilities. A server can expose:
- Tools: actions the application can invoke, such as creating an issue or querying a service.
- Resources: data the application can read, such as files or records.
- Prompts: reusable prompt templates supplied by a server.
The user-facing host creates clients that communicate with servers. The model may recommend a call, but the host should enforce permissions and approvals.
| Component | Responsibility | Example |
|---|---|---|
| Host | User experience, model access, consent, policy | An AI-enabled IDE |
| MCP client | Protocol communication with a server | Client embedded in the host |
| MCP server | Publishes bounded capabilities | A source-control integration |
| External system | Stores data or performs the real action | Git provider, database, CRM |
This separation makes integrations reusable, but it does not make every server safe or compatible.
How an MCP request works
A simplified flow is:
- The host connects to or configures an MCP server.
- The client learns which capabilities the server exposes.
- The model receives descriptions of allowed tools or resources.
- The model proposes a call with structured arguments.
- The host applies consent and policy checks.
- The server invokes the external system and returns structured content.
- The host gives the result back to the model or user.
MCP uses JSON-RPC and supports local and remote deployments. Transport affects authentication, exposure, and operations. A local stdio server is not automatically trustworthy, nor is remote HTTP automatically unsafe.
What changed in the 2026-07-28 specification
The official MCP page presents 2026-07-28 as the authoritative specification and defines a stateless, self-contained request model. Its announcement says the initialize/initialized exchange and Mcp-Session-Id header were retired. Protocol version and capabilities now travel with each request; server/discover supports up-front discovery.
Google’s August 5, 2026 article calls 2026-07-28 a specification release candidate and SDK support beta. Because these official sources use different maturity language, verify your SDK, host, and server versions rather than assuming universal production support.
Applications may still retain explicit state—for example, through a handle supplied on each relevant request—without relying on one connection or server instance to remember prior calls.
| Before the revision | 2026-07-28 model |
|---|---|
| Initialization handshake established protocol context | Each request carries required protocol context |
| Session header could identify a logical session | Protocol-level session header removed |
| Connection history could shape handling | Server processes requests independently |
| Stateful routing could be necessary | Ordinary load balancing is easier in principle |
Statelessness may simplify horizontal scaling and recovery, but it does not eliminate application databases, authentication, authorization, replay protection, or task tracking.
When MCP is useful
MCP helps when multiple AI applications need one capability or one host needs many integrations:
- Giving coding assistants controlled access to repositories and issue trackers.
- Connecting internal assistants to approved knowledge sources.
- Exposing a business API with model-readable schemas.
- Reusing one tool server across compatible development environments.
- Separating model orchestration from integration maintenance.
For one small application with one stable API, direct function calling may be simpler. Protocol adoption adds dependencies, version compatibility, and another security boundary.
MCP versus related approaches
| Approach | Best when | Tradeoff |
|---|---|---|
| Direct API integration | One application and a few known services | Tight coupling and repeated integration work |
| Function/tool calling | Model needs app-defined functions | Usually specific to the application or provider |
| MCP | Capabilities should be discoverable and reusable | Requires compatible clients, servers, and policy |
| Agent-to-agent protocol | Independent agents need to coordinate | Solves a different, higher-level communication problem |
MCP can coexist with these approaches. A host might use MCP for tool access, direct APIs for a latency-sensitive path, and an agent framework for orchestration.
Security and reliability limitations
An MCP server can become a bridge to sensitive data or destructive actions. Tool descriptions, resource content, and third-party data should be treated as untrusted. Prompt injection can attempt to persuade a model to reveal data or call unrelated tools.
Other risks include malicious servers, dependency compromise, overly broad credentials, tool-name collisions, schema changes, data exfiltration, duplicate calls, and confused-deputy problems where an agent uses the user’s authority incorrectly.
Use operating-system or container isolation where appropriate. Keep credentials outside prompts and server responses. Require confirmation for consequential actions, validate arguments in deterministic code, return minimal data, and record auditable calls. Do not install an MCP server merely because it appears in a directory.
Implementation checklist
- Confirm the host, SDK, and server support the same protocol revision.
- Prefer official or inspectable server implementations.
- Pin and review dependencies; plan updates deliberately.
- Grant separate, least-privilege credentials per server.
- Allowlist tools and resources needed for the use case.
- Validate every input independently of model instructions.
- Require approval for writes, messages, purchases, and deletions.
- Make retryable write operations idempotent.
- Log tool identity, arguments, result status, and user approval.
- Test prompt injection, malformed responses, timeouts, and version mismatch.
Begin with read-only resources and one low-risk tool. Add capabilities only after observing real traces and failure modes. Compare architectural choices in local LLM vs cloud AI and explore AI platform comparisons.
FAQ
Does MCP let a model access everything on my computer?
No—not by definition. Access depends on the installed server, its credentials, the host’s controls, and user approvals. A badly configured server can still expose too much.
Is MCP only for local desktop tools?
No. MCP supports architectures involving local processes and remote services. Authentication and transport security need to match the deployment.
Does the stateless specification remove all sessions?
It removes reliance on protocol-level session state. Applications can maintain explicit state through identifiers and their own storage. Long-running work still needs careful lifecycle design.
Is MCP the same as tool calling?
No. Tool calling is a model or API capability. MCP standardizes how applications discover and communicate with external capabilities. Hosts often present MCP tools to a model through tool calling.
Should every API become an MCP server?
Not necessarily. Use MCP when interoperability and discovery justify the operational and security overhead. A direct integration can remain the clearer choice for a narrow, stable path.