The Model Context Protocol (MCP) is an open standard that lets an AI application talk to outside systems, such as a CRM, a database, a file store or a ticketing tool, through one common interface. Instead of writing a custom integration for every model and every system, you expose a system once as an "MCP server" and any MCP-capable assistant or agent can use it.
In two years MCP went from an Anthropic side project to the default plumbing for AI agents. It is now supported across the major AI vendors, it moved to neutral governance under the Linux Foundation in December 2025, and the July 2026 specification reshaped it for production scale. That also made it a target: tool poisoning and over-privileged servers are now a real security category.
This guide explains what MCP is in plain terms, what changed in 2025-2026, where it fits in a business architecture, and the controls you need before you connect an agent to anything that matters.
What the Model Context Protocol actually is
Before MCP, connecting a language model to your systems meant writing "function calling" glue for one model provider, then rewriting it when you switched providers or added a second app. Every integration was a one-off.
MCP standardises that layer. It defines how an AI application discovers what an external system can do, how it asks that system to do it, and how results come back. The usual analogy is a USB port for AI: the device (your billing system, your document store) implements the port once, and any compatible host can plug in.
Three roles matter:
- Host: the AI application the user works in, such as a desktop assistant, an IDE, or your own agent service.
- Client: the connector inside the host that speaks MCP to one server.
- Server: a small service that wraps a real system and exposes its capabilities.
Servers expose three kinds of things. Tools are actions the model can call (create a ticket, look up an order). Resources are data the application can read (a file, a record, a report). Prompts are reusable templates the server offers. Most business value today comes from tools and resources.
What changed in 2025 and 2026
Three developments turned MCP from an interesting idea into infrastructure.
Neutral governance. On 9 December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, alongside Block's goose and OpenAI's AGENTS.md as founding projects. The MCP project's announcement states that the existing maintainer-led governance continues. For buyers, this lowers the risk of betting on a single vendor's protocol.
A stateless core. The specification dated 2026-07-28, which followed a release candidate in May 2026, was the largest revision since launch. As the AAIF's summary of the 2026 changes explains, protocol-level sessions were removed: each request carries the metadata the server needs, so there is no session ID header to track. A new discovery method lets a client learn a server's supported versions and capabilities without the old initialise handshake. In practice, a remote MCP server now behaves like any other stateless HTTP service, which makes load balancing and horizontal scaling ordinary.
Extensions instead of a growing core. Optional, versioned extensions (for example, long-running Tasks and interactive "MCP Apps" user interfaces) keep the base protocol small. The release also introduced a formal deprecation policy with a minimum 12-month window, which matters if you are maintaining servers for years.
Where MCP fits in a business architecture
MCP is a connection layer, not an agent framework and not a security boundary. It sits between the model-driven application and your systems of record.
| Layer | What it does | Examples |
|---|---|---|
| Model | Reasons, plans, writes | Frontier API or self-hosted open-weight model |
| Agent / host | Runs the loop, holds the conversation, enforces policy | Your agent service, an IDE, a desktop assistant |
| MCP client and server | Discovers and calls capabilities in a standard way | CRM server, document server, database server |
| Systems of record | Hold the real data and do the real work | HMS, ERP, ticketing, file storage |
Two neighbouring standards are often confused with MCP. Function calling is a model feature: the model emits a structured request to call a function. MCP standardises how those functions are discovered and served across applications. Agent-to-agent protocols such as A2A handle communication between independent agents, often across organisations. We cover that in our post on multi-agent systems and the A2A protocol.
How businesses are using MCP
The strongest uses share a pattern: the agent needs live, permissioned access to a few systems to complete a bounded job.
- Internal knowledge and operations assistants that search documents, read tickets and draft replies, with write actions gated behind approval.
- Developer tooling, where coding agents read repositories, issue trackers and logs through MCP servers.
- Customer support agents that check order status, booking slots or account details, and hand off to a human for anything outside policy.
- Reporting and analytics, where a read-only server over a warehouse lets staff ask questions in plain language instead of waiting for a report.
- Healthcare operations, where a read-only server over appointment and bed data answers front-desk questions, while anything touching clinical records stays behind stricter controls.
For a hospital running a custom hospital management system, a sensible first MCP server is narrow: today's OPD schedule, doctor availability and token status, read-only, with no patient identifiers returned unless the user's role allows it.
The security problem you must design for
MCP's flexibility creates new attack surface. The model reads tool descriptions and tool outputs as text, and anything it reads can try to instruct it.
Tool poisoning. In April 2025, Invariant Labs described tool poisoning: malicious instructions hidden in a tool's description, visible to the model but not to the user. A harmless-looking "weather" tool can carry hidden text telling the model to read a credentials file and pass it along in a parameter. Later research showed the same trick works through any part of a tool's schema and through tool outputs, not only descriptions.
Rug pulls. A server you approved can change its tool definitions after approval. If your host does not pin and re-verify definitions, yesterday's safe tool can become today's exfiltration channel.
Weak protocol-level guarantees. A January 2026 paper, arXiv 2601.17549, argues that MCP has design gaps such as no capability attestation, meaning a server can claim permissions it should not have. The protocol tells you how to talk to a server; it does not tell you whether to trust it.
Ordinary software vulnerabilities. MCP servers and helper packages are software like any other. In 2025 a critical remote code execution flaw (CVE-2025-6514) was reported in the widely used mcp-remote package. Many community servers are small, quickly written and rarely audited.
A practical MCP security checklist
Use this before any MCP server touches real data:
- Run only servers you built or have reviewed. Pin versions and keep an internal registry of approved servers.
- Give each server the least privilege possible: separate read-only and write servers, scoped OAuth tokens, no shared admin credentials.
- Pin tool definitions and alert when a description or schema changes.
- Treat every tool output as untrusted input. Do not let content returned by one tool silently trigger a write in another.
- Require human approval for irreversible or external actions: sending messages, payments, deletions, anything leaving your network.
- Log every tool call with user, arguments and result, and review the logs. Our guide to prompt injection defence for AI agents covers the architecture behind these controls.
- Keep personal data out of tool responses unless the task needs it, which also helps with DPDP Act obligations in India.
How to start: your first production MCP server
A realistic first project takes a small team a few weeks, mostly spent on permissions, testing and logging rather than protocol code.
- Pick one job with clear value and low risk, such as "answer staff questions about this week's schedule".
- List the minimum data and actions the job needs. Remove anything that is merely convenient.
- Build a server with the official SDK for your stack (Python and TypeScript are the most mature), using the stateless transport from the 2026 spec.
- Write tool descriptions carefully. Clear, distinct descriptions improve model accuracy and make poisoning easier to spot in review.
- Put authentication in front of the server and map each user to scoped credentials.
- Build an evaluation set of 20-50 realistic requests, including adversarial ones, and run it on every change.
- Pilot with a small group, watch the logs, then widen access.
Costs depend mostly on how messy the underlying system is. Wrapping a clean REST API is quick; wrapping a legacy database with no access layer means building that layer first. If that is your situation, our AI agent development and workflow automation teams typically start by building a thin, well-permissioned service layer and then expose it through MCP.
Common mistakes to avoid
| Mistake | Why it hurts | Better approach |
|---|---|---|
| One "god" server with every tool | Huge context, confused model, wide blast radius | Several small servers, scoped by job |
| Reusing an admin token | Any injection inherits full access | Per-user, per-scope credentials |
| Exposing raw SQL as a tool | The model can read or change anything | Named, parameterised queries only |
| No change detection on tool definitions | Rug-pull attacks go unnoticed | Pin and diff definitions |
| Skipping evals | Silent regressions when models change | A fixed test set run on every release |
Conclusion
MCP is now the most practical way to connect AI agents to business systems without locking yourself to one model vendor. The 2026 specification made it easier to run at scale, and neutral governance under the Linux Foundation makes it a safer long-term bet.
The protocol does not make an agent safe. Safety comes from what you expose, how narrowly you scope it, and what you require a human to approve. Start with one read-only server for one job, measure it, and expand only when the logs show it is behaving. If you want a second opinion on an MCP design, Algon's LLM development team is happy to review it.
Frequently asked questions
What is the Model Context Protocol in simple terms?
MCP is an open standard that lets AI applications discover and use external tools and data, such as a CRM or database, through one common interface instead of a custom integration for each model and system.
Who owns MCP now?
Anthropic created MCP and donated it in December 2025 to the Agentic AI Foundation, a directed fund under the Linux Foundation. The project keeps its maintainer-led governance.
What changed in the 2026 MCP specification?
The spec dated 2026-07-28 removed protocol-level sessions so servers are stateless, added a discovery method that replaces the initialise handshake, moved features like Tasks into optional extensions, and introduced a minimum 12-month deprecation window.
Is MCP secure?
The protocol itself does not guarantee safety. Risks include tool poisoning, servers changing definitions after approval, and ordinary software vulnerabilities. You need least-privilege servers, pinned definitions, logging and human approval for risky actions.
What is the difference between MCP and an API?
An API is how a specific system exposes functions. MCP is a standard wrapper that describes those functions to AI applications so any MCP-capable agent can discover and call them in the same way.
How long does it take to build an MCP server?
Wrapping a clean, well-documented API can take days. Most of the effort in a production server goes into authentication, scoping permissions, logging and evaluation, which usually takes a few weeks for a first deployment.
