MCP server hosting: hosted, self-hosted or serverless, with the real trade-offs
Pick hosted when your agent needs OAuth, token refresh and uptime you do not want to own. Pick self-hosted when the data cannot leave your network. Serverless sits between them, and it got easier in 2026: the July 28 spec revision dropped protocol-level sessions, so a remote MCP server can now be stateless.
What MCP server hosting means after the 2026-07-28 spec
An MCP server answers JSON-RPC over one of two bindings. On stdio, your client launches it as a subprocess on the same machine. On Streamable HTTP, it is a web service with a single POST endpoint. Hosting is only a question for the second one.
Revision 2026-07-28 changed what that service has to hold in memory. It removed protocol-level sessions and the standalone GET stream, and it moved the protocol version and client capabilities into per-request _meta fields that the transport mirrors into HTTP headers. Earlier revisions, 2025-03-26 through 2025-11-25, did the opposite: the server could mint an Mcp-Session-Id, the client could reopen a long-lived stream with GET, and streams were resumable with Last-Event-ID. None of those mechanisms exist in the current revision, and a server that only speaks it should answer GET or DELETE on the MCP endpoint with 405 Method Not Allowed.
That single change is most of the hosting story. A server with no session state is an ordinary stateless HTTP service: run four replicas behind a load balancer, deploy mid-conversation, lose an instance, and no client has to reconnect. A server still speaking the 2025 revisions has to route every request back to the instance holding that session, which is why so many early remote deployments were one box with sticky sessions and a nervous owner.
Two caveats worth knowing before you plan capacity. Streams are no longer resumable, so a dropped connection means the client reissues the request rather than picking up where it left off. And long-lived change notifications now ride on the response stream of a subscriptions/listen request, which is a stream you do have to keep open, with keep-alive comments, for as long as the client listens.
Remote MCP server or local: what actually changes
A local stdio server inherits your machine: your filesystem, your environment variables, your network. Credentials come from the environment, and the spec explicitly says stdio implementations should not follow the OAuth flow. That is why a local server is quick to build and impossible to share.
The moment the server becomes remote, four things land on whoever runs it:
- Identity. HTTP-based servers are OAuth 2.1 resource servers. They must implement Protected Resource Metadata (RFC 9728), validate that each token was issued for them as the audience, per the authorization spec, and return
401with aWWW-Authenticateheader carrying theresource_metadataURL and the requiredscope. - Platform tokens. The agent's token gets it into your server. Your server still needs its own credentials for whatever it talks to, and those expire on somebody else's schedule.
- Logs. A tool call that published something is an action in the world. Without a per-call record you cannot answer what the agent did at 3am.
- Availability. An agent that cannot reach the server does not degrade gracefully, it reports that the tool does not exist.
The work nobody counts on a hosted MCP server
The OAuth dance is the part people estimate, and it is not the expensive part. The expensive parts are the ones with no end date.
Token refresh is the first. Every platform you connect hands back a credential with its own lifetime and its own renewal ritual, and a silent expiry looks exactly like a bug in your agent. PlugKit's own WhatsApp docs make the point concretely: connect a real number, because a Meta test number ships a 24-hour token and stops working the next day.
The second is the consent loop. Tokens expire, users revoke apps, and scopes turn out to be too narrow. The spec has a path for the last case: the server answers 403 with error="insufficient_scope" and the scopes needed, and the client runs a step-up flow requesting the union of what it had and what was just demanded. Implement that badly and your users live in a redirect loop.
The third is simply being reachable. Agents retry, and an agent retrying a publish tool is not an idempotent event.
Hosted, self-hosted or serverless
| What you carry | Hosted | Self-hosted | Serverless |
|---|---|---|---|
| Monthly floor | a subscription, PlugKit Creator is $49 a month for 5 connected accounts | a VM or cluster plus your hours | per-request billing, near zero when idle |
| OAuth 2.1 resource server | done for you | yours to build and keep current with the spec | yours, plus a token store outside the function |
| Platform token refresh | done for you, silently | a background job you must monitor | needs durable state, so not really serverless |
| Audit log of tool calls | vendor's, readable | yours | yours, and scattered across invocations |
Long-lived subscriptions/listen streams |
vendor's problem | fine | awkward, most platforms cap execution time |
| Data residency | vendor's region | wherever you want | vendor's region |
| Who gets paged at 3am | the vendor | you | you, but less often |
Serverless reads cheapest and often is, for a read-only server over a public API with no credentials to keep. Add OAuth and refreshable platform tokens and you have reintroduced a database, a scheduler and a secret store, which is the infrastructure you were avoiding. Add an open notification stream and you hit execution-time caps.
Self-hosted wins on two arguments and they are good ones: the data genuinely cannot leave your network, or the tools you are exposing are yours and nobody sells them. If either applies, host it yourself and budget for the OAuth work as real work.
Where PlugKit sits, and when it is the wrong answer
PlugKit is the hosted case for one narrow job: handing an agent your social accounts. The server lives at https://api.plugkit.co/mcp, speaks Streamable HTTP, is stateless, and exposes 103 tools plus three prepared workflows, verified on docs.plugkit.co on October 21, 2026. Authentication is OAuth 2.1 with PKCE and no client secret, with two scopes: mcp:read for profiles, accounts, posts, conversations and analytics, mcp:write to add publishing, messaging, comment replies and connecting accounts. Clients without OAuth send an API key as a bearer token, which has full access and no scopes.
Adding it to Claude Code is one line:
claude mcp add -t http plugkit https://api.plugkit.co/mcp
It is $49 a month for 5 connected accounts or $97 for 30, cancel anytime, after 7 days free with no card, one connected account during the trial. One honest caveat from the same docs: the server asks the model to get your approval before a public write, and that is a prompt-level instruction, not an enforced control. If that matters, grant mcp:read and keep writes behind your own code.
PlugKit is the wrong answer when the tools you want are not social accounts, when your compliance rules say the tokens stay in your VPC, or when you want deterministic publishing with no model in the loop. The last case is a REST call, not an MCP server at all, and the trade-off is laid out in MCP or REST API for your agent. For the authentication mechanics in detail, read MCP server OAuth. For what a single-platform hosted server looks like in practice, the Instagram MCP server, and for who else ships one, social media MCP servers compared.
FAQ
Do I need to host an MCP server at all?
Not if it runs on your own machine for your own use. A stdio server launched by your client needs no hosting and no OAuth, and it reads credentials from the environment. You need hosting the moment a second person, a phone or a cloud agent has to reach the same tools.
Can an MCP server be stateless?
Since revision 2026-07-28, yes. That revision removed protocol-level sessions and the GET stream, so every POST carries its own metadata and any instance can answer it. Servers that still support the 2025 revisions keep session state and need sticky routing.
What does a hosted MCP server actually do that I would otherwise build?
The OAuth 2.1 resource server with Protected Resource Metadata and audience validation, the refresh loop for every platform token, the per-call audit log, the step-up flow when a scope is missing, and the uptime. The first is a sprint; the rest never finish.
Is serverless a good fit for MCP?
For a read-only server with no stored credentials, yes. Once you need OAuth, refreshable tokens or an open subscriptions/listen stream, you need durable state and long-running connections, and you end up rebuilding a server with extra steps.
How do I point a client at a remote MCP server?
Give it the endpoint URL. In Claude Code, claude mcp add -t http <name> <url>. In Claude's apps, Customize then Connectors then a custom connector. In Cursor or VS Code, a one-click install link or three lines of JSON. The client discovers the authorization server from the 401 the endpoint returns.
One plug for every platform your agent touches
$49 a month for 5 connected accounts, cancel anytime. Every feature in every plan.
Get your API key →