TL;DR
Most MCP business cases are built on a productivity multiplication nobody believes. This one is built on four things you can actually count: integration effort, maintenance load, time from request to capability, and whether the pilot clears the security review at all. Every number below is an assumption you can see and replace. The arithmetic is the point, not the inputs.
Start by throwing out the usual model
The standard AI business case goes: N knowledge workers save M minutes a day, multiply by an hourly rate, and there is your seven-figure saving. We published a version of that ourselves in 2025. It is gone, because nobody who signs a budget believes it. Minutes saved do not turn into money unless somebody's headcount or spend changes, and a CFO knows that.
What a CFO does believe is a cost that exists today, with a name and an owner, that will be smaller under the new arrangement. So that is what we count.
Line 1: integration effort
Every assistant that needs to reach a system is an integration. It needs authentication, a mapping of what the assistant may call, error handling and somewhere to send logs. If three assistants (say Copilot for the business, Claude for engineering and a coding agent) each need to reach twelve systems, that is thirty-six integrations built one at a time.
With MCP, each system is exposed once as a server, and every assistant reads the same server. Twelve pieces of work instead of thirty-six, and for most SaaS products the server already exists.
| Input | Per-client integration | MCP |
|---|---|---|
| Assistants in use (A) | 3 | 3 |
| Systems to reach (S) | 12 | 12 |
| Pieces of integration work | A × S = 36 | S = 12 |
| Of which already exist off the shelf | 0 | your count; often most of them |
| Engineer-days per piece (your estimate) | d | d |
| Build effort | 36 × d | (12 − existing) × d |
Put your own value of d in. The ratio does not depend on it. With two assistants the saving is 2×; with four it is 4×. This is the arithmetic from One Connector, Every AI Client, and it is the only integration number in this article that is not an assumption.
Line 2: maintenance load
Integrations do not stay built. Systems change their APIs, rotate credentials and retire endpoints. Each change has to be applied everywhere that system is integrated.
If each system changes twice a year, per-client integration means 3 × 12 × 2 = 72 touch points a year. Under MCP it is 12 × 2 = 24, and none of them involve the assistants. Multiply by the hours a touch point costs you and by your loaded hourly rate; that is a recurring line, and recurring lines are what a three-year case is made of.
Line 3: time from request to capability
The cost that is hardest to see and easiest to feel is elapsed time. A team asks for its assistant to reach a system. Under per-client integration, that is a ticket, a build, a review and a deployment, per assistant, per system. Weeks is normal.
With one governed connector per person, a system is connected once, centrally. A team gets access by being added to a group in the identity provider. A new joiner in that group has the same access on day one; a leaver loses it the day they leave. The interval between "we need this" and "we have it" collapses from a project to an administrative step.
To cost it, take one use case you already have queued, estimate what it is worth per month once live (be conservative; use a number the team owner will defend), and multiply by the months of delay you would save. That is the opportunity line, and unlike the productivity multiplication, it attaches to a specific request and a specific owner.
Line 4: whether it ships at all
This is the line most business cases leave out, and it is the one that decides the rest. An AI pilot that stalls at the security review has cost 100% of its budget and returned nothing. The review stalls on questions the protocol cannot answer: who is allowed to use this, what exactly may they do with it, what happens when the agent tries something risky, where did the data go, and can you prove any of it afterwards.
MCP on its own does not answer those. It authenticates a client to a server; an authorised client then sees everything the server exposes to it, and nothing in the protocol decides which person may use which tool or holds a call for approval. So the honest business case for MCP includes the governance layer that makes it approvable: entitlement per person through the groups you already hold, policies evaluated on the actual arguments of a call, a human approval step for the calls that need one, a tamper-evident log of who did what, and cost attributed to the team that incurred it. We wrote up the reasoning in MCP vs API.
Cost it as a probability. If you have run pilots before, you know your own rate of pilots that reached production. Whatever moves that rate is worth the difference between pilot spend and pilot spend times the rate.
Line 5: spend you can see
Once assistants are calling tools in production, there is a bill: tokens, tool calls, the systems behind them. If that bill arrives as one undifferentiated number, finance will either cap it or kill it, and nobody will be able to say which team's work it paid for.
Cost attribution per team, per agent and per tool call turns that bill into something a budget owner can defend. That is not a saving in itself. It is what stops the programme being cut in month six, which for a business case is the same thing.
What goes on the other side
A case that only lists benefits is a pitch. Here is what you will actually pay.
- Servers you do not have. For systems with no off-the-shelf MCP server, someone writes one. Budget the engineer-days.
- The governance layer. Licensing for Palma or whatever you choose, and the infrastructure it runs on if you deploy it in your own VPC or on-prem.
- Someone who owns policy. Deciding which group may call which tool with which arguments is a job. It is a small job compared to running thirty-six integrations, but it is not zero.
- The first week. Connecting the identity provider, the first two or three systems, and one team. We say it takes about a week to a first governed use case; hold us to it, and budget it.
The worksheet
| Line | Your inputs | Arithmetic |
|---|---|---|
| 1. Build effort saved | A, S, existing servers E, days per piece d, day rate r | (A × S − (S − E)) × d × r |
| 2. Maintenance saved per year | changes per system per year c, hours per touch h, hourly rate | (A × S − S) × c × h × rate |
| 3. Delay recovered | value per month of one queued use case v, months saved m | v × m, per use case |
| 4. Pilot spend that reaches production | pilot budget P, historical pass rate p₀, expected pass rate p₁ | P × (p₁ − p₀) |
| 5. Cost | licensing L, servers to write W × d × r, policy owner share of an FTE, first week | sum, per year |
| Three-year case | line 1 once + 3 × (lines 2, 3, 4) − 3 × line 5 |
Fill it in with numbers the people who will be asked about them are willing to stand behind. If line 1 alone does not clear the cost, do not build the case on lines 3 and 4; they are real, but they are the ones a sceptical reviewer will attack first.
If you want a second pair of eyes
We have filled this worksheet in with enough companies to know where the inputs usually go wrong. Bring yours, the list of systems and the assistants in use, and we will go through it in thirty minutes.
