MCP for Business: What the Standard Settles, and What You Still Build Yourself
The Model Context Protocol has won the argument it started. In December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI, and backed by Google, Microsoft, AWS, Cloudflare and Bloomberg. There are more than ten thousand active public MCP servers. It is the standard.
Now the part nobody puts in a press release. The protocol’s own 2026 roadmap lists four priorities, and the fourth is enterprise readiness — audit trails, single sign-on, gateway behaviour, configuration portability — which the maintainers describe, in writing, as “the least defined” of the four. That is exactly the list a business needs before it connects an AI assistant to its order book. The standard is settled; the plumbing a company would want around it is being drafted this year.
What MCP actually is, in business terms
Strip out the protocol vocabulary and MCP is a plug standard. Before it, connecting an assistant to a system meant a bespoke integration per assistant per system: five tools and four assistants is twenty pieces of work, each maintained separately. With MCP you build one server per system, and any compliant assistant can use it.
| Question | Without MCP | With MCP |
|---|---|---|
| Connecting one system to four assistants | Four integrations | One server |
| Switching AI vendor | Rebuild the integrations | Point the new client at the same server |
| Who owns the connector | Usually the AI vendor | You do |
| What it costs to add a fifth assistant | Another integration | Configuration |
That last column is the whole commercial case, and it is worth being precise about it: MCP is not a product you buy, an AI capability, or something that makes an assistant smarter. It is a socket. The value is that the wiring stops being disposable, which matters most to the businesses that have already thrown away one integration when they changed tools.
The strategic reason the governance change matters more than any feature: a connector built to a vendor’s private interface is an asset with someone else’s expiry date on it. A connector built to a standard held by a neutral foundation is an asset you control. If you are going to pay to integrate your CRM, your stock system or your booking calendar with anything AI-shaped this year, that distinction is worth more than any individual capability on the roadmap.
What changed in July 2026, and why your hosting bill cares
The 2026-07-28 specification is the release that turned MCP from an interesting protocol into an ordinary piece of web infrastructure. Four changes matter commercially.
- It became stateless. The old handshake and session identifier are gone; each request carries what it needs. In plain terms, an MCP server can now sit behind the same round-robin load balancer as the rest of your site, with no shared session store and no sticky routing. That is a real reduction in what it costs to run one reliably.
- Requests are routable without opening them. Every call now carries headers naming the method and the target, so a gateway or web application firewall can route, meter and rate-limit without parsing the body. This is what makes it plausible to put an MCP server behind the infrastructure you already own.
- Catalogues can be cached. List responses carry a time-to-live, so a client stops re-fetching your tool list on every interaction. Fewer calls, lower cost, less load.
- Some things were deprecated, on a clock. The legacy transport is deprecated, dynamic client registration is being replaced, and three older capabilities carry a minimum twelve-month support window. If a supplier built you an MCP integration in 2025, there is a migration in your future — and twelve months is a comfortable runway only if somebody has the date written down.
That last point is the one to act on. Ask whichever supplier built the thing which specification version it targets, and put the answer in the same place you keep your other renewal dates.
Where it pays for an ordinary business
Three cases where MCP earns its keep today, and one where it does not.
- Internal question-answering over systems that do not talk to each other. “How many of SKU 4471 are left, and which supplier has the shortest lead time?” — a question that currently requires a person to open three tabs. This is the highest-value, lowest-risk use because it is read-only.
- Drafting work that needs live data. Quotes, order confirmations, supplier chasers: the assistant reads current prices and stock rather than guessing, and a person still presses send.
- Support triage with context. An assistant that can look up the actual order behind an enquiry answers usefully instead of asking the customer for their order number a second time.
Where it does not pay: automating a process nobody has written down. MCP will connect an assistant to a mess faster than before, and the result is a faster mess. The integration questions worth settling first are the ordinary ones in our note on connecting a website to a CRM and a stock system — an assistant is one more consumer of that plumbing, not a substitute for it.
What building one actually costs
Estimates in this area are wildly inconsistent, mostly because two very different jobs get the same name. The work divides cleanly.
If the system already has a usable API, an MCP server over it is a small piece of work — a thin translation layer that exposes a handful of named operations, plus the credential handling and logging described below. This is days, not months, and the honest majority of the effort goes into deciding which operations to expose and writing their descriptions well enough that an assistant picks the right one.
If the system has no API, MCP is irrelevant to your problem. You have an integration project, and the protocol is the last ten percent of it. Any proposal that quotes an “MCP integration” for a system with no programmatic access is quoting for the wrong thing.
The recurring cost is the part usually left out of both estimates: every operation you expose is a thing that must keep working as the underlying system changes, and a tool description that has drifted out of date is worse than a missing tool — the assistant will call it confidently.
The security shape of an MCP server
An MCP server is an API endpoint that a language model drives, which changes the threat model in one specific way: the instructions arriving at your tools were partly written by whatever text the model just read. A support email, a supplier PDF, a web page in a search result — any of it can contain text attempting to steer the assistant into calling your tools in ways you did not intend. This is not hypothetical and it is not solved by the protocol.
Four controls, in order of how much they buy you.
Start read-only, and stay there longer than feels necessary. A server that can look things up but cannot change them has a bounded worst case. Most of the value in the list above is available read-only. Add write access one operation at a time, with a named owner for each.
Scope credentials to the operation, not the system. The token behind an MCP server should reach exactly the records the tool needs. This is the same principle as separating deployment credentials from database credentials, set out in our note on why the build step became a security boundary.
Put a human in front of anything irreversible. Sending money, emailing a customer, cancelling an order, deleting a record: confirmation before execution, every time. This is a design decision at the server, not a preference you express in a prompt.
Log every call yourself. Audit trails are on the roadmap, not in the specification — so if you need to answer “what did it do on Tuesday”, that logging is your build. It is also the thing a client’s security questionnaire will ask about, for the reasons in our note on how NIS2 reaches you through a contract.
Buying it: questions for a supplier
Five questions establish whether an MCP proposal is engineering or vocabulary.
“Which specification version does this target?” A supplier who cannot answer built against whatever was current when they started, which for anything begun in 2025 means a migration nobody has scheduled.
“What can it write, and what can it only read?” You want a list, not a reassurance. If the answer is “it has full access for now”, that is a decision someone made on your behalf.
“Which credentials does the server hold, and what do they reach?” The correct answer is narrow and boring. A single admin token is the common shortcut and the expensive one.
“Where is it hosted, and who can reach it?” An MCP server exposed to the internet without authentication is a public API onto your business. Ask specifically.
“What is logged, and where does it go?” Since the specification does not yet mandate audit trails, this is a build decision, and it either happened or it did not. The rest of the supplier-assessment questions are in our note on the checklist to run before integrating a service.
A proportionate position for 2026
The protocol is settled, the hosting story got much better in July, and the enterprise controls a cautious business would want are still being written. That combination argues for a specific posture rather than either enthusiasm or avoidance.
Build read-only first, on one system, and see whether anyone uses it — most of these projects fail at adoption rather than at engineering. Keep the write operations behind confirmation until the audit-trail work lands. Write down which specification version you are on. And decide in advance which questions an assistant is allowed to answer with your data at all, which is a governance decision rather than a technical one, and is covered in our note on the AI rules worth writing down now.
What not to do: connect an assistant to your production database because a demo was impressive, or buy an “MCP strategy” as a retainer. The protocol is a socket. Sockets are useful and they are not strategies.
Key takeaways
- MCP is vendor-neutral as of December 2025, donated to the Agentic AI Foundation under the Linux Foundation by Anthropic with Block and OpenAI, with 10,000+ active public servers.
- It is a plug standard, not a product — one server per system instead of one integration per assistant per system, and you own the connector.
- The July 2026 specification made it stateless and routable, so it runs behind an ordinary load balancer and gateway; that is the change that lowered the cost of hosting one.
- Deprecations are on a twelve-month clock. Ask which specification version your integration targets and record the answer.
- Enterprise readiness — audit trails, SSO, gateway behaviour — is the roadmap’s own “least defined” priority. Anything you need there, you build.
- Start read-only, scope credentials per operation, confirm anything irreversible, and log every call. The instructions reaching your tools were partly written by text the model read.
