MCP server hosting: managed vs. self-hosted deployment

MCP server hosting turns a server that works on your laptop into a remote HTTPS endpoint that ChatGPT, Claude, Cursor, Codex, and other MCP clients can reach. The shortest path is to use a managed host that stores the upstream API credential, protects the MCP endpoint, and gives you a ready connection URL. The self-hosted path gives you more control, but you must own deployment, secrets, authentication, updates, and incident response.

If your API already has an OpenAPI spec, you do not need to hand-write the tool catalog first. You can generate the tool surface, review it, and host the approved tools from the same input.

The fast path with Sourced

1. Open the OpenAPI-to-MCP generator.
2. Paste or upload an OpenAPI 3.x document.
3. Review the generated tools and the read, write, and destructive classifications.
4. Select Host with Sourced.
5. Add the upstream API credential if the API requires one.
6. Copy the hosted /mcp URL and the one-time endpoint token.
7. Add both values to your MCP client.

The Free plan includes one hosted MCP server. It does not require a credit card. Sourced exposes safe read tools by default. It keeps write and destructive operations out of the initial surface unless you explicitly enable them, and destructive calls still require a confirmation value.

Managed hosting vs. self-hosting

Decision	Managed with Sourced	Self-host on Vercel or Cloudflare
OpenAPI conversion	Generated in the browser	Generate or write the server yourself
Public HTTPS endpoint	Created for you	Configure and deploy it
Upstream API credential	Encrypted at rest	Store it in the host's secret manager
MCP endpoint token	Generated once; stored as a hash	Build and operate token or OAuth checks
Default tool surface	Safe read tools	Whatever your code exposes
Destructive operations	Disabled by default and confirmation-gated	You must build the policy
Updates	Regenerate and update the hosted server	Build, test, and redeploy
Best fit	A fast, reviewed OpenAPI-to-MCP path	Custom runtime, OAuth, state, or infrastructure rules

Managed hosting is the better first choice when your server is a thin proxy over a public HTTPS API and the OpenAPI operations map cleanly to tools. Self-hosting is the better choice when you need a custom OAuth consent flow, long-running state, private-network access, unusual middleware, or infrastructure controls that a managed service does not expose.

What a remote MCP endpoint needs

A production endpoint needs more than a successful deploy.

1. Streamable HTTP

Remote clients need an HTTP transport. New deployments should prefer Streamable HTTP. Local stdio remains useful for development, but a cloud client cannot start a process on your laptop.

2. A public HTTPS URL

The endpoint must be reachable by the client. Do not use localhost, a private IP, or plain HTTP for a production connection. A common path is:

https://mcp.example.com/mcp

3. Two separate trust boundaries

Treat these as different credentials:

• MCP endpoint credential: lets the AI client connect to your MCP server.
• Upstream API credential: lets the MCP server call your API.

Do not send the upstream credential to the AI client. The MCP server should hold it and apply it to upstream requests.

4. A narrow tool allowlist

Do not expose every operation only because it exists in OpenAPI. Start with ordinary read operations. Review sensitive reads. Keep create, update, send, charge, revoke, and delete operations out of the first launch unless you have a clear approval rule.

5. Validation after deployment

Test the deployed URL, not only the local server. At minimum, verify:

• the endpoint rejects a missing or invalid access token;
• initialize returns server information;
• tools/list returns the approved tool set;
• a read tool calls the correct upstream URL;
• errors do not reveal credentials;
• a destructive tool fails without explicit confirmation.

Self-hosting on Vercel

Vercel documents MCP deployment with a route handler that serves Streamable HTTP. A typical deployment creates an /api/mcp route, stores secrets as project environment variables, and uses the final Vercel URL in the client config.

Self-hosting on Vercel is useful when your application already uses Next.js or Vercel Functions. You still own the server code, authentication, tool policy, tests, and release process.

Self-hosting on Cloudflare

Cloudflare documents remote MCP servers on Workers. Its current guidance supports stateless Streamable HTTP and authenticated deployments. A Worker is a good fit when you want an edge runtime, Cloudflare Access, or direct control over the deployment.

The same warning applies: a deployment button gives you an endpoint, not a safe tool surface. Review tool permissions and credentials before you connect an agent.

Client configuration example

Most remote MCP clients need the endpoint URL and, when used, an authorization header.

{
  "mcpServers": {
    "your-api": {
      "url": "https://your-host.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${YOUR_MCP_TOKEN}"
      }
    }
  }
}

Keep the real token outside a committed config file. Use the client or operating system's environment-variable support.

Hosting checklist

Use this before you call a remote MCP server ready:

• Public HTTPS /mcp endpoint is reachable.
• Missing endpoint auth returns an error.
• Upstream API secrets never appear in generated files or client config.
• tools/list contains only approved tools.
• Safe read tools work against the intended API environment.
• Sensitive reads have an explicit decision.
• Write and destructive tools are disabled or confirmation-gated.
• Request sizes and upstream response sizes have limits.
• Upstream calls have a timeout.
• Private, loopback, and reserved upstream hosts are blocked when users can set a base URL.
• Tokens can be rotated without changing the public endpoint.
• The final endpoint works in the client you plan to support.

When not to host an MCP server

Do not create a remote server for a one-time API call. A documented curl command is simpler. Do not expose an internal admin API only because a model can call it. Do not use managed hosting when the required authentication model is unsupported.

Sourced managed hosting currently supports bearer credentials, basic auth, API-key headers, and API-key query parameters for the upstream API. OAuth and OpenID Connect upstream flows need a full consent and token lifecycle, so Sourced blocks them instead of pretending a static token is enough.

FAQ

Can I host an MCP server for free?

Yes. Sourced includes one hosted MCP server on the Free plan with no credit card required. You can also self-host on infrastructure that has a free allowance, but you remain responsible for the server and its security.

Does an MCP server need its own domain?

No. It needs a stable public HTTPS URL. A platform subdomain works. A custom domain can make ownership and rotation easier later.

Is hosting the same as generating an MCP server?

No. Generation creates the tool definitions and server behavior. Hosting runs that server at a reachable URL. Sourced can do both from one OpenAPI workflow.

Should I use OAuth or a bearer token?

Use OAuth when each user must grant scoped access through an identity flow. Use a separate endpoint bearer token for a controlled server-to-client connection where static credentials meet your security requirements. Never reuse the upstream API key as the MCP endpoint token.

Can I update the server without changing its URL?

Yes. A managed deployment can update the tool set behind the existing endpoint. Review the tool diff before you update it because adding a tool changes what connected agents can do.

Host an MCP server from OpenAPI or read the MCP server security checklist before you expose write operations.