What is MCP?
Model Context Protocol (MCP) is an open protocol for connecting an AI application to tools, resources, and reusable prompts. A host creates an MCP client for each configured server; the client negotiates capabilities, discovers what the server exposes, and carries protocol messages between the host and server.
MCP standardizes the integration boundary. It does not decide when a model should call a tool, provide agent-to-agent delegation, or make an unsafe tool trustworthy. Those responsibilities remain with the host, model orchestration, authorization layer, and tool implementation.
Current version status
Verified August 6, 2026. The latest MCP specification is 2026-07-28, released on July 28, 2026. It is the largest revision since the protocol launched, and it changes the transport model rather than the primitives:
- The protocol went stateless. The initialize handshake and the protocol-level session are gone. Requests are self-contained, and capability negotiation happens per request. A remote server can now sit behind a plain round-robin load balancer with no sticky sessions and no server-side session state.
- One HTTP request per call. The legacy flow (initialize to obtain an
Mcp-Session-Id, then invoke) collapses into a single POST carryingMCP-Protocol-Version: 2026-07-28,Mcp-Method, andMcp-Nameheaders. The payload remains JSON-RPC 2.0; client information moves into a_metafield within params. - Multi Round-Trip Requests (MRTR) are a new pattern for server-to-client interaction within a request.
- The Enterprise-Managed Authorization extension is stable, letting organizations centrally manage authorization so end users reach all connected servers through a single login.
- Optional extensions now cover Tasks (durable long-running operations), MCP Apps (inline interactive UI), and a Skills over MCP working group.
SDK status: the redesigned v2 TypeScript packages (split @modelcontextprotocol/server, @modelcontextprotocol/client, and @modelcontextprotocol/core) are published with support for the 2026-07-28 revision, but the maintainers label them beta. The latest stable v1 release is @modelcontextprotocol/sdk@1.30.0, a maintenance update targeting the 2025-11-25 specification.
The practical implication: keep production applications pinned to @modelcontextprotocol/sdk@1.30.0 for now, but treat the v2 migration as scheduled work, not a distant possibility — the specification it targets is already the current one. New remote servers are the strongest candidates to start on v2 beta, because statelessness removes most of the deployment complexity that the v1 Streamable HTTP transport carried.
What problem does MCP solve?
Without a protocol boundary, every host-to-tool combination needs a custom adapter:
- provider-specific function schemas;
- bespoke process or HTTP lifecycle code;
- inconsistent discovery and error handling;
- duplicated authentication and configuration;
- integrations that cannot move between compatible hosts.
MCP turns those adapters into reusable servers. A database team can expose a constrained query tool once; multiple compatible hosts can discover and invoke it without rewriting the database integration for each host.
Architecture
MCP Host (AI application)
└── MCP Client (one connection per configured server)
└── MCP Server
├── Tools callable operations
├── Resources readable context
└── Prompts reusable prompt templates
Host: the user-facing AI application. It owns model access, consent, server configuration, and the final decision to expose a server capability to the model.
Client: the protocol participant inside the host. It negotiates capabilities, lists server primitives, sends requests, and handles responses or notifications. Under the 2025-11-25 specification this starts with an initialize handshake and a session; under 2026-07-28, negotiation is carried per request and there is no protocol-level session.
Server: a local process or remote service that exposes bounded capabilities. Servers should keep authorization and domain rules close to the underlying system rather than trusting model-generated arguments.
For local integrations, stdio gives the host direct process ownership and a simple trust boundary. For remote shared services, Streamable HTTP supports network deployment but adds authentication, tenant isolation, origin validation, rate limiting, and operational monitoring. The 2026-07-28 revision removes one large piece of that operational burden: with no protocol-level session, remote servers no longer need sticky routing or shared session storage to scale horizontally.
When should you use MCP?
Use MCP when:
- the same capability must work in more than one compatible host;
- a team owns a reusable tool or context service independently from the AI application;
- discovery and capability negotiation are more maintainable than a hard-coded function list;
- local tools need a standard subprocess contract;
- remote tools need an explicit protocol boundary and lifecycle.
Prefer direct Tool Calling when:
- one application owns one or two stable functions;
- portability is not a requirement;
- the provider’s native tool API is already the simplest boundary;
- another protocol layer would add more deployment and debugging work than reuse.
MCP is not a replacement for Multi-Agent Collaboration. MCP connects a host to capabilities. Agent-to-agent protocols and orchestration define delegation, task state, artifacts, and collaboration between autonomous agents.
Implementation workflow
- Keep business logic independent from the protocol adapter.
- Define narrow input and output schemas.
- Register the tool, resource, or prompt with an MCP server.
- Choose stdio for host-managed local processes or Streamable HTTP for remote service deployment.
- Configure the host with the minimum required environment and permissions.
- Test discovery, valid calls, invalid inputs, downstream failures, cancellation, and authorization separately.
Executed core handler
The repository includes examples/mcp/search-docs.mjs, which keeps searchable document logic separate from MCP transport code. It was executed on July 23, 2026 with:
node --test tests/mcp-search-docs.test.mjs
The test covers a successful match and rejection of an empty query. This verifies the tool’s domain handler, not MCP protocol interoperability.
export function searchDocs(query, documents) {
const normalized = query.trim().toLowerCase();
if (!normalized) throw new Error("query must not be empty");
return documents
.filter((document) => document.text.toLowerCase().includes(normalized))
.map(({ id, title }) => ({ id, title }));
}
TypeScript SDK adapter (illustrative)
The following adapter targets @modelcontextprotocol/sdk@1.30.0, the latest stable v1 release. It is illustrative and was not executed in this repository, because the SDK is not a project dependency.
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import { searchDocs } from "./search-docs.js";
const documents = [
{ id: "mcp", title: "Model Context Protocol", text: "MCP connects hosts to tools." },
];
const server = new McpServer({ name: "docs-server", version: "1.0.0" });
server.tool(
"search_docs",
"Search the approved documentation corpus",
{ query: z.string().min(1) },
async ({ query }) => ({
content: [
{
type: "text",
text: JSON.stringify(searchDocs(query, documents)),
},
],
}),
);
await server.connect(new StdioServerTransport());
Pin the SDK version in a real application and validate the API against the v1 documentation. The v2 packages targeting the 2026-07-28 specification are published but beta; plan the migration deliberately, starting with servers, and review the specification migration notes rather than translating v1 code line by line.
Security and operational boundaries
Treat MCP server installation and tool invocation as privileged operations.
- Validate every argument at the protocol boundary and again where domain invariants require it.
- Enforce authorization in the server or downstream system; never infer permission from the model’s request.
- Require explicit user approval for destructive, financial, or externally visible operations.
- Apply least privilege to local process credentials and remote service tokens.
- For Streamable HTTP, validate origins, authenticate clients, isolate tenants, rate-limit requests, and log tool outcomes without storing secrets.
- Treat tool descriptions, resource content, and tool results as untrusted input that can contain prompt-injection instructions.
- Trace initialization, discovery, calls, latency, errors, cancellations, and downstream side effects.
Failure modes
Tool overload: exposing hundreds of tools can consume context and reduce selection quality. Publish smaller capability sets or route to specialized servers.
Protocol/version drift: copying examples from an unreleased SDK branch can break production imports. Pin stable packages and record the specification version.
Hidden authorization gaps: a correct schema does not prove that the caller may perform the operation. Preserve user and tenant identity through the call chain.
Remote-server ambiguity: network MCP adds normal distributed-systems failures. Define timeouts, idempotency, retry behavior, and cancellation semantics.
Conflating MCP with agent delegation: an MCP tool call is not a stateful remote-agent task. Use an agent-to-agent protocol when the remote party owns planning, task lifecycle, and artifacts.
Frequently asked questions
What is the difference between MCP and tool calling?
Tool calling is the model-facing mechanism for requesting a structured operation. MCP standardizes how a host discovers and communicates with an external capability provider. A host may expose MCP tools through its model provider’s native tool-calling API.
Do I need MCP for a simple chatbot?
Usually not. Direct tool calling is simpler when one application owns a small, stable function set. MCP becomes valuable when capabilities must be reusable across hosts or independently deployed.
Which transport should I use?
Use stdio for local tools whose process lifecycle is owned by the host. Use Streamable HTTP for remote or shared services, accepting the additional authentication, isolation, networking, and observability work. If you are building a new remote server, evaluate the stateless 2026-07-28 transport first — it removes session affinity from the deployment picture entirely.
Does MCP make tools safe?
No. MCP provides protocol structure, not business authorization or trustworthy behavior. Safety depends on schemas, permissions, user confirmation, sandboxing, downstream controls, and audit logs.
Primary references
- Model Context Protocol specification
2026-07-28 - Official MCP blog —
2026-07-28release and stateless transport - Official MCP specification and documentation repository
- Official TypeScript SDK and v1/v2 status
- MCP security best practices
