MCP Server Hosting Requirements: A Production Checklist

The minimum requirements for hosting an MCP server are an https URL speaking streamable HTTP, authentication on every request, safe storage for upstream credentials, logging of tool calls, and a way to monitor, restart and update the service. Production adds per-consumer keys, tool allowlists, tenant isolation and a plan for spec changes.

The checklist

Use this as a scoring sheet for a self-hosted setup or any vendor. Score each row met, partly met or missing.

#	Requirement	Why it matters
1	Streamable HTTP over HTTPS with valid certificates	Remote clients cannot use stdio
2	OAuth and per-key bearer authentication	Consumer assistants use OAuth; developer tools use keys
3	One key per consumer, instant revocation	Limits the blast radius of a leak
4	Upstream credentials in an encrypted server-side vault	Agents must never see raw secrets
5	Tool allowlists and data-class access policies	Least privilege per agent
6	Human approval for consequential actions	Sending, spending and deleting need a gate
7	Tenant isolation enforced below the application layer	Prevents cross-customer reads
8	Logging of every tool call with arguments and result	Audit and debugging
9	Monitoring that checks the protocol, not just the port	Catches outages and drift
10	A path to follow spec and SDK revisions	Protocol upkeep never ends
11	Data export and a clear exit	Avoids lock-in

Rows 2 to 8 and 11 echo the eight-point evaluation list in BusinessMCP’s what is MCP hosting guide. That list is vendor-authored, and we have extended it with monitoring and spec upkeep, but the underlying questions are sound for any host.

Transport and endpoint

The spec defines streamable HTTP as the standard remote transport. Your endpoint must accept the initialize handshake, answer tools/list and handle tools/call, with responses as plain JSON or streams. Place it behind TLS. If you run behind a proxy, make sure it does not buffer streamed responses, which breaks long-running tools.

BusinessMCP’s build guide recommends keeping a transport-agnostic server factory with thin entry points for stdio and HTTP, so one codebase serves local and remote. Its stateless pattern, a fresh server and transport per request, suits horizontal scaling.

Authentication requirements

Authentication is not optional for a remote server. The spec treats the MCP server as an OAuth resource server and uses protected-resource metadata (RFC 9728) for discovery. For internal use a bearer token is a common minimum. Full detail is in MCP server hosting with authentication.

Secrets and isolation

Where your server calls upstream APIs, keep those credentials out of agent context. Encrypt them at rest, resolve them server-side and never return them in tool output. If you serve multiple customers, isolate them below your application code. BusinessMCP says it uses row-level security with workspace-scoped tables; for your own multi-tenant server, the equivalent might be separate databases or enforced row-level policies.

Key takeaway: most hosting failures are authorisation failures: a key that can do too much, or a server that can see more than the caller should.

Capacity and cost inputs

Most MCP servers are thin: they translate a tool call into an upstream API call. CPU is rarely the limit; latency and concurrency are. Estimate:

• Concurrent clients at peak.
• Average and worst-case tool call duration.
• Whether any tool streams or holds connections open.
• Upstream rate limits, since your server inherits them.

Then size accordingly and add a ceiling per caller. Pricing mechanics are in our cost article.

Where managed hosts fit the checklist

A managed endpoint can satisfy rows 1 to 8 by default. BusinessMCP’s MCP hosting, for example, describes a bearer-key and OAuth 2.1 endpoint, scoped keys built from data classes, an encrypted vault, per-key audit logs and aggregation of third-party servers. What it does not satisfy is “run my own server code,” which the page states plainly. If that requirement is on your sheet, add a self-hosted component and read self-hosted versus managed.

Before launch

1. Score every row; do not launch with a “missing” on rows 2 to 8.
2. Run a handshake test from each client you support.
3. Revoke a test key and confirm it stops working immediately.
4. Read a day of logs for anything you did not expect.
5. Write down who is paged when the handshake check fails.
6. Record the spec revision you implement and a date to review it.

Requirements by audience

Not every server needs every row at full strength. Calibrate to who will use it.

Audience	Must have	Can defer
Just you, remote for convenience	HTTPS, bearer token, basic logs	OAuth, tenant isolation, approval gates
A small internal team	Per-person keys, revocation, allowlists, monitoring	Custom policy engine
Cloud assistants such as ChatGPT or Claude’s connector UI	OAuth, protected-resource metadata, consent screen	Per-tenant database isolation if single-tenant
Customers of a product you sell	All rows, plus support commitments and an incident process	Nothing

Note the third row. Consumer assistants connect through a sign-in flow, so a plain static token is not enough. BusinessMCP’s page says its endpoint includes OAuth 2.1 with PKCE so Claude.ai’s custom-connector UI can connect, and offers scoped presets on its consent screen. If you build this yourself, plan time for the consent flow, token refresh and metadata endpoints; they are often the largest piece of work.

For the security side of these rows, BusinessMCP’s MCP security best practices gives a threat-to-mitigation table that maps neatly onto rows 3 to 8; it is vendor-authored but the controls are generic.

Common requirement gaps

No health check beyond port 443. Your load balancer says healthy while the server rejects every handshake. Add a protocol-level check, as discussed in MCP server monitoring.

Secrets in environment files committed to a repo. Use a secrets manager and rotate on a schedule.

Logs without arguments. A log that says “tool called” and nothing else is of no use when an agent did something surprising.

No owner. The most expensive missing requirement is a named person who gets the alert. Write the name in the runbook.