Remote vs local MCP servers, and where a business should host one

The two transports

The difference matters most for who can use the server. A local server only exists on the computer it is installed on, so each person who wants it needs their own copy and their own credentials. A remote server is set up once and shared, which is why Claude's organization settings and ChatGPT's workspace publishing both work with remote servers.

The MCP specification defines two standard ways for an assistant to talk to a server. With stdio, the client launches the server as a program on the same machine and exchanges messages through standard input and output. With Streamable HTTP, the server is a web service the client reaches over the network.

In practice, stdio means a local server: it lives on one person's computer, uses that computer's network, and takes credentials from its environment. Streamable HTTP means a remote server: one deployment that many people and many clients can use, with OAuth sign-in.

Where each one works

Anthropic's documentation says Claude connects to remote custom connectors from Anthropic's cloud, across claude.ai, Claude Desktop, Cowork, and the mobile apps. Local servers configured in Claude Desktop through claude_desktop_config.json are a separate mechanism that uses your local network, and Anthropic says they are not available in Cowork or claude.ai. It also notes that advanced Research cannot invoke tools from local MCP servers.

On the ChatGPT side, OpenAI's testing guide asks for a public HTTPS endpoint, typically at /mcp, or a Secure MCP Tunnel. OpenAI also documents desktop-only plugins that run a local MCP server, as a separate submission path.

When local makes sense

A local server is not automatically safer. It runs with the permissions of the person's computer and whatever credentials sit in its environment, which the MCP authorization specification says is how stdio servers should get credentials. Every laptop that runs it holds those credentials, and there is no central log of what was called. For one developer that is acceptable. For a team it is harder to control than one remote server.

• A developer connecting tools on their own machine, such as a code editor or a local database.
• A personal workflow where only one person needs access.
• Prototyping a tool design before building the remote version.

Why businesses usually need remote

• It works in the browser, desktop, and mobile versions of Claude, not only on one computer.
• An admin adds it once for the organization, and each member signs in with their own account.
• Access is controlled centrally. Removing a person or a tool happens in one place.
• Logging and rate limits live on the server, so you can see every call.
• Updates ship once instead of on every laptop.

Hosting options for a remote server

Public HTTPS endpoint: the simplest path. The server runs on a cloud platform with a valid certificate and requires OAuth on every request. It works with both Claude and ChatGPT and is required for public directory listings.

Private network with an allowlist: if the server must sit inside your network, Anthropic says you need to allowlist Anthropic's published IP addresses so inbound connections from Claude can reach it. Servers behind a VPN or a blocking firewall will not connect.

Secure MCP Tunnel for ChatGPT: OpenAI describes an outbound-only tunnel, where a client inside your network polls OpenAI for work and forwards it to your private server, so you do not open inbound firewall ports. OpenAI notes it does not support public plugin submission.

Vendor-hosted or your own cloud: a builder can host the server for you, or deploy it into your own cloud account so data and logs stay inside your boundary. Security teams often prefer the second for sensitive systems.

Questions for your security team

Hosting a remote MCP server is a normal web service decision, and your security team will likely ask the same questions they ask of any internet-facing API. Having answers ready shortens the review.

• Where will the server run, and in whose cloud account?
• Which source systems will it reach, and through which credentials?
• Will inbound traffic come from the public internet, from Anthropic's published IP ranges, or through an outbound tunnel?
• How are user tokens validated, and where are permission checks enforced?
• What is logged, how long is it kept, and does it exclude tokens and secrets?
• Who is alerted when it fails, and how are updates deployed and tested?
• Can we move the server to another host later without rebuilding it?

Choosing for your business

A practical rule: build locally to try out tool designs, then move to remote before anyone outside the build team depends on it. The tools and their descriptions carry over; what changes is the transport, sign-in, and hosting around them.

If more than one person will use the server, or anyone will use it from the web or a phone, build it remote. Then choose hosting based on where the data lives and what your security team requires. Prestyj's custom MCP servers are built remote by default, hosted by us or deployed into your cloud, with local stdio builds reserved for developer tooling.