How to Build an MCP Server for Your SaaS Product

Building an MCP server costs between $100K and $1M+ in 2026, and the server code itself is the cheap part. Authentication, audit logging, safety controls, and distribution consume the majority of the budget for production MCP servers. That’s the reality most teams don’t see coming — they budget for a two-week integration project and end up funding a multi-quarter platform build. If your SaaS product needs AI agents to interact with it, here’s how to scope the actual work, avoid the 60-80% cost underestimation trap, and ship something that won’t collapse under production load.

The Non-Protocol Cost Dominance Pattern

What I call the Non-Protocol Cost Dominance pattern explains why MCP server budgets balloon so predictably. Tool handlers and basic transport — the parts every tutorial shows you how to build — represent roughly 10% of production MCP effort. The other 90% is authentication, authorization, rate limiting, observability, PII protection, prompt injection defense, multi-tenant isolation, versioning, compliance, and ongoing maintenance. Zuplo’s analysis calls this the build-vs-buy iceberg, and it’s the single most important mental model for anyone planning an MCP deployment.

The numbers back this up. Building a production-grade multi-tenant MCP server from scratch costs $60,000 to $120,000 and takes months of engineering time. A focused production-grade internal-product server takes 8-16 weeks to build, with ongoing maintenance costing 10-20% of the initial build cost per year. And those figures assume you correctly scope the work upfront — which almost nobody does. Build-cost estimates for MCP servers land at reliably 60-80% of actual final cost, per Digital Applied’s TCO analysis.

The takeaway isn’t that MCP is expensive. It’s that the protocol is the easy part. Everything around it — the operational infrastructure that makes an MCP server safe, reliable, and multi-tenant — is where your engineering months disappear.

Before You Build: Check the Public Catalog First

The public MCP catalog covers more than most teams realize. By March 2026, the ecosystem had over 10,000 active public servers, with pre-built, vendor-maintained integrations for Salesforce, Slack, GitHub, Notion, Stripe, Postgres, Snowflake, and dozens of other tools your customers already use. Design Key’s analysis found that the catalog covers 80%+ of integration needs in 2026. The first answer to “should we build a custom MCP server” is almost always no.

The 10% of cases where building makes sense share four traits: proprietary data the public catalog can’t reach, auth or audit requirements public servers don’t meet, performance characteristics that demand local-first execution, or a workflow that needs a tool surface no one else has standardized yet. If your project doesn’t hit at least one of those, you’re building for the sake of building — and paying 2-3x the initial estimate to do it.

For teams still weighing the strategic question, our guide on how MCP changes SaaS development workflows covers the non-functional requirements that consume most of the budget.

Choosing Your Transport and Auth Stack

Streamable HTTP is the recommended transport protocol for production SaaS MCP deployments. The older stdio transport works for local development, but it doesn’t scale across multiple sessions and users. The July 2026 spec update — the largest revision since the protocol launched — makes Streamable HTTP significantly easier to operate by removing the session layer entirely. Servers can now run behind a plain round-robin load balancer without sticky sessions or shared session stores.

On authentication, MCP mandates OAuth 2.1 with PKCE for remote server authentication and explicitly prohibits token passthrough. This isn’t optional. Nearly a quarter of respondents running MCP servers have no authentication at all, per Zuplo’s State of MCP report, and 53% of open-source MCP servers still rely on static API keys instead of OAuth. Of the 30+ MCP-related CVEs filed in early 2026, 43% involved command injection. The auth layer isn’t where you cut corners.

The July 2026 spec also introduces breaking changes to transport, authorization, and tool schema handling. If you’re building now, target the new spec — the final version ships July 28, 2026 — because migrating an already-shipped server later adds unplanned engineering costs. The stateless core and hardened OAuth 2.1 support eliminate the need for sticky sessions, shared session stores, and custom JSON config files, which simplifies production operations significantly.

Designing Your Tool Surface

MCP gives you three primitives: tools (callable functions the agent invokes), resources (readable content the client fetches), and prompts (reusable prompt templates). A newer fourth primitive, sampling, lets the server request LLM completions from the client. Your tool surface is the contract between your SaaS product and every AI agent that will ever interact with it — design it with the same rigor you’d apply to a public API.

Each tool needs a precise name, typed input schema, and clear description. Agents read tool names and descriptions to decide what to call, so vague naming creates real failures. A tool called search with a generic query parameter is harder for an agent to use correctly than search_tickets with explicit status, assignee, and date_range parameters.

Scope each tool to the narrowest permission the task allows. Omnibus tools that accept free-form input and dispatch at runtime are the single most common critical finding in production MCP security audits. If your tool doesn’t need write access, make it read-only. If it doesn’t need access to all records, scope it to the requesting user’s tenant and permission level.

The Build-vs-Buy Decision Framework

Here’s a comparison of the three main paths teams take when adding MCP support to a SaaS product:

Path	Timeline	Typical Cost	Ongoing Effort	Best For
Off-the-shelf open-source MCP server	1–3 days to configure	$0 software + $1,000–$5,000 integration labor	Low — community patches	Mainstream SaaS tools with standard auth
Managed MCP hosting (cloud marketplace)	1–2 days	$50–$500/month SaaS fee	Minimal	Teams without ops capacity
Custom MCP server (single data source)	2–8 weeks	$8,000–$15,000	10–20% of build/year	Proprietary APIs, custom auth needs
Custom production-grade multi-tenant build	8–16 weeks	$60,000–$120,000+	10–20% of build/year	Multi-tenant SaaS with compliance requirements

The math overwhelmingly favors buying for standard integrations. Building and maintaining a single custom MCP server in-house typically costs $50,000 to $150,000 per integration per year, per Truto’s analysis. That includes development, QA, monitoring, and ongoing support — and it’s driven by mandatory operational overhead, not unique feature work.

For the realistic first-year projection: a SaaS product building a production-grade, multi-tenant MCP server with 4+ data source integrations is looking at $60,000–$120,000 for the initial build, plus $6,000–$24,000 for first-year maintenance (10–20%). Factor in the typical 60–80% cost underestimation gap, and the total first-year range lands at $66,000–$168,000.

Deployment and the July 2026 Spec Migration

The 2026-07-28 specification release candidate makes the protocol stateless, removes the initialize/initialized handshake and Mcp-Session-Id header, and requires Mcp-Method and Mcp-Name headers for Streamable HTTP transport. The practical effect is that a remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a standard load balancer with standard OAuth login flows.

This is a genuine operational improvement, but it also means every existing production MCP server needs to be migrated by July 2026. If you’re building a new server now, implement against the 2026-07-28 spec from day one. The migration cost for teams that have already shipped custom builds on the old spec is real and unplanned.

For a deeper look at the security implications and the full list of breaking changes, our post on MCP security risks covers the CVEs, auth gaps, and governance requirements that engineering teams need to address before production.

The Real Question: Is Your MCP Server the Product?

Here’s the contrarian take that most MCP content won’t give you: for 80% of enterprise MCP use cases in 2026, teams should default to using a public catalog server or managed MCP service rather than building custom. The hidden operational overhead of custom builds results in actual costs tracking 1.25x–1.67x higher than initial estimates, with no functional benefit for standard integration needs.

Build a custom MCP server when it’s the product — when the server itself is what you’re selling, or when it connects to proprietary systems with no public alternative. For everything else, the math favors buying. The engineering hours you save on OAuth implementation, tenant isolation, and rate limiting are hours you can spend on the features that actually differentiate your product.

The teams winning with MCP right now aren’t the ones with the most sophisticated server infrastructure. They’re the ones who correctly identified that their use case was standard, used a vendor-maintained server, and spent their engineering budget elsewhere.