What is a remote MCP server?

A remote MCP server is an MCP server hosted at a public HTTPS URL, which AI assistants such as Claude or ChatGPT connect to over the network using the Streamable HTTP transport. Unlike a local server, which runs as a subprocess on one person's computer, a remote server can be used by a whole team, from any device, with each person signing in with their own account.

What is the difference between a local and a remote MCP server?

A local server runs on the user's machine, launched by the assistant over stdio, with credentials kept on that machine. A remote server runs on a server you host, reached over HTTPS, with users authorized through OAuth. Local suits a developer's own tools and files; remote suits business systems shared by a team.

Can Claude and ChatGPT connect to a remote MCP server?

Yes. In Claude, you add it as a custom connector by pasting its URL; on Team and Enterprise plans an owner adds it once and each member connects with their own account. In ChatGPT, custom MCP connectors with write actions sit behind Developer mode. Both need the server to be a public HTTPS endpoint.

Should an MCP server be part of my application or a separate service?

Embed it in the application when the system is yours: the tools reuse the app's code, database, accounts and permissions, and ship with its releases. Run a separate server when you need to reach systems you can't modify, such as SaaS products or legacy software: it translates tool calls into their APIs, with its own sign-in. We run both.

Where should I host a remote MCP server?

Anywhere that serves HTTPS reliably and can reach your data: a container platform such as Cloud Run or Kubernetes, a serverless platform, or the same cluster as the application it exposes. Because the current MCP specification has no protocol sessions, a stateless server scales horizontally like any web API.

How much does it cost to host an MCP server?

The hosting itself is small: we run client servers on our platform for about $50 to $100 a month. The cost is in building the tools, the permissions and the sign-in. At Reflekt Lab, scoping one workflow costs $2,300 to $4,700, a first workflow in production starts at $17,500, and running it starts at about $470 a month.

Remote MCP Server: Local vs Remote, and How to Host One

A laptop with a small local box on one side, and on the other a cloud server with a padlock and a key reached by a phone, a laptop and a chat panel

A remote MCP server is an MCP server hosted at a public HTTPS URL, so AI assistants like Claude and ChatGPT reach it over the network instead of launching it on someone's laptop. That one difference changes who can use it: a local server serves one person on one machine; a remote server serves a whole team, from desktop, web or phone, with each person signed in as themselves through OAuth. Hosting one means an HTTPS endpoint, a stateless server, real sign-in, permissions enforced on every call, and monitoring, which is a small web service, not a project. It comes in two shapes: embedded in an application you own, or standalone in front of systems you don't. Below: when you need remote, what hosting involves, the two shapes, and what we learned running both.

Local vs remote

	Local MCP server	Remote MCP server
Where it runs	On the user's computer, launched by the assistant	On a server you host
Transport	stdio	Streamable HTTP, over HTTPS
Who can use it	The person whose machine it is	Anyone you authorize, from any device
Sign-in	Credentials in a config file on the laptop	OAuth: each user signs in with their own account
Updates	Each user reinstalls	You deploy once
Works in claude.ai and on mobile	No	Yes
Best for	A developer's own tools, local files	Business systems shared by a team

Many official servers are still local. Intuit's open-source QuickBooks Online server, for example, runs as a subprocess against one company, which is fine for one bookkeeper. We compared it with a server of our own in QuickBooks MCP.

Choose remote as soon as more than one person, or a phone, is involved. Claude's and ChatGPT's custom connectors can only reach a public HTTPS endpoint: neither can reach a server on a laptop or inside a private network.

What hosting one involves

1. An HTTPS endpoint speaking Streamable HTTP

One URL, typically /mcp, that accepts JSON-RPC over HTTP POST. With the official Go SDK it is a few lines, which we walk through in how to build an MCP server.

2. A stateless server

The MCP specification published on 28 July 2026 removed protocol sessions. A server that keeps nothing between requests is already the right shape, and it scales like any web API: put several replicas behind a load balancer and any of them answers any call. Ours run stateless, so a deploy or a crashed replica doesn't drop anyone's connection.

Our first remote server took an API key in a header. That works for whoever built it and for nobody else. In August 2026 we moved our CRM to MCP OAuth: a user adds the server's URL in Claude, signs in with their own account, approves a consent screen, and every call runs as them. A "Connected apps" page lists every assistant someone has authorized and revokes it in one click.

What that requires, in short: answer an unauthenticated call with a 401 that points at your metadata, serve /.well-known/oauth-protected-resource, serve your authorization server's metadata, and run a standard authorization code flow with PKCE. The details, and the five things that break it silently, are in connecting Claude to your software with MCP OAuth.

4. Permissions enforced on every call

Scopes from the tools themselves. A token carries read, write or both. A tool marked read-only needs read; anything else, including a tool someone forgot to mark, needs write.
Tenancy in the server. Every query is limited to the caller's own organization in code. A model can be talked into anything; a database filter can't.
Previews before destructive writes. Updates and deletes accept a dry run that shows what would change.

5. Monitoring and failure handling

Fail at boot, not at the first call. Check the database and every upstream API when the server starts, and refuse to start if one is down.
Errors the model can act on. Return a category and a plain message, not a stack trace. Group production errors by tool, so "which tool got flaky this week" is one view.
Long jobs as runs. Anything that takes minutes starts a run and returns an ID; another tool reports progress. A request that hangs for minutes ends in a timeout somewhere along the way.

Embedded or standalone: two ways to build it

We run remote MCP servers in two shapes, and the choice comes from one question: do you own the application the assistant needs to reach?

Embedded: the MCP endpoint lives inside the application. Our CRM serves /mcp itself, and so does a time-tracking and project-profitability dashboard we built for a client. The tools call the same code and the same database as the screens, sign-in reuses the application's own accounts, and a permission that exists in the app exists for the assistant automatically. When a feature ships, its tool ships in the same release. Choose this when the system is yours, or one you build for a client.

Standalone: a separate MCP server in front of systems you don't own. Our standalone server wraps systems through their APIs or databases: Google Sheets, Linear, spreadsheet files, a 1.3-million-row wine database, and the CRM's own API for agents that run outside it. It holds no business data of its own; it translates tool calls into API calls, with its own sign-in and its own rules about who may call what. Choose this for SaaS products, legacy systems and anything you can't modify, which is also how a QuickBooks bridge works.

	Embedded	Standalone
Lives in	The application itself	Its own service
Reaches the data through	The app's own code and database	The other system's API, files or database
Sign-in	The app's existing accounts	Its own: OAuth for people, keys for agents, mapped to the other system's credentials
Ships with	The app's releases	Its own releases, and breaks when the other API changes
Fits	Systems you own or build	SaaS, legacy and third-party systems

Either way, it needs to run somewhere that serves HTTPS reliably and can reach the data: the application's own hosting for an embedded endpoint, a container platform such as Cloud Run or Kubernetes for a standalone one, and possibly a gateway in front of several servers, which we discuss in MCP gateway. Keep the database off the public internet and the secrets in a secrets manager, as for any other service. Our own setup is on our security page.

What it costs

The hosting is the small part. On our platform it falls in the same band as our other hosted services, about $50 to $100 a month. The work is the tools, the permissions and the sign-in, shaped around one job. Our published prices: scoping one workflow costs $2,300 to $4,700, a first workflow in production starts at $17,500, and running it, with monitoring and updates when the specification or the upstream APIs change, starts at about $470 a month.

Questions to ask before you host one

Who will use it, and from where? One developer on a laptop, or a team on web and mobile?
Does each user sign in as themselves? Or does everyone share one key?
What can a read-only token do? Check that the answer is "nothing that writes".
Is tenancy enforced in code?
Who is alerted when an upstream API changes or a token expires?

Remote MCP Server: Local vs Remote, and What It Takes to Host One

A local MCP server runs on one person's laptop. A remote one is a URL that Claude, ChatGPT and a whole team can connect to, from any device, each person signed in as themselves. Here is when you need one, what hosting it really involves, and what we learned running ours.

Local vs remote

What hosting one involves