MCP server hosting: what you take on, and what you can hand off

Host it yourself when the tools it exposes are the differentiated part of your product, when the data must not leave your network, or when you already operate the service they wrap. Take a managed path when the server is a means to an end: you want an agent using those tools, not another service on the on-call rota. Many teams do both: their own server, someone else running the agent in front of it.

The three words get used interchangeably by vendors and they are not the same claim. Separating them is most of the work of this decision.

• Remote says where the server runs relative to the client: reachable over HTTPS rather than launched as a local process beside it. This is a transport fact, and it decides whether an agent running in somebody else's infrastructure can reach the server at all.
• Hosted says who owns the machine. It says nothing about who gets paged when a tool starts returning 500s at four in the afternoon.
• Managed says who is responsible for it working: patching, credentials, uptime, keeping the tool schemas honest, and the pager. It is the only one of the three that is a commercial commitment rather than a deployment detail.

None of this is hard in isolation. It is a standing cost, and the reason to name it item by item is that it usually gets estimated as one line called "stand up an MCP server" and then paid over the following two years.

• Authentication. MCP does not decide how a caller proves who it is, so you do. A static token is the fast start and the thing that gets rotated badly; an OAuth exchange is the honest answer and is its own project.
• Uptime. The server sits in the request path of a live conversation. When it is unavailable the agent does not degrade politely — it stalls in front of a customer, or answers without the data it was supposed to have.
• Tool versioning. Renaming a tool or making an argument required is a breaking change for every client already calling it. Unlike your HTTP API, you do not control those callers and do not get to run a deprecation window on your own schedule.
• Access scoping. Which tools a given caller may reach is a product decision that has to be enforced somewhere. Granting the whole toolset to everything that connects is the default, and it is the arrangement you get asked about after an incident rather than before one.
• Schema drift. Tool descriptions are prompts. When the product changes and the descriptions do not, a model keeps calling tools on stale assumptions and nothing fails loudly: the tests pass, the traces look ordinary, and the answers are quietly wrong.

Two situations settle this without a spreadsheet, and in both of them the server belongs to you.

• The tool surface is the product. A telemetry vendor whose value is its query engine should own the server exposing it. The set of tools, their arguments and their descriptions are that product's public vocabulary and a roadmap decision, and handing it over means negotiating your own API surface against someone else's release cycle.
• The data is not allowed to leave. A payroll or clinical system whose tools read records that cannot transit a third party. The server belongs inside the network boundary the auditors have already signed off on, and that boundary is the entire reason it exists rather than a direct integration.

A buy-versus-build page written by a vendor is worth reading only if it is straight about which side the vendor is on. We do not run arbitrary third-party MCP servers. We consume yours: the server stays wherever it already lives, and the agent connects out to it.

Four mechanics are worth knowing before that connection becomes a line in an architecture diagram.

• Transport is remote MCP over HTTPS.
• Tools are discovered live from the server before the connection is saved, so a server whose shape has moved says so at configuration time rather than mid-conversation some weeks later.
• Four authentication modes are supported: static headers, OAuth2 client credentials with the token cached and refreshed a minute before it expires, a locally minted JWT carrying your own claims and expiry, and the full OAuth2 authorization-code exchange with redirect and refresh.
• A server is attached per agent, not per account. The tools a given conversation can reach are an explicit list somebody chose, which is the difference between an agent you can reason about and one you reconstruct from logs afterwards.

There is one MCP server in this arrangement that we do operate, and it is ours. The tools that build and run an agent — create a flow, add a stage, set the examples that shape how it answers, write an SOP, hold a test conversation, read back what happened in production — are themselves an MCP surface. The dashboard is one client of it rather than the source of truth, so an agent can be built and operated from your own tooling.

This is usually what someone is after when they go looking for a no-code MCP server or an MCP server SaaS: they want the managed answer and get shown the hosted one. The wider integration layer, including where UCP and agentic commerce fit, is on the API, webhooks and MCP page.

If you have read this far you probably already run the server. The open question is who operates the thing talking to your customers on top of it, and that is a different job from keeping a tool endpoint up. It needs conversation design that holds under real traffic, grounding in data that changes daily, the same agent working across web chat, WhatsApp, voice and email, an escalation path that hands a human the context rather than the transcript, and enough traceability to answer whether it is telling customers the truth.

You keep your stack, your servers and your client. We bring the agent, and your MCP server stays exactly where it is.