Managed MCP Server Hosting vs. Building Your Own

By Mark Kuhn · · 6 min read

Writing an MCP server is a weekend. Running one in production is a job. Here's an honest breakdown of what DIY actually costs and when managed hosting is the right call.

Building an MCP server is genuinely easy. The SDKs are good, the protocol is small, and you can have a server exposing one tool in an afternoon. This is not marketing spin — it's true, and it's why "just build your own" is reasonable advice for a lot of cases.

So let me be straight about where that advice stops working, because the gap between "I built an MCP server" and "I run an MCP server my team depends on" is wider than it looks. That gap is the whole reason managed hosting exists, and it's worth walking through honestly — including the cases where you should absolutely just build it yourself.

What the demo hides

The tutorial version of an MCP server is a script. It runs on your laptop, it talks over stdio, it wraps one endpoint, and it works. Ship that mental model to production and here's what you discover you also signed up for:

Somewhere to run it. A laptop script isn't reachable by your team or by a cloud AI client. Now you need a host — a process that stays up, a URL that resolves, TLS, a deploy pipeline. That's a small always-on service to own and patch.

Credential storage that isn't a plaintext env var. Your server holds the keys to the upstream API. In a demo that's API_KEY in your shell. In production it's an encryption-at-rest story, a rotation story, and an "who can read these" story. Getting this wrong is the kind of mistake that ends up in an incident writeup.

Authentication on the server itself. An MCP server sitting at a public URL with no auth is an open door to whatever it wraps. Real deployments need the server to authenticate its clients — and if you want it to work smoothly with cloud clients like Claude, that increasingly means implementing the MCP authorization spec: OAuth 2.1, PKCE, dynamic client registration, the works. That's not a weekend anymore.

Rate limiting and timeouts. The moment an AI agent can call your API in a loop, you need to protect the upstream from getting hammered — per-client limits, sane timeouts, backoff when the API pushes back. A model that retries an expensive endpoint ten times because it's "not sure it worked" will find the ceiling you forgot to build.

Updates. Your API changes. New endpoints, renamed fields, a deprecated route. Every one of those is a change to the server, redeployed and retested. The server is not a build-once artifact; it's a thing you maintain for as long as the API lives.

None of these are hard individually. The problem is that they're all ongoing, and they're the unglamorous 90% that the afternoon demo skips.

The part almost nobody accounts for

There's one more that deserves its own paragraph because it's a genuine security landmine: if your server ever wraps a URL it didn't hardcode — a base URL from config, anything user-supplied — you've built a server-side request forger unless you actively prevent it.

An AI agent asking your server to fetch http://169.254.169.254/ isn't hypothetical; that's the cloud metadata endpoint, and on a misconfigured host it hands out credentials. A robust server has to resolve the destination host and reject loopback, private, link-local, and reserved ranges — and do it at connection time, not just by inspecting the string, because DNS can resolve to a public IP on the first check and a private one on the second (that's a DNS-rebinding attack, and it's a real technique, not a theoretical one). Building that correctly is a security project in its own right. It's the sort of thing that's invisible until it isn't.

I'm not raising this to scare anyone off building. I'm raising it because "wrap an arbitrary API as an MCP server" quietly includes "write an SSRF guard," and a lot of DIY servers simply don't.

When you should build your own

Managed hosting is not the answer to everything. Build it yourself when:

  • The logic is bespoke. Your tools do real work — orchestrating multiple calls, transforming data, enforcing business rules that don't map to "call this endpoint." A generic wrapper can't express that; your code can.
  • It never leaves your machine. A personal, local, stdio server that wraps something for your own use has none of the hosting, auth, or SSRF concerns above. Build it. It's an afternoon and it's yours.
  • You have hard constraints — an air-gapped environment, a compliance regime that dictates exactly where the process runs, an existing platform you must slot into. Sometimes the constraint decides for you.

If you're in one of these, the honest recommendation is to reach for the official MCP SDKs and go.

When managed hosting wins

Managed hosting wins in the common case, which is more common than the exceptions: you have one or more existing REST APIs, they're already documented with a spec, and what you actually want is for AI agents to call them — safely, without you standing up and babysitting a fleet of small services.

That's the case API2MCP is built for. You register the API, it turns the endpoints into tools from the spec, and the platform owns the parts you'd otherwise be maintaining forever: encrypted credential storage with server-side injection, authentication on the server including the full OAuth 2.1 flow that cloud clients expect, per-tier rate limiting with a token-bucket throttle in front of your upstream, response caching, and the SSRF guard described above running on every outbound call. You get a server URL and a token; you don't get a new service to operate.

The trade you're making is the usual build-vs-buy one. DIY gives you total control and costs you ongoing engineering time. Managed gives you those hardened defaults immediately and costs you a subscription. For a bespoke, do-real-work server, control is worth it. For "make my existing API callable by Claude and Cursor," paying to skip the 90% is almost always the better deal.

A straight answer

If you're wrapping standard REST endpoints so AI agents can use them, and you'd rather not run infrastructure to do it, managed hosting is the right call — and you can start on the free tier without a card to see whether your API reads well as a set of tools before you commit to anything.

If your server needs to do things a wrapper can't, build it, and build the security in on purpose. Either way, the useful move is to be clear-eyed about which situation you're actually in — because the demo makes both look like the same afternoon, and only one of them is.