Model Context Protocol for Business: What It Is and When You Need It

If you have followed AI news this year you will have seen three letters everywhere: MCP. Suppliers say their product "supports MCP", and developers talk about "building an MCP server". For a business owner or operations lead the useful questions are plainer. What is it, do we need it, and what could go wrong?

This article answers those questions from the protocol's own documentation and announcements, checked on 10 October 2026.

What MCP is

The project's introduction describes MCP as "an open-source standard for connecting AI applications to external systems". AI applications can connect to data sources such as files or databases, tools such as search engines or calculators, and workflows such as specialised prompts. The documentation likens it to a USB-C port: one standard way to connect, instead of a different cable for every device.

In practice there are three parts.

• A host or client: the AI application a person uses, such as an assistant or a developer tool.
• A server: a small service that exposes your capabilities in a standard shape.
• Capabilities: the specification names resources (context and data), prompts (templated messages) and tools (functions the model can run).

The part that matters most for business risk is tools. The specification is blunt that tools represent arbitrary code execution and must be treated with appropriate caution.

What MCP is not

It is not a model, and it does not make an AI more accurate. It is not a security product, either. The specification says MCP itself cannot enforce its security principles at the protocol level, so implementors must build consent and authorisation flows into their applications. It is also not a replacement for the ordinary APIs that connect your business systems. An MCP server usually sits in front of those APIs and presents them to AI applications in a standard way. We explain why well-built APIs matter in our piece on durable API integrations.

What changed in the 2026-07-28 specification

The maintainers released a new version on 28 July 2026. Their announcement describes it as having a stateless protocol core, and lists changes that matter for anyone planning a build.

Selected changes in MCP specification 2026-07-28 and what they mean for a business

Change	What the maintainers say	Why it may matter
Stateless core	Each request is self-describing, so it can land on any server instance behind a plain round-robin load balancer. The initialise handshake and session header are retired.	Simpler hosting and scaling for servers. Teams that relied on sessions face a migration.
Header-based routing	Method and tool names travel in HTTP headers so gateways, rate limiters and firewalls can route and meter on them.	Easier to apply existing gateway and monitoring controls.
Multi Round-Trip Requests	A tool can return an input-required result so the client can ask the user for a confirmation or missing detail, then retry.	A standard route to approval steps before a sensitive action.
Cacheable lists	List responses carry cache hints and a deterministic order.	Lower repeated fetching and more stable prompt caching.
Authorisation hardening	Issuer validation is required before redeeming a code, and Dynamic Client Registration is deprecated in favour of client metadata documents.	The maintainers say authorisation is where implementers spend most integration time. Budget for it.
Deprecations	Roots, sampling and logging are deprecated and will keep working for at least twelve months. The legacy HTTP plus SSE transport has a year-long off-ramp.	Avoid building new work on deprecated features.

Two practical takeaways. First, the maintainers say there will be some migration cost, especially for developers who depended on session identifiers. Second, the specification now carries a formal deprecation policy with a twelve-month minimum window, which makes upgrades easier to plan.

Who looks after it

In December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation. The foundation was co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. The MCP project says its governance model "continues as is", and that technical direction stays with its maintainers. For a buyer this is useful but limited: vendor-neutral stewardship lowers the risk of one company changing the rules, and it does not remove the need for your own security design.

When you need MCP and when you do not

A practical way to decide

Situation	Likely better fit	Why
One automation calls one model and three of your APIs	Direct integration	Fewer moving parts and nothing extra to host or patch.
A voice or chat agent with a handful of fixed tools	Direct tool definitions in the agent	Tool calls are simple functions, as our voice agent architecture guide (linked after this table) describes.
Staff use several AI assistants and want the same safe access to your systems in each	MCP server	One governed catalogue instead of a custom connector per assistant.
You want customers or partners to connect their own AI tools to your service	MCP server	A standard interface that clients already understand.
Your data is messy or the underlying APIs do not exist yet	Fix the API first	MCP exposes what is there. It does not tidy it.

For the voice agent case, see our voice agent architecture guide. The common mistake is adopting MCP because it is fashionable. A protocol adds a server to run, a version to track and a security surface to defend. It pays off when it removes repeated work across several AI clients.

A read-only-first rollout

1. 01Pick one use caseChoose a task people already do by hand, such as looking up an order status.
2. 02Start read-onlyExpose lookups only. A wrong answer is annoying. A wrong write is an incident.
3. 03Enforce permissions in your systemDo not rely on the prompt to limit what a tool can do. Use the caller's credentials and your own access rules.
4. 04Add confirmations for writesUse the specification's input-required pattern or your host's confirmation prompts, and log every call.
5. 05Review after a monthCheck logs for surprises before adding new tools.

An example of a deliberately narrow, read-only tool follows. It is illustrative only. Names and wording are ours, and you should check the current specification for exact fields.

{
  "name": "get_order_status",
  "title": "Order status lookup",
  "description": "Return the status of one order. Read-only. Does not return payment details.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "orderReference": { "type": "string", "description": "The customer-facing order reference" }
    },
    "required": ["orderReference"]
  }
}

Notice what is missing: no refund tool, no "run any query" tool and no free-text SQL. Each extra capability widens what a wrongly behaving or manipulated model could do.

Security: what the specification asks of you

The 2026-07-28 tools page lists obligations. Servers must validate all tool inputs, implement proper access controls, rate limit tool invocations and sanitise tool outputs. Clients should prompt for confirmation on sensitive operations, show tool inputs before calling the server, validate results before passing them to the model, implement timeouts and log tool usage for audit. The specification also says tool annotations should be treated as untrusted unless they come from a trusted server, and that there should always be a human in the loop with the ability to deny tool invocations.

That list is a good starting checklist for any supplier. Ask each question in writing before you sign anything:

• Who can connect to the server, and how are they authenticated?
• What is the narrowest set of tools we can start with?
• Where are tool calls logged and how long are logs kept?
• What happens when the model is fed hostile text from an email, web page or document?

The last question is the hardest. A model that reads untrusted content can be steered by it, and a tool-equipped model can act on that steering. We cover the risk and the controls in prompt injection and AI agent security.

What it costs

We have not found a reliable published figure for typical MCP build costs, so we will not invent one. The cost drivers are easy to name: how many tools you expose, how clean the underlying APIs are, how much authentication work you need, and how much testing and monitoring you want. The model charges are separate and covered in our comparison of AI model APIs. Expect ongoing maintenance, because the specification has just had breaking changes and has a published deprecation schedule.

Conclusion

MCP is a sensible way to give several AI applications governed access to the same business capabilities, and it now has open governance and a mature-looking specification. It is not a reason to rebuild integrations that already work. Start small, keep tools read-only until you trust them, enforce permissions in your own systems and plan for the specification to keep moving.

If you are weighing up where AI could safely sit in your operations, our AI workflow automation page describes how we scope that work, and you can talk to us about a specific process.