October 28, 2026
MCP (Model Context Protocol) Explained starts with a simple idea: AI models can write, reason, and summarise, but they need access to external tools and data to perform real-world tasks. An AI agent may need to check your calendar, query a database, retrieve files, or open a support ticket. Traditionally, each connection required a separate custom integration, making it difficult to scale AI applications across multiple services.
The Model Context Protocol (MCP) addresses this problem by providing a standardised way for AI applications to connect with external tools, data sources, and services. Anthropic introduced MCP as an open standard in November 2024, and the protocol has since moved under Linux Foundation governance. This guide explains how MCP works, why AI agents depend on it, what has changed in the latest specification, and the security risks developers should understand before adopting it.
What MCP actually is
MCP is a protocol, not a product or a library. It defines a common way for an AI application to discover and use external capabilities. Think of it as a shared plug shape: any app that speaks MCP can connect to any server that speaks MCP.
Three roles make it work:
- Host: the AI application the person uses, such as a chat assistant, a code editor or an agent platform.
- Client: the connector inside the host that maintains the link to one server.
- Server: a program that exposes capabilities from a system, such as a ticketing tool, a file store or an analytics database.
The model never talks to a server directly. The client passes the server’s capabilities to the model, the model decides what to use, and the host carries out the call, which is where permission prompts live.
Servers offer three kinds of capability:
- Tools: functions the model can call, each with a name, a description and a schema for its inputs, such as search_issues or create_invoice.
- Resources: context the application can read, such as a document or a database record.
- Prompts: reusable templates a user can pick.
A typical interaction runs like this. The client asks a server what it offers. The model reads the tool list, picks a tool that fits the user’s request, and the client sends the call. The server runs it and returns a result, which the model uses to answer or to take the next step. Because the tool list is discovered at runtime, you can add a capability to a server without rewriting the AI application.
Why agents, specifically, need it
A chatbot answers questions. An agent pursues a goal across several steps: look something up, decide, act, check the result, continue. That loop has three needs that MCP addresses directly.
Discovery. An agent has to learn what it can do in the current environment. With MCP, the tool list is machine-readable and self-describing, so the agent isn’t limited to what a developer hard-coded in advance.
Action with accountability. Reading data is low-risk. Sending an email or changing a record is not. Since every action passes through a standard channel, a host can ask for consent, log the call and apply policy in one place, instead of separately for each integration.
Portability. A server built once works with any compliant host. That changes the economics for service providers: build one MCP server and every major agent platform can use it. Companies in sectors from advertising to analytics have been shipping servers for this reason, including write access in some cases.
MCP doesn’t make a model smarter or more reliable. It standardises the connection. A weak model with excellent tools still makes poor decisions, and a strong model with badly described tools misfires.
How it differs from things it’s often confused with
| Approach | What it is | Where MCP differs |
| A plain REST API | An interface designed for developers to call from code | MCP wraps capabilities in self-describing form so a model can discover and choose them at runtime |
| Function calling | A model feature for emitting structured calls to functions you define in your app | Function calling is how a model asks for an action. MCP standardises where those functions come from and how they’re served, across apps |
| Retrieval-augmented generation | Fetching documents to include in the prompt | RAG is a pattern for supplying context. An MCP server can implement retrieval, but MCP also covers actions |
| A plugin store | A closed, vendor-specific extension system | MCP is an open spec that any vendor can implement |
They work together. An agent might use function calling to emit a call, MCP to reach the server, and RAG inside that server to find the answer.
What changed in 2026: the stateless specification
MCP specifications are named by release date. The current one, 2026-07-28, shipped on 28 July 2026 and follows earlier revisions in 2024 and 2025. Its maintainers describe it as the largest revision since launch. The headline is that the protocol no longer has sessions.
Before. A client opened a connection with an initialize handshake, received a session identifier, and attached it to every later call. That pinned traffic to whichever server instance had started the session, so running a server at scale meant sticky routing and a shared session store.
Now. Each request is self-contained. The protocol version, client information and capabilities that used to be sent once at connection time travel in a metadata field on every call. A new server/discover method lets a client ask what a server supports on demand. The practical result is that any server instance can handle any request, so a remote MCP server can sit behind an ordinary load balancer.
Other notable changes include:
- Routing headers. The HTTP transport carries Mcp-Method and Mcp-Name headers, so gateways and rate limiters can route by operation without parsing the body.
- Caching hints. List and read results can include a time-to-live and a cache scope, modelled on HTTP caching, so clients can avoid refetching tool lists.
- Tracing. Standard trace-context keys let one tool call be followed through the host, client, server and downstream systems in an OpenTelemetry-compatible backend.
- Multi-round-trip requests. When a server needs input mid-call, such as confirming a destructive action, it returns an input_required result with a state token. The client gathers the answer and retries with the token attached, so any instance can resume the work.
- Extensions with a governance track. Extensions get reverse-DNS identifiers, negotiated capabilities and an independent versioning cycle. Two ship as official: MCP Apps, which lets a server provide interactive HTML interfaces rendered in a sandbox by the host, and Tasks, for long-running work that returns a handle instead of an immediate result.
- Authorization hardening. Several changes align MCP with real-world OAuth and OpenID Connect practice, including client validation of the iss parameter to defend against mix-up attacks.
- Deprecations with a policy. Roots, sampling and structured logging are marked deprecated, but they keep working, and the new lifecycle policy requires at least twelve months between deprecation and any removal.
- Smaller breaking changes. Tool schemas now support full JSON Schema 2020-12, and a missing-resource error now uses the standard JSON-RPC invalid-params code instead of an MCP-specific one.
Statelessness doesn’t forbid stateful applications. A server that needs memory across calls can hand back an explicit handle, such as a basket ID, and expect the model to pass it back as an argument, the same pattern web APIs have used for years.
What this means if you build servers or agents
The release candidate appeared in May and the final spec in late July, and SDKs adopt new revisions at their own pace. Older revisions can stay in use for some time. A sensible approach:
- Check your SDK’s supported revision before assuming a feature exists, and use version negotiation rather than hard-coding one.
- Audit session assumptions. Anything that relied on a session ID or a handshake needs a redesign, usually into explicit handles.
- Update error handling if you match on the old missing-resource code.
- Move off the experimental Tasks interface. The old tasks/list method was removed, so migrate to the extension.
- Plan for stricter authorization. Make sure your authorization server supplies the iss parameter, since a future revision is expected to require it.
- Stop building on roots, sampling and logging for new work, even though they still function.
A minimal server is small. Here’s a sketch using the official Python SDK’s high-level interface, which you should check against the SDK’s current documentation:
python
from mcp.server.fastmcp import FastMCP
mcp = FastMCP(“order-status”)
@mcp.tool()
def get_order_status(order_id: str) -> dict:
“””Return the current status of an order, given its ID.”””
# Look up the order in your own system here.
return {“order_id”: order_id, “status”: “shipped”}
if __name__ == “__main__”:
mcp.run()
The docstring matters more than it looks. It’s what the model reads to decide whether to use the tool, so a vague description produces bad tool choices.
The security reality
MCP’s growth has brought an attack surface that deserves honest treatment. Researchers have reported many vulnerabilities in MCP servers and tooling, and commentators generally note that the serious ones have come from implementation choices, defaults and trust assumptions, not from the protocol’s message format.
The main patterns:
- Prompt injection through tool output. Agents tend to treat what a tool returns as trustworthy. A server that reads user-generated content, such as issues, emails or web pages, can pass hidden instructions to the model.
- Tool poisoning. The term was coined by Invariant Labs in April 2025. Malicious instructions hide in a tool’s description or schema, text the model reads but the user usually never sees. Unlike a single injected message, it persists for as long as the tool stays installed.
- Rug pulls and supply chain compromise. A server can behave well at first and change later. In September 2025, a backdoor was reported in a widely installed email-related MCP server.
- Unauthenticated and over-permissioned servers. Servers with no authentication, or agents granted far more access than a task needs, turn small mistakes into large ones.
- Cross-server contamination. When one agent connects to several servers, a compromise of one can influence how it uses the others.
Practical defences are not exotic:
- Connect only to servers you control or have reviewed, and pin versions instead of auto-updating.
- Grant the narrowest permissions the task needs, and keep read access separate from write access.
- Require human confirmation for destructive or irreversible actions, and think twice before enabling auto-approval.
- Log every tool call, and route remote servers through a gateway that can enforce policy.
- Write factual tool descriptions, and treat all tool output as untrusted input.
The new spec helps with some of this, notably stronger authorization alignment and the pre-declared, reviewable interface templates in MCP Apps, but it doesn’t remove the need for these habits.
Build Your AI Foundations with Saiket Systems Internships 2026
AI agents and protocols like MCP are easier to learn once you’re comfortable with Python, data handling and basic machine learning. Students and freshers can build those foundations through the Saiket Systems Internship Program, which offers domains such as Python Developer, Machine Learning, Data Science and Software Development, with a focus on practical projects. The program doesn’t list an MCP-specific track, and details like duration and eligibility may vary by role, so review the current information before applying.
Ready to get started? Explore the domains and apply through the official Saiket Systems Internship page.
When MCP is the wrong choice
Not every integration needs it. If you have a single application calling a single internal service, a direct API call is simpler and easier to secure. If a task is a fixed workflow with no decisions in it, ordinary code beats an agent. MCP pays off when several agents or hosts need the same capabilities, when tools should be discoverable at runtime, or when you want one governed channel for actions.
What to watch for the rest of 2026
The project’s public roadmap named four priorities for the year: transport scalability, agent-to-agent communication, governance maturity and enterprise readiness. The 2026-07-28 release delivers most directly on the first two. Enterprise needs such as audit trails, configuration management and single sign-on were described as the least defined, which makes them the areas to follow. Also watch how quickly SDKs and hosts adopt the new revision, how the extensions track fills out, and whether a shared conformance suite makes compatibility claims easier to trust.
Frequently asked questions
Is MCP only for Claude? No. It’s an open standard, and hosts from several vendors and many developer tools support it.
Do I need to learn it if I only use AI chat apps? Not to use it. Many apps let you connect services through ready-made connectors. You need to understand it if you build integrations or evaluate which connectors to trust.
Does the stateless change break existing servers? Servers on older revisions can keep working for a while, but the change affects how they handle sessions and handshakes when you adopt the new spec, so plan a migration.
Is MCP the same as an AI agent? No. An agent is the decision-making loop. MCP is one way the agent reaches the outside world.
How do I know a server is safe? You can’t be certain from its listing alone. Review what it does, check who maintains it, limit its permissions and monitor its calls.
Sources and further reading
- MCP specification (2026-07-28): https://modelcontextprotocol.io/specification/2026-07-28
- 2026-07-28 changelog: https://modelcontextprotocol.io/specification/2026-07-28/changelog
- Release notes: https://github.com/modelcontextprotocol/modelcontextprotocol/releases/tag/2026-07-28
- Tool poisoning disclosure (Invariant Labs): https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
Last checked 28 October 2026. We’ll update this post when a new specification revision ships.
