What is a remote MCP server?

A remote MCP server is an MCP server that runs as a service at a URL rather than as a process on the user's machine. The client connects over HTTP, authenticates with OAuth, and calls tools the same way it would call a local one. There is nothing to install, no process to keep running, and one deployment serves every user and every client.

A local MCP server is the other kind: a program the client launches itself, speaking JSON-RPC over its standard input and output. Most early MCP servers were local. Most servers that hold someone's data are becoming remote.

Local versus remote

	Local MCP server	Remote MCP server
Where it runs	On the user's machine, launched by the client	On your infrastructure, at a URL
Transport	stdio	Streamable HTTP
Install	Every user, every update	None, paste a URL
Authentication	Usually an API key in an environment variable	OAuth in the browser
Works from ChatGPT	No, it cannot launch a process	Yes, as a custom connector
Data stays on the user's machine	Yes	No, the server holds it
Who can update it	The user, by re-installing	You, by deploying

The last two rows are the real decision. A local server is right when the tool works on files or processes that live on the user's machine, or when the data must not leave it. A remote server is right when the data already lives on your side and the point is to give an agent an authenticated door to it.

What is a local MCP server

A local server is a command. The client's configuration names the command and its arguments; the client runs it and talks to it over stdio. Credentials, if any, are passed as environment variables in that same configuration. It works well for tools that need the local filesystem, a local database or a local browser.

Its costs are distribution and secrets. Every user installs and updates it, and an API key sitting in a config file is a key sitting in a config file.

How to add a local MCP server to Claude Desktop

Claude Desktop reads a JSON configuration file listing local servers by command. Add an entry with the command and arguments that start your server, restart the app, and the tools appear. The exact file location differs by operating system and is in Anthropic's documentation for the app.

Note what this does not give you: the same server in Cursor needs its own entry, in Claude Code its own, and ChatGPT cannot use it at all. That is the moment most teams decide to go remote.

How to migrate from local to remote MCP server

Migration is mostly not about the tools. The tool handlers stay. What changes is around them:

1. Swap the transport. Replace the stdio loop with an HTTP endpoint that accepts a JSON-RPC message on POST and returns one. You do not need a server-initiated event stream; answer a GET asking for one with 405 if you have none.
2. Replace the environment-variable key with OAuth. The client cannot reach your environment any more, so authentication moves to the browser: discovery metadata, dynamic client registration, authorization code with PKCE. The steps are in how to add OAuth to an MCP server.
3. Scope per user. A local server served one user by construction. A remote one serves everyone, so every tool call must be resolved to a workspace from the token.
4. Add rate limits and say so. Return RateLimit-* headers so an agent sees a limit coming.
5. Publish a server card at /.well-known/mcp/server-card.json so clients and registries can describe the server without reading your docs.
6. Rewrite the connect instructions. "Add this URL" replaces "install this and set this variable."

The user-side migration is one line. In Claude Code, for Annsa:

claude mcp add --transport http annsa https://app.annsa.ai/mcp

In Cursor, Settings → MCP → Add server, and paste the URL. The first run opens a browser on the consent screen.

What Annsa is

Annsa is a remote MCP server at https://app.annsa.ai/mcp: Streamable HTTP, JSON-only, OAuth 2.1 with PKCE, 6 tools, no package to install and no token file to manage. It connects from Claude Code, Cursor, Codex, ChatGPT, Windsurf, Figma Make, Lovable and Bolt with the same URL. Per-client setup is in using Annsa with coding tools, and the developers page holds the machine-readable surfaces.

When to stay local

If your server reads the user's filesystem, runs their tests or drives their browser, stay local. That is what stdio is for. Go remote when the data is yours and the job is letting an agent in.