The 20% that's genuinely easy
Let's concede the point upfront: the MCP server is easy now. Ask any coding assistant and you'll have tools speaking Streamable HTTP before lunch. If your goal is a demo on your own machine with your own API key, build it in-house — sincerely.
The 80% that isn't
The moment the user of your MCP is a paying customer instead of you, the server becomes the smallest component in the system. What you're actually signing up to build:
- Identity per customer. A credential store with encryption at rest, upstream key validation, per-customer forwarding, one-click revocation, refresh-token rotation with reuse detection.
- An OAuth 2.1 authorization server. Real AI clients demand protected-resource metadata, RFC 8414 discovery, dynamic client registration, and PKCE — that's four RFCs before your first tool call.
- Protection. Per-minute rate limits with burst, monthly caps with notify/auto-pause, per-customer allowances, origin/IP allowlists.
- Observability. Request logs that include auth failures (or you'll debug "nothing happened" blind), per-customer usage, latency percentiles, retention.
- Client-compatibility scar tissue. The 405-vs-401 handshake rule, CORS headers the spec revision added, CDN AI-bot blocking — bugs that only production clients expose.
- Keeping up. The MCP spec ships breaking revisions; every one is a maintenance sprint you didn't plan.
We measured it, accidentally
We took a real deployment — AnnounceKit's GraphQL API, 84 tools — through the production clients of Claude, Cursor and ChatGPT. Three separate integration failures surfaced in a single day, none visible in spec-level testing. That's what "we'll just build it in-house" actually costs: not the first afternoon, but every afternoon after.
The build-vs-buy math
A minimal in-house gateway is an engineer-quarter to build and a permanent on-call surface to run. A hosted deployment is $9.99/endpoint/month (there's a free tier to prove it works). The question isn't whether you can build it — it's whether the gateway is where you want your engineers differentiating.
A fair decision rule
And building the gateway is still only half the job — a server nobody can find isn't a channel. See the distribution playbook for the other half.
See what the hosted gateway includes →
FAQ
- Isn't writing an MCP server easy now that AI can scaffold one?
- Yes — and that's the trap. An AI assistant scaffolds a working MCP server in an afternoon. What it doesn't scaffold is the production gateway: per-customer credentials with encryption and revocation, an OAuth 2.1 authorization server (discovery, dynamic client registration, PKCE, refresh rotation), rate limits and quotas, request logs, and compatibility fixes for real clients. That's the 80% you'd still be building three months later.
- What breaks when a homegrown MCP server meets real clients?
- In our production experience: authenticated GET probes answered with the wrong status code send Claude into infinite re-auth loops; missing CORS headers (MCP-Protocol-Version) block every browser-based request client-side; and CDN AI-bot protection silently eats tool calls. None of these appear in curl tests.
- When does building in-house make sense?
- If MCP infrastructure is your product, or you have hard on-prem/data-residency constraints a hosted gateway can't meet. For everyone else, the build-vs-buy math is a gateway team versus $9.99 per endpoint per month.