MCP Server Build vs Buy: TCO Calculator + Framework

MCP server build-versus-buy is the recurring capital-allocation decision of 2026 — every team shipping agentic workflows hits the same fork roughly once per quarter, and the wrong call on a single capability can dominate two years of engineering throughput. The framework below replaces gut feel with a six-axis, twenty-four-month TCO model that names every line item, including the ones most teams forget to count.

The published MCP server ecosystem crossed 1,200 npm packages in Q2 2026 — Slack, GitHub, Linear, Postgres, Figma, browser control, internal-corpus search, and a long tail of capability-specific servers from independent authors and enterprise vendors. For any given capability your agent needs, the build option and at least one credible buy option both exist. The question is no longer can you buy; it is whether you should.

This guide walks the six decision axes that determine the call, decomposes each side of the TCO into the line items teams routinely miss, models four common capability archetypes with realistic numbers, and ends with a one-page flowchart you can apply at every MCP capability fork. Everything here is drawn from build-versus-buy engagements we have run with product teams shipping MCP into production over the last year.

Three things changed about agentic infrastructure between mid-2025 and Q2 2026, and together they make build-versus-buy the dominant cost question every product team faces this year. First, the MCP specification stabilised — the wire format, transport options, and tool schema conventions are no longer in flux. Second, the vendor market filled in: every capability worth wrapping has a credible paid option, often three or four. Third, the cost of writing an MCP server in TypeScript or Python dropped to roughly an engineer-week for a focused tool — well within the noise floor of most product roadmaps.

That combination is dangerous. When both options are cheap, the decision feels low-stakes — and so teams make it casually, capability by capability, with no central framework. Six months in, the typical mid-sized product team operates fifteen to thirty MCP capabilities across some mix of bought servers, built servers, and partially-built wrappers around bought servers. Half of them are in the wrong column on the build-versus-buy axis. The cost of being in the wrong column on any one capability looks small at the decision moment, and compounds quietly across the portfolio.

The fix is not to slow down — it is to apply a consistent framework at every capability fork. The framework below takes ten minutes to run per capability and produces a defensible answer. The output is not a single number; it is a documented set of axis weights, a twenty-four-month TCO under both paths, and a stated assumption about strategic differentiation that you can revisit when the picture changes.

The principle worth carrying into the framework: build-versus-buy is a portfolio question disguised as a sequence of individual decisions. The framework treats it that way — axis weights are consistent across capabilities so the portfolio view is coherent, even though each decision is made one at a time. The compounding advantage shows up at the eighteen-to-twenty-four-month mark, when the teams running the framework consistently have a measurably lower blended TCO and meaningfully less vendor lock-in than teams that decided each capability on its own merits.

Six axes drive the call. Each is rated on a one-to-five scale per capability, weighted, and rolled up into a directional signal. The axes are not equal — strategic differentiation is the override, and volume × change cadence is the next-strongest signal. The rest refine the answer when the top two are inconclusive.

The weighting that works in practice across the engagements we have run: differentiation 30%, volume 20%, cadence 15%, depth 15%, governance 10%, talent 10%. Differentiation gets the lion's share because it is the only axis where being wrong is strategically expensive rather than just operationally annoying. Volume and cadence together carry 35% because they are the most predictive of twenty-four-month TCO. The remaining 35% spreads across the three refinement axes.

A capability that scores high on differentiation but low on volume still warrants a build — the cost is incurred to control the strategic surface, not to amortise. A capability that scores high on volume and cadence but low on differentiation almost certainly wants a build for cost reasons. The interesting cases are the middle of the matrix, where the refinement axes tip the balance and the twenty-four-month TCO model becomes the decider.

The naive build estimate is engineering hours times loaded rate, and it is wrong by 30-40% almost every time. The line items that get missed are predictable and they are the same across engagements. The TCO model below names them explicitly so you can either include them or document the decision not to.

Read that as: an engineering estimate of one engineer-month for the initial build typically lands at one engineer-month for delivery plus another engineer-month spread across ops, auth, observability, and schema versioning, plus 0.3 engineer-months per year in ongoing maintenance through the TCO horizon. A two-year build TCO on a "one engineer-month" estimate is closer to 2.6 engineer-months of fully-loaded effort, not one.

Two further line items are situational and deserve explicit consideration. The first is integration test coverage — if the MCP server wraps an upstream API you do not control, you need contract tests against that upstream that catch breaking changes before they reach production. Budget another 10-15% of build for that test suite and its CI maintenance. The second is multi-host support — if the server needs to negotiate stdio, SSE, and streamable HTTP transports for different host classes, each transport adds 5-10% to build because the error-handling and lifecycle code is not portable.

The naive buy estimate is the license line on the contract, and it misses roughly half the twenty-four-month cost. Three categories dominate the gap: integration hours that get treated as a one-time cost when they are not, the vendor lock-in tax that compounds each renewal cycle, and the operational overhead of running someone else's software inside your trust boundary.

The vendor lock-in tax is the line item most teams refuse to model on the grounds that "we'll renegotiate at renewal." Renegotiation works exactly to the extent that you have a credible alternative. On the day you sign, your alternative is the build option — which you priced earlier in this framework, which means you already know what walking away costs. Document the lock-in tax explicitly at sign time: "the renewal price we will accept before switching to $alternative is $X, beyond which the migration cost of $Y becomes the better deal." Without that documented number, every renewal negotiation becomes an emotional decision instead of an arithmetic one.

One additional buy-side cost that deserves naming is capability boundary risk — the case where the bought server does 80% of what you need and the remaining 20% has to be built around it. That 20% wrapper is the worst of both worlds: you pay the buy-side license, you carry the build-side maintenance, and the vendor's schema changes break your wrapper on their cadence rather than yours. Model the wrapper explicitly when scoping the buy, not as an afterthought.

Every build-versus-buy TCO model needs a third axis: the cost of switching paths after month twelve. The teams that get build-versus-buy wrong are rarely the teams that picked the wrong initial path — they are the teams that did not budget for the switch when the picture changed. Vendor pricing rises, the build grows beyond its maintenance budget, a new vendor enters the market, an acquisition deprecates a tool. The capability needs to move; the cost of moving is what dominates twenty-four-month TCO at the portfolio level.

Switching cost has three components. The first is the new implementation — either the fresh build or the new vendor's integration. The second is contract translation — the schema differences between the old and new MCP servers that propagate into every agent tool call site, every prompt that mentions the tool by name, and every test that exercises the capability. The third is the parallel run period where both implementations ship traffic side by side so the switch is reversible if behaviour drifts.

The aggregate is sobering. A typical switch costs roughly 1.2 to 1.5× the original implementation — more than building from scratch, because you are now paying for the schema-translation work too. Two practical consequences. First, include an expected-switching-cost line in every twenty-four-month TCO with a probability weight: "P(switch by month 24) × switching cost." If P(switch) is 30% and switching cost is 1.3× original, the expected-switching line is 0.39× original — about a third of the headline build or buy number.

Second, design every MCP integration to minimise the contract translation surface. The cheapest switches are the ones where the schema, tool names, and response shapes are stable abstractions owned by your code rather than the vendor's. Wrap the bought server in your own tool-name namespace, with your own validated schema on the agent side, and the switching cost on that capability drops from 1.3× to roughly 0.8× because the contract translation work evaporates. This wrapper pattern is the third path we discuss in Section 06.

The framework is easier to internalise on worked examples. The four scenarios below cover the cardinal directions of the build-versus-buy space: high-volume commodity, low-volume specialist, high-differentiation core, and the wrapped-buy third path. Each is a realistic capability we have seen play out in engagements, with the numbers rounded for legibility.

Two patterns stand out across the four. First, specialist vendors are usually expensive at small scale — their pricing is calibrated for large customers, and your low-volume use case subsidises that calibration. When you find yourself in a "specialist vendor" quadrant, the build math almost always wins. Second, the wrapped-buy pattern is under-used — it adds one to three engineer-weeks of work up front, drops the lock-in tax substantially, and makes future switches cheap. For any capability where you suspect the vendor market will shift before month 24, the wrapper is the right play.

Behaviour to avoid: framing the decision as a single binary at one moment. Every capability in the portfolio should be revisited at renewal cycles and at any 2× volume inflection. The framework is cheap to rerun; the cost of being in the wrong column when the numbers have moved is not. For teams running multiple capabilities on the same vendor, run the calculator at the portfolio level — vendor concentration risk is a real line item once you cross three or four capabilities with the same provider.

The flowchart below collapses the framework into a sequence you can walk in ten minutes per capability. It is intentionally narrow — five questions, three terminal outcomes (build, buy, wrap-buy) — so the cognitive load stays low at decision time. The wider analysis we have been doing through Sections 02-06 lives in the documented axis ratings and TCO tables; the flowchart is the daily artefact that operationalises it.

One discipline keeps the flowchart honest at month eighteen, when the numbers have moved and someone is asking why the original call was made: write down the axis ratings and TCO numbers at decision time, in a short markdown file alongside the capability in your repo. The file does not need to be elaborate — six axis scores, the weighted total, the build and buy TCO bottom lines, the P(switch) estimate, and the resulting decision. When the situation changes you can rerun the framework against the documented baseline in fifteen minutes rather than reconstructing the original reasoning from memory.

For teams building the framework into their delivery process, two related guides are worth reading alongside this one. The MCP TypeScript build tutorial walks the full server implementation you will be costing on the build side of the calculator. The MCP security audit checklist is what you apply to the bought option before signing, and to the built option before shipping — governance-axis questions get answered there in operational detail.