One MCP Server Replaces Every Custom Tool Integration

There is a ticket in your backlog that says “let the agent see our deploy state.” It has sat there a sprint. Nobody disagrees the agent would be better with eyes on which build is live. The ticket sits because everyone knows what finishing it means: another adapter. Auth handling, request shaping, response parsing, retries, a thin tool surface, tests for all of it, and then you own that code for as long as the system exists.

If you are still deciding whether agents should reach your external systems at all, that case is made here. This piece assumes it and asks the question that comes after: what does that reach cost to build and keep, once more than one agent wants it?

The tension, in one sentence: every system you wire to an agent by hand costs you again for every other agent that wants the same reach, and the fix is not writing better adapters. It is noticing that half of that multiplication was never yours to pay.

Here is where this piece ends up, so you can check the derivation against it. For a team running three agent surfaces against three systems, hand-wiring costs 108 hours of adapter work in year one. Doing it with MCP servers costs 40.5. That is a 2.67x cut, and it grows: the ratio climbs toward a 24x ceiling as the team adds agents, because the agent-side half of the protocol was already built into Copilot, Cursor, and every other client before anyone on the team touched a config file.

Every hour figure in this post comes from six toy assumptions you can check with a pencil. Before any of that arithmetic, spend thirty seconds finding out whether the problem is yours.

List the agent surfaces your team actually runs. Copilot in the IDE for most people, a Cursor pilot in one corner, a terminal agent the platform folks live in. Next to each, list the external systems it can reach through code someone on your team wrote: the Jira wrapper, the Postgres bridge, the deploy-status script.

The check is one question: does the same system appear twice, wired twice, for two different agents?

Jira under Copilot and Jira again under the terminal agent, in two codebases, by two authors. That duplication is the thing this piece prices. If no system appears twice, you have a list of one-off integrations, and the honest move is to close the tab and come back when the second agent arrives. And if your team runs exactly one agent surface, the table ahead has your row: year one is a wash, and it says so out loud.

For everyone else, here is what the duplicates cost.

If you have never wired the same system twice for two different agents, this piece is not about your team yet.

Fix one example and keep it for the whole piece. A team shaped like the check above: three agent surfaces (Copilot in the IDE, Cursor, a terminal agent) and three systems they need to reach (Jira, Postgres, GitHub Actions deploy state, the ticket from the top). Call the number of agent surfaces M and the number of systems N. This team is M=3, N=3.

Each hand-written adapter carries the same weight no matter which agent it serves. Eight hours to build: the auth flow, the request shaping, the response parsing, the retry logic, the tool surface, the tests. Four hours a year to keep alive, patching when the upstream API moves. That is 12 hours per adapter in year one. These are toy numbers, chosen so every total in this post comes out of them with a pencil; swap in your own hours and the shape of everything below survives.

Now count the work the obvious way, one artifact at a time. Copilot needs Jira: an adapter. Cursor needs Jira: an adapter. The terminal agent needs Jira: an adapter. Three artifacts for one system, and the Jira adapter for Cursor is almost all of the Jira adapter for Copilot, but nobody reuses it, because each harness wants its tools wired its own way. Then the same again for Postgres, and the same again for deploy state.

M × N is 3 × 3: nine adapters, each carrying the full 12 hours. That is the multiplication, the recurring cost this post tracks.

9 adapters x 12 hours = 108

108 hours. All of it real code. That is the size of the problem before any fix is named: nine artifacts, 108 hours, all of it yours, and every new agent or system multiplies the pile again.

Hand-wiring multiplies integrations: M × N artifacts, each carrying full weight, each yours forever.

The fix is to stop writing the integration into your code at all. An MCP server (Model Context Protocol, the open standard the major agent tools have converged on; the per-tool mechanics are here) is a standalone process that exposes typed tools (postgres.query, jira.get_ticket, fs.read_file) over a standard protocol. Your agent is the client. On connect, the agent asks the server what it can do, the server hands back its tool list, and the agent can call those tools immediately.

The shape change is the whole point:

Bespoke: one adapter per pair        MCP: one server per system

Copilot  ─ adapter → Jira            Copilot  ─┐
Cursor   ─ adapter → Jira            Cursor   ─┼─→ jira server ──→ Jira
terminal ─ adapter → Jira            terminal ─┘
                                          postgres server ──→ Postgres
(the same three again                    actions server  ──→ deploy state
 for Postgres, and the same
 three again for deploy state)       each agent holds one config file
                                     pointing at all three servers

M x N = 9 adapters                   N servers + M config files = 6 artifacts

Count the artifacts again for the same team and the same needs. One server per system: a Jira server, a Postgres server, an actions server. Three. One config file per agent, listing the servers it connects to. Three more. Six artifacts where the bespoke world had nine.

Done the obvious way, the count comparison undersells the win: 9 against 6 is a 1.5x cut. Hold that number. It is the naive prediction, and the real gap is bigger, for a reason the next section prices.

This is no longer a single-vendor bet. OpenAI wired MCP into its Agents SDK and ChatGPT in early 2025; Google committed Gemini to it weeks later. In December 2025, Anthropic donated the protocol to the Linux Foundation’s new Agentic AI Foundation, with OpenAI and Block as fellow founding contributors and AWS, Google, Microsoft, Cloudflare, and Bloomberg among the members. That matters here for one practical reason: the server you write, or install, outlives any single vendor’s agent. You integrate against a wire format all of them speak.

The matrix collapses from M × N artifacts to M + N: one server per system, one config per agent, nothing written per pair.

The count treated all six artifacts as equal. They are not, and the difference is the whole argument. Price each kind, year one, same toy convention:

Read the middle row carefully. An MCP server costs the same as an adapter because it is the same code: same auth, same parsing, same retries, same tests, just written to the protocol once instead of per agent. The server side of M + N buys you nothing by itself.

The third row is the one to sit with. A config pointer, one server block in one agent’s config file, is a quarter hour to add and a quarter hour a year to maintain, mostly token rotation. 0.5 hours per pointer. A pointer, not a program.

And 12 divided by 0.5 is 24. An adapter costs 24 times what a pointer costs. Remember 24. It explains the gap in a moment, and it returns at the end of this piece as a ceiling.

Now the full cost, computed the obvious way, summing every artifact’s unit price. Bespoke is already done: 9 × 12 = 108 hours. For MCP, the servers are 3 × 12 = 36 hours. The pointers hide the part the count missed. Each agent’s config file holds one pointer per system, so pointers still go as M × N: 9 of them, at 0.5 hours each, 4.5 hours. Total:

servers   3 x 12            = 36.0
pointers  3 x 3 x 0.5       =  4.5
                            ------
MCP, year one               = 40.5 hours

bespoke 108.0 - MCP 40.5    = 67.5 saved
ratio      108 / 40.5       = 2.6667x

There is the claim from the top of the post, re-derived: 108 against 40.5, a 2.67x cut, 67.5 hours back.

And there is the gap flagged earlier: the count promised 1.5x, the cost says 2.67x. Check it with a shortcut before trusting it. The ratio written out is (M × N × 12) / (N × 12 + M × N × 0.5). Both terms of the denominator carry an N; factor it out and N cancels top and bottom entirely, leaving M × 12 / (12 + M × 0.5). At M=3: 36 / 13.5 = 2.6667. Exact match against the summed line above, no approximation.

The two sides of M + N are priced differently, 12 hours against half an hour, and that difference is why the real win beats the count’s 1.5x promise.

Why does a pointer cost a 24th of an adapter? Both connect an agent to a system. By now you could derive the answer yourself, so here it is with a name: the client half of the protocol is already paid for.

Half of any integration is client capability: discovering what a server offers, reading its typed tool list, routing calls, speaking the protocol. In the bespoke world you rebuild that half every time, inside every adapter, for every agent, because each harness has its own tool plumbing. In the MCP world you never build it at all. Anthropic, GitHub, Cursor’s team, and every other client vendor already shipped it, inside the agent, before your team touched anything.

Your half hour is the price of pointing at work those engineers already did. That is why the M side of M + N is nearly free: the client vendors built that half once, shipped it inside every agent, and MCP is the agreement that lets any team point at the same finished half.

This also explains something the count could not: why the win grows when the team adds an agent. The next table makes it precise.

The expensive half of every integration ships inside the agent already; all you pay for is pointing at it.

Hold N at this team’s three systems and vary the number of agent surfaces. This table is the picture to keep; every claim left in this post is a row of it.

Row 1 is negative. One agent surface and three systems: 36 hours of adapters against 37.5 for servers plus pointers, a loss of 1.5 hours. A team that will only ever run one agent gets nothing from this, and the table says so before any booster does.

Row 3 is this post’s team: 2.67x, 67.5 hours back. By row 12 the ratio is 8.00x. At 100 agent surfaces it is 19.35x and still climbing. Toward what? Run the closed form with M growing: M × 12 / (12 + M × 0.5) approaches 12 / 0.5, which is 24. The per-unit ratio planted two sections ago is the ceiling. At M=100 the ratio sits at 19.35x; at M=10,000 it reaches 23.94x, within one of the ceiling, and it never crosses it. The 24x plant pays off exactly.

One more property, verified by re-running every row of this table with N=8 systems instead of 3: every ratio comes out identical. The ratio depends on how many agent surfaces you run and never on how many systems you wire. The closed form already said so, since N canceled.

That lands the practical advice, and it sharpens the usual pitch for MCP. Adding another system is linear in both worlds: three adapters, 36 hours, by hand, against one 12-hour server plus three pointers, 13.5 hours. “To add a system, add a config block” is true, but adding systems is where the two worlds stay closest. Adding an agent is where MCP compounds: a fourth agent costs three more adapters, 36 hours, by hand, and three pointers, 1.5 hours, with servers. That marginal gap is the full 24x, the unit-price ratio, paid again on every agent. The payoff rides on agent adoption inside your team, and on nothing else.

The ratio tracks how many agents run, ignores how many systems they wire, and climbs toward 24x without crossing it.

The half-hour artifact, concretely. A client config wiring two MCP servers, both standard, neither written by you:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y", "@modelcontextprotocol/server-filesystem",
        "/Users/you/work/acme-api"   // the ONLY directory it can touch
      ]
    },
    "github": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PAT}"  // from your shell, never inline
      }
    }
  }
}

Two entries. No adapter code anywhere in the repo. And the deploy-state ticket this post opened with dissolves here: deploys already run as GitHub Actions, the GitHub server reads workflow-run state with a token from the environment, and the agent learned about all of it from one config block. That is the 0.5 hours.

Scoping happens at the same door. The filesystem server above is pinned to one directory; it cannot read_file outside that path because it was never given a wider window. The GitHub server has the same dial in two more notches: GITHUB_TOOLSETS=actions exposes only the workflow tools, so the agent never even sees create_pull_request, and GITHUB_READ_ONLY=1 strips every write tool no matter what the client allows downstream. The token stays in the environment, never inline, never in the repo, never in the model’s context; the trust-boundary piece owns that argument in full.

Where the server runs is one line either way: stdio as a local subprocess, or a hosted endpoint over HTTP. GitHub ships both, and a platform team can stand the hosted one up once for the whole org, which is the M side of M + N made literal: every agent points at the same running thing, and nobody else manages a secret.

Reach becomes one config entry plus one scoping decision, made at the boundary and inherited by every session after it.

Three honest caveats and two scope lines.

The 8-hour server build is the worst case. Far more often you install a server someone already wrote: the official MCP registry, live in preview since September 2025, listed thousands of servers within its first year, by public counts. That drops the toy’s server side from 36 hours to 1.5, three installs at pointer prices, and the M=3 row climbs from 2.67x to a straight 18x. Two caveats ride with it: the registry is still in preview, and it lists rather than vets. Installing someone else’s server is a trust decision, and this piece’s arithmetic does not price it.

The equal pricing is an assumption this piece chose. A server was priced at 12 hours because it is the same code as an adapter. Price it at double, for the protocol work and packaging, and every ratio below the ceiling shrinks. The shape survives: the ratio still climbs with M toward 24x, because the ceiling comes from the adapter-to-pointer price alone.

And this piece priced the build, never the run. Every server you wire in adds its tool list to the model’s context on every turn. The scale of that bill, from Anthropic’s own engineering post on advanced tool use (November 2025): a client loaded with 50-plus MCP tools carries about 72,000 tokens of definitions before the first prompt runs. Two measured costs follow. Tokens: RAG-MCP (Gan and Sun, arXiv 2505.03275, May 2025) found that retrieving only the relevant tool descriptions cut prompt tokens by more than half. Judgment: the same paper’s stress test measured tool selection at 43.13% accuracy when the relevant definitions are fetched first, against 13.62% for its baseline without retrieval. The industry’s answers exist and are worth looking up by name: Anthropic’s Tool Search Tool (November 2025) loads tool definitions on demand, which Anthropic reports cutting tool-definition tokens by up to 85%, and Cloudflare’s Code Mode (February 2026) gives an agent an entire API in about a thousand tokens by having it write code against one typed interface instead of loading every endpoint as a tool. This site already owns the context-window villain in two pieces, cache-the-explore and stop-reading-your-codebase-in-the-window; go there for the run tax, the ongoing context bill for everything you wired in.

Two scope lines, because a reader in 2026 arrives expecting both. Security is out of scope here: this is the build-cost argument, and the safety argument lives in four sibling pieces, the confused deputy (one server holding read and write scope at once), credentials server-side, typed output boundaries, and confirmation gates on destructive tools. And Agent Skills, the other primitive you have heard of, is a complement here rather than a rival: MCP is what the agent can reach, Skills are what it does once it gets there, the live connection versus the stable procedure. A skill will not query your deploy state; a server will not encode your release checklist.

The build math is honest about its own edges: worst-case hours, a chosen cost model, and a run tax it never priced.

Back to the table, row by row, because it is the picture to keep. One agent surface: 0.96x, a loss of 1.5 hours. Three, this team: 2.67x, 67.5 hours back. Six: 4.80x. Twelve: 8.00x. A hundred: 19.35x. Ten thousand: 23.94x, still under a ceiling of exactly 24, the price ratio between an adapter and a pointer, and the number this post planted the first time it priced anything. That is the opening claim reconciled: 108 hours against 40.5 for the team shape you probably have, computed from six toy hours you can check with a pencil.

The advice the table encodes: spend your energy where the ratio lives. Wiring a fifth system into four agents costs 48 hours by hand and 14 with servers, the close case. Wiring a fourth agent into five systems costs 60 by hand and 2.5 with servers, the 24x case, and it is 24x on every agent after that, because the build tax, the one-time hours this piece counted, shrinks toward zero as agents arrive. Which is another way of saying the client vendors already paid it.

So go delete that backlog ticket. The work it describes is a process you point at, a directory you scope, a token you keep in the environment, and one block of config the agent reads on connect.

And the open question this piece hands you: it never priced the run. Every server in that config ships its tools into context on every turn, and the better the build math looks, the more servers you are tempted to wire. The build tax falls as your team adopts agents; the run tax rises as you wire systems; and the second bill is the one to read next, in cache-the-explore and stop-reading-your-codebase-in-the-window.

The build tax shrinks toward zero as your team adopts agents; the run tax is the bill this piece hands you unread.

About the numbers. The six unit hours (8 build + 4 maintain for an adapter, 8 + 4 for a server, 0.25 + 0.25 for a config pointer) are toy numbers, invented for traceability, not measured off any real team. Every other hour figure in this piece, the 108, the 40.5, the 67.5, the marginal costs of one more system or one more agent, the 18x registry row, and every row of the master table, is arithmetic that follows from those six, re-checked against a script before publishing. Swap in your own hours and the shape survives: row one stays negative until the second agent arrives, N still cancels, and the ceiling becomes your own adapter-to-pointer price. The quoted figures, each dated: the RAG-MCP results (43.13% against 13.62%, and the over-50% prompt-token cut) are from Gan and Sun’s paper, arXiv 2505.03275, May 2025; the 72,000 tokens for 50-plus tools and the up-to-85% token reduction are Anthropic’s own figures, from its advanced tool use post, November 2025; the thousand-token API figure is from Cloudflare’s Code Mode post, February 2026; the registry’s September 2025 preview launch is public record, and server counts on it drift by the month. The Agentic AI Foundation facts are from the Linux Foundation’s December 2025 announcement.

For the per-tool mechanics, see MCP servers for the protocol and server setup, Permissions, sandboxing & approval modes for gating discovered tools at the client, and Skills for the complementary primitive: stable procedure rather than live reach.