Hosting an MCP server comes down to one question: who is responsible for the endpoint after the first demo works? There are three honest answers. Your team runs it. Your team deploys it on a general-purpose platform. Or a provider runs it for you as a managed service. Each is a reasonable choice for a different kind of company, and the wrong choice usually shows up as an integration that worked in a demo and then quietly stopped when a client updated.
This article compares the three on the things that matter after launch: who holds the credentials, who answers when a tool fails, what it costs in money and engineering time, and what happens when ChatGPT or Claude change how they connect. If you are still deciding whether your API should have an MCP server at all, start with what an OpenAPI-to-MCP conversion can automate and come back here when the answer is yes.
What an MCP server needs from its host
For the remote SaaS integrations compared here, the MCP server exposes an HTTPS endpoint that assistants call. MCP also supports local servers: the transport specification distinguishes Streamable HTTP from stdio. This guide focuses on hosting a remote endpoint for customer workflows. What makes hosting a real responsibility is everything around the protocol:
- A stable public URL with TLS. Assistants store the URL in a connector configuration. If it changes, every user reconnects.
- Authentication for two parties. The assistant must prove which user it acts for, and the server must hold whatever credential the upstream API needs. These are separate authorization boundaries. This comparison assumes private customer data; authorization is optional at the protocol level, and public tools can be anonymous. See the MCP authorization specification.
- Permission checks on every call. A read tool that returns another customer's record is a data breach, not a bug. See why read-only tools still need permissions.
- Observability. You need to know which tools are called, how often they fail, and whether failures come from input, from the upstream API, or from the server.
- Change management. MCP clients evolve. Transport details, authorization flows, and tool-listing behaviour have all changed within the protocol's short life. Someone has to notice and adapt. The July 2026 protocol changelog gives concrete examples of transport and authorization changes.
With that list in hand, the three options are easier to compare.
Option one: self-hosted
Your team writes the server, deploys it on infrastructure you already run, and owns everything on the list above.
When it fits. You have engineers who already follow the MCP specification, you want the server inside your existing security perimeter, or the integration is central enough to your product that owning it is strategic.
What it costs. Mostly time. The first version is a bounded project; the ongoing cost is the attention needed to keep up with client changes and to investigate tool failures. Infrastructure cost is usually small because the server is a thin layer over your API.
An illustrative failure. The server ships, the engineer who built it moves to another project, and six months later a client update breaks the authorization flow. Nobody notices until a customer complains.
Option two: a general platform
You still write the server, but you deploy it on a platform that handles the HTTPS endpoint, scaling, and logs: a serverless runtime, a container platform, or a platform-as-a-service.
When it fits. You want to avoid running infrastructure but are comfortable owning the code. This is the natural choice for teams that already deploy small services this way.
What it costs. A modest platform bill plus the same engineering attention as self-hosting for everything above the transport layer: tool design, permissions, error contracts, pagination, and client changes.
What goes wrong. The platform solves the easiest part of the list. Credential handling, permission checks, and change management are still yours, and they are the parts that cause incidents.
Option three: managed MCP hosting
A provider designs the tools from your documentation, runs the endpoint under a subdomain you control, and takes responsibility for monitoring, maintenance, and client changes. This is what API to Agents offers as a managed MCP server.
When it fits. You want your service reachable from assistants without adding MCP to your team's responsibilities, you need a fixed price before committing, or you want the design review (which tools, which boundaries, which confirmations) done by people who do it repeatedly.
What it costs. A one-time setup fee quoted from the scope, then a monthly plan. Every line item is published on the pricing page; hosting starts only when the integration is live.
What goes wrong. You depend on the provider's roadmap for new capabilities, and you should check where data is processed. (API to Agents hosts in EU regions.) Enterprise requirements such as private-cloud deployment need a separate conversation.
The comparison at a glance
- Who writes the tools: your team for self-hosted and general-platform deployments; the provider for managed hosting, working from your documentation and reviewing the scope with you.
- Who holds upstream credentials: your team for self-hosted and general-platform deployments; the provider under restricted secrets for managed hosting.
- Permission checks and confirmations: your team designs them for self-hosted and general-platform deployments; they are included in the managed setup scope.
- Monitoring and failure triage: your team for self-hosting; partly the platform, mostly your team on a general platform; the provider for managed hosting.
- Adapting to client changes: your team for self-hosted and general-platform deployments; included in managed hosting.
- Time to first working tool: delivery depends on scope and team experience; managed delivery is estimated in the quote after the audit.
- Cost shape: engineering time for self-hosting; a platform bill plus engineering time on a general platform; fixed setup plus a monthly plan for managed hosting.
A worked example: an order-status tool
Imagine a shop exposing get_order_status(order_id). A customer asks where order ORD-1042 is. The tool must check that the caller can access that order, request its current status from the shop API, and return a useful error if that API is unavailable. This is an illustrative workflow, not a customer case.
With self-hosting, your team owns the tool and the runtime. On a general platform, the platform can keep the endpoint running while your team still fixes an expired upstream credential or an incorrect permission check. In the managed option described above, you agree those responsibilities with the provider as part of the scope. A useful question for any proposal is: who investigates when this one tool starts returning errors, and how do we reach them?
How to decide
Three questions settle most cases:
- Will an engineer own this in a year? If the honest answer is no, self-hosting is the expensive option even though it looks free.
- Is the integration a product or a channel? If assistants are a new channel to your existing product, managed hosting keeps your roadmap on the product. If the MCP layer is the product, own it.
- Do you need a price before you start? Managed providers quote from scope. Self-hosting estimates are usually optimistic because the design work (which tools, which boundaries) is discovered along the way.
Whichever you choose, do the design work first. Choosing which actions to expose, writing descriptions an assistant can act on, and building an evaluation set are needed under every hosting model.
If you want to see what the managed path would look like for your API, the Agent Readiness Audit proposes the tools, lists the risks, and returns a fixed quote in about two minutes, without credentials.