MCP Won the Protocol War: Build-vs-Buy Math for Your Own Deploy MCP Server

The strangest standards war in AI infrastructure ended the way the best ones do: one side simply adopted the other's protocol. When OpenAI announced MCP support across its products in March 2025 — CEO Sam Altman's entire announcement was a single post saying "people love MCP and we are excited to add support across our products" — the contest for the agent-tool standard was effectively over. Anthropic had open-sourced the Model Context Protocol four months earlier; its biggest rival chose convergence over a fork. By December 2025 the protocol lived under neutral governance at the Linux Foundation's Agentic AI Foundation, co-founded by Anthropic, Block, and OpenAI itself.

That settlement changes the only question that matters for a platform team in 2026. It is no longer which protocol will win — it is should we build our own infrastructure MCP server, or buy one. Here is the short answer, with the full math below:

The one-sentence verdict: if your agents only need to read infrastructure state, do not build — start read-only or buy. If they must deploy and roll back, budget for write operations properly, because auth, audit logging, and the safety story cost more than the server itself.

From one company's spec to neutral infrastructure in 13 months​

The convergence timeline is worth stating precisely, because "the protocol bet is settled" is a claim that needs receipts:

• November 2024 — Anthropic releases MCP as an open standard with Python and TypeScript SDKs, aimed at the N×M integration problem between agents and data sources.
• March 2025 — OpenAI adopts MCP across its Agents SDK, Responses API, and ChatGPT desktop app. Altman announces it on X in one sentence.
• April 2025 — Google DeepMind confirms MCP support in upcoming Gemini models. All three frontier labs are now on one tool protocol.
• December 2025 — Anthropic donates MCP to the newly formed Agentic AI Foundation under the Linux Foundation. The protocol is no longer one company's to steer.
• 2026 — ChatGPT opens its app directory to third-party MCP submissions, ships MCP Apps support, and requires remote HTTPS servers (no stdio); the spec itself reaches a mature 2026-07-28 revision.

Adoption followed governance. The ecosystem reports 97 million monthly SDK downloads, roughly 10,000 servers active in production, and about 9,400 public servers. Stacklok's 2026 survey puts 41% of software organizations in limited or broad production with MCP servers, and enterprise surveys report nearly two-thirds running a custom internal MCP server at large shops. Gartner projects 40% of enterprise applications will include task-specific AI agents by end of 2026. Critically for the build-vs-buy question, deployment has gone remote: 80% of the most-searched MCP servers now offer remote deployment, and ChatGPT only connects to remote HTTPS servers — the stdio-localhost era is a development detail, not a distribution strategy.

What an infrastructure MCP server actually is​

"Build an MCP server" sounds abstract until you list the tools. An infrastructure server that lets agents operate a deploy pipeline is a small, legible tool surface — each tool a named operation with a JSON schema, because the agent reads names and descriptions to decide what to call:

• list_services — enumerate apps across environments (read)
• get_deploy_status — rollout state, replica health, last deploy SHA (read)
• get_logs — tail service logs with a time window (read)
• deploy — trigger a deploy of service X to environment Y at ref Z (write)
• rollback — restore service X to its previous revision (write)

This is not hypothetical. The ArgoCD MCP server already exposes sync_application and rollback_application alongside diff inspection; community Kubernetes servers expose rollout and rollback operations; Red Hat open-sourced a Kubernetes MCP server you deploy yourself; whole DevOps toolkits now wire Jenkins, ArgoCD, Helm, Terraform, Prometheus, and Vault behind MCP tools. If you run GitOps, your agents are one tool surface away from "show me which apps are out of sync in production, explain the diff, and sync payment-service."

The line that matters in that tool list is the one between reads and writes. Everything about the cost — and the decision — pivots on which side of it you land.

The build-vs-buy math, with real 2026 numbers​

A September 2026 cost study by Launch Day Advisors, built from real partner engagements and in-house builds, gives the clearest public envelopes. Adapted here to an infrastructure server:

The delta between read-only and actions is roughly 2× — and almost none of it is the server code. A representative $500K level-2 build breaks down as: tool surface $80K–$180K, OAuth 2.1 + PKCE + Dynamic Client Registration $60K–$120K, safety story (idempotency keys, reversibility, intent preview) $60K–$120K, audit log plus admin surface $40K–$80K, server implementation and hosting $50K–$100K, with discovery, distribution, pen test ($30K), and first-time SOC 2 ($50K–$150K) making up the rest. The server process — the part engineers picture when they say "build an MCP server" — is the cheapest line item. Auth, audit, and the safety story are what a security review actually inspects, and they are where a thinly staffed build dies: one engineer part-time with "audit log as a TODO" reliably becomes a rebuild by month six, with 30–50% of the in-progress code thrown away.

On the buy side, the math is simpler but not free. Managed MCP gateways (Arcade's tool platform, Cloudflare Workers with its OAuth provider library, Stytch Connected Apps, WorkOS) absorb the auth hardest part — spec-compliant OAuth 2.1, DCR, token lifecycle — plus hosting, rate limiting, and per-user credential isolation. You pay hosting plus gateway or seat fees instead of two quarters of eng time. The honest trade: you rent the trust boundary. Your deploy credentials flow through someone else's OAuth service, and your tool surface is constrained to what the gateway expresses well. For read-heavy surfaces and standard OAuth patterns, that trade wins. For deploy/rollback against your own fleet with custom approval flows, it often doesn't — which is exactly what the decision rule below encodes.

One more number that belongs in every model: the second client costs 1.4–1.7× the single-client total, not 2× and not zero. Different auth, different distribution, different review process. If your server must work in both Claude and ChatGPT right now, price two clients. If you can ship one and add the directory listing later, say so explicitly — it is a $100K+ scoping decision hiding in a launch checklist.

Three paths, one decision rule​

The whole decision fits in two variables: do agents need write operations? and how many clients must work on day one?

Three notes on what flips the answer:

1. Writes are the cliff, not a slope. Adding "just one deploy tool" to a read-only server moves you from level 1 to level 2: idempotency, reversibility, audit, approval UX. Scope the tool list before staffing, not after.
2. Compliance is a second cliff. If enterprise procurement will ask about SOC 2, pen tests, and tamper-evident audit logs, add $100K+ and a quarter — or buy from someone who already has them.
3. Opportunity cost reverses the in-house discount. In-house looks $100K cheaper than a partner at the midpoint, but those four-plus engineers come off your roadmap. If delayed features cost more than ~$100K in value, the partner wins on total cost.

Product-line depth: what makes your server callable by agents you never built​

The deeper question underneath the math is the interesting one: what determines whether someone else's agent calls your server? The answer is product-line depth — how far down the stack the protocol reaches — and in 2026 it has a concrete checklist:

1. A remote endpoint, not a localhost process. Streamable HTTP over TLS is the distribution transport; ChatGPT connects only to remote HTTPS servers. If your server only speaks stdio, third-party agents cannot reach it at all.
2. OAuth 2.1 with Dynamic Client Registration. This is how an agent your team never met authenticates its user against your server without a pre-shared API key baked into a config file. It is also, recall, a $60K–$120K line item — the price of being callable by strangers.
3. A directory listing. ChatGPT's app directory opened to third-party MCP submissions in 2026 with human review; registries and marketplaces are the discovery layer. Unlisted servers get called by agents whose operators typed in the URL — listed ones get called by agents whose operators only described the task.

API-only depth (your server works with one SDK) gets you agents you built. Full depth (remote + OAuth + listed) gets you agents you never built a client for — which is the entire point of converging on one protocol. Price the checklist, not just the code.

The risk moved, it didn't disappear​

Two years ago the risk was betting on the wrong protocol. That risk is gone: rivals converged, governance is neutral, the spec is mature, and the install base is measured in tens of millions of downloads. The risk left is scoping badly — treating a write-capable deploy surface like a weekend project, discovering auth and audit in month three, and paying for the build twice.

So run the decision rule honestly. Read-only or standard OAuth? Buy, or start small. Agents deploying to production on infrastructure you own? Budget two quarters, staff the safety story like the product feature it is, and ship a server that any agent — including ones your team will never meet — can call. The protocol war ended without a fight; the least you can do is spend the peace dividend on the parts that keep production safe.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agents as first-class operators is the thesis: a deploy/rollback tool surface over your own fleet is exactly what MCP was built for. Star the repo on GitHub or deploy your first app today.