Adamarant
HomeServicesTeamBlogContact
AI and Automation

Build vs buy MCP server: when to write your own and when to buy

Self-hosting an MCP server costs $50k to $150k per integration per year. Buying solves 80% of cases, building wins the rest. Here is how to decide.

April 24, 20269 min readBy Stefano
Build vs buy MCP server: when to write your own and when to buy

An MCP server is a backend process that exposes tools, resources, and prompts over the Streamable HTTP transport so an AI client like Claude, Cursor, or ChatGPT can call them as first-class capabilities. The build vs buy question is whether to stand up that backend yourself or let a managed vendor run it for you. The honest answer in 2026: buy for the 80% of integrations that are commodity, build for the 20% where the MCP server is part of your product or touches data you cannot hand to a third party.

This decision matters because the cost gap is wide. Custom MCP servers run $50,000 to $150,000 per integration per year once you count authentication, governance, and upkeep. A managed server for the same integration typically costs a fraction of that, with the tradeoff of handing the tool surface to a vendor. The question is not "which is better" in the abstract. It is "for this integration, at this stage, which set of tradeoffs fits".

TL;DR: who picks what

  • Buy if you are connecting to a popular SaaS (Slack, Notion, GitHub, Google Drive, Stripe), need OAuth and audit logs on day one, and want your engineers working on product instead of plumbing.
  • Build if the MCP server is the product (you sell AI access to a specific system), the data is regulated or proprietary, or no managed vendor covers the surface you need.
  • Hybrid is the stable end state for most teams: buy the commodity surfaces, build the two or three that are differentiating or sensitive.

What you are actually buying

When we say buy, we mean pointing an AI client at a managed MCP server run by a third party. Major options in early 2026:

  • Cloudflare Agents. Managed remote MCP servers with OAuth via workers-oauth-provider, MCP Server Portals for centralized routing, and a catalog of first-party servers for Cloudflare's own APIs.
  • Truto, Composio, Kong MCP Gateway. Multi-tenant gateways that wrap hundreds of SaaS APIs behind one registered integration, with OAuth, rate limiting, and tool-level permissions.
  • Official MCP Registry at registry.modelcontextprotocol.io, which does not host servers itself but publishes a verified catalog pointing to npm, PyPI, or Docker packages.
  • First-party managed servers from GitHub, Atlassian, Notion, and others, run by the SaaS vendor for their own product surface.

Gartner projects that by 2026, 75% of API gateway vendors and 50% of iPaaS vendors will ship MCP features. Buy is no longer an early-adopter bet.

The axes that actually decide

Time to first working tool

Buying gets you from zero to a working MCP tool in hours. Building the same thing takes 80 to 120 hours for a simple database connector and 150 to 250 hours for an API integration server, with 400 to 800 hours needed for multi-system orchestration. If you need the tool live this quarter, that gap is the whole argument.

Authentication

The first wall every self-hosted team hits is OAuth. The 2025-06-18 spec revision made OAuth 2.1 mandatory for remote servers. Managed servers ship this by default. Building it yourself means implementing dynamic client registration, consent screens, token exchange, refresh handling, and scope enforcement. Libraries like Cloudflare's OAuth provider cut the work substantially, but you still own integrating identity providers (GitHub, Google, WorkOS, your own IdP).

Security posture

MCP servers have a nontrivial attack surface. In 2025 and early 2026, researchers disclosed CVE-2025-53818 (command injection in the GitHub Kanban MCP server), CVE-2025-53110 (filesystem sandbox escape in the reference MCP filesystem server), and an Anthropic MCP SDK flaw that affected more than 7,000 publicly accessible servers. Indirect prompt injection through tool output remains an unsolved class of risk, documented by Microsoft, by Palo Alto Unit 42, and by Simon Willison. A managed vendor owns patching, disclosure, and the forensic trail. A self-hosted server makes that your team's job, indefinitely.

Cost at scale

At a loaded engineering cost of $100 per hour, a medium custom MCP server consumes $1,200 to $2,600 per month in maintenance time alone. Multiply that across ten integrations and you have two FTE budgeted purely on MCP plumbing. Managed pricing typically comes in as per-seat or per-call with a floor under $1,000 per month per integration. The break-even arrives faster than most teams expect, usually within the first six months of the third integration.

Data residency and compliance

A managed MCP server sees, at minimum, the tool arguments and return values passing through it. For HIPAA-, GDPR-, PCI-, or customer-proprietary data, that is often a non-starter without a signed DPA, a regional deployment guarantee, and a right to audit. Not every managed vendor provides all three. Building keeps the data in your VPC and the control plane in your SOC.

Protocol velocity

The MCP spec has shipped three major revisions since late 2024: the initial November 2024 release, the 2025-03-26 revision that introduced Streamable HTTP and remote auth, and the 2025-06-18 revision that made OAuth 2.1 mandatory and added elicitation. The 2026 roadmap adds asynchronous operations, multi-modal content, and stronger agent-to-agent patterns. Managed servers absorb protocol churn. Self-hosted servers force you to re-read the spec every quarter and ship a client migration with each breaking change.

Where building wins

When MCP access is the product

If you sell AI access to a specific system that no one else owns (a vertical SaaS, a proprietary dataset, a regulated industry workflow), the MCP server is not plumbing, it is the surface your customers pay for. Building it is a product investment, not a cost center. The economics flip: the 400 to 800 hours you would spend are also the hours you are already spending on API design, and the maintenance burden is the same burden you already carry on your public API.

When the data cannot leave your perimeter

Customer financial records, health records, legal discovery, or proprietary research cannot pass through a third-party gateway without contract changes most enterprise buyers are unwilling to sign. In that case the only question is which stack you build on. Cloudflare Workers with the Agents SDK is the fastest on-ramp. A plain Node or Python process behind your existing ingress works too, as long as it terminates OAuth properly.

When no managed vendor covers the surface you need

The MCP ecosystem is broad but uneven. Common surfaces (Slack, Notion, GitHub, Google Workspace, major databases) have three or four managed options each. Niche surfaces (your company's internal ERP, a vertical industry API, a custom inference service) have zero. If the only vendor offering your system is the SaaS vendor themselves, and their server cannot express the tools you actually need, building is the fallback.

When you need tool-level control beyond what a vendor exposes

Managed MCP servers typically expose a curated tool set. If you need tools the vendor has not built, need to compose tools across systems the vendor handles separately, or need authorization logic tied to your own roles and entitlements, you write them yourself.

Where buying wins

When the integration is commodity

Integrations with major SaaS platforms are near-identical across companies. The OAuth flow is the same. The tool list is the same. The rate limits are the same. Paying a vendor to maintain that once, for everyone, and passing the cost to customers (or amortizing it across your own product) is cheaper than reinventing it per team.

When you need it live this week

Speed matters when AI features are a competitive bet rather than a platform investment. A team that ships an AI assistant in two weeks using a managed MCP captures the market the team still building OAuth on their custom server loses.

When your security team is already stretched

MCP added roughly 200,000 new publicly accessible servers to the attack surface in 2025. Vulnerability disclosure has been frequent. If your security team cannot keep up with Dependabot already, a self-hosted MCP server is a liability the managed vendor is paid to carry.

When you want a single pane of governance

Cloudflare MCP Server Portals or Kong MCP Gateway give you one endpoint to monitor, rate-limit, and audit, even if the servers behind it are multiple. Building that governance layer yourself is a second project on top of the servers themselves.

What we do at Studio

We default to the hybrid pattern. For SaaS integrations a client already uses (Slack, Notion, GitHub, Stripe), we wire a managed MCP server and focus our time on the agent logic that calls it. For access to the client's own database, internal services, or customer data, we build a small MCP server on Cloudflare Workers with the Agents SDK, typically 2 to 3 weeks including OAuth, audit logging, and deployment. For deeper context on what that build looks like inside an existing codebase, see our guide on how to build an MCP server for an existing Next.js SaaS, and the product-level framing in what MCP is and when a SaaS needs one.

Two rules we hold to. First, no production MCP server runs without OAuth 2.1 and audit logs, whether managed or built. Second, the MCP server is never the place where new features prototype first. We prototype in a stdio server locally, then promote to a remote server with hardened auth when the feature ships.

How to decide for your case

Walk the axes in order, and stop at the first one that forces the answer.

  1. Does the data leave your perimeter legally? If no, build.
  2. Is the MCP server a product you sell? If yes, build.
  3. Does a managed vendor cover this system with the tools you actually need? If no, build.
  4. Does your team need a working integration within two weeks? If yes, buy.
  5. Can your security team own a new public-facing service indefinitely? If no, buy.
  6. Is this one of the three integrations that make your agents different from everyone else's? If yes, consider building. Otherwise, buy.

The mistake we see most often is teams that default to build because MCP looks simple in a five-minute demo, then discover six months in that they have spent more on MCP plumbing than on the AI features it was supposed to enable. Build where building earns it, buy everywhere else.

Sources

Photo by Tyler ↗ on Unsplash ↗

Studio

Start a project.

One partner for companies, public sector, startups and SaaS. Faster delivery, modern tech, lower costs. One team, one invoice.

Tell us what you are buildingRead more articles

Related articles