- The Short Answer
- What "Remote" Actually Means
- Remote vs Local MCP Servers
- A Side-by-Side Comparison
- Why Remote Is Becoming the Default
- When a Local Server Still Makes Sense
- What to Look For in a Remote Server
- FAQs
- Related Reading
The Short Answer
A remote MCP server is a Model Context Protocol server that lives at a URL and is reached over the internet, rather than running as a process on your own machine. You point an MCP client — Claude, Cursor, Codex, ChatGPT — at the URL, authenticate once, and the server's tools are available. There's nothing to install and nothing to keep running locally.
That's the whole idea, but the consequences are bigger than they sound. Where a server runs changes how you install it, how it authenticates, how it's maintained, and whether it follows you when you switch machines or editors.
What "Remote" Actually Means
MCP defines how a client and a server talk. A local server communicates over STDIO — the client launches the server as a subprocess on your computer and exchanges messages through standard input/output. A remote server communicates over Streamable HTTP — the client sends JSON-RPC messages to a URL, and authentication is handled at the transport layer, typically with OAuth.
So "remote" isn't just "hosted somewhere else." It's a different transport, a different auth model, and a different maintenance story. You connect to a remote server the way you connect to any web service: with a URL and a sign-in, not an install.
Remote vs Local MCP Servers
The practical differences come down to four things.
Installation. A local server has to be installed and run on your machine — often via a package manager, sometimes with runtime dependencies. A remote server needs only its URL; the client handles the connection.
Authentication. Local servers usually read credentials from environment variables or local config, which means secrets sit on your disk. Remote servers typically use OAuth, so you sign in through the browser and the server holds credentials on its side.
Maintenance. A local server is a version you own — you update it, you patch it. A remote server is maintained by whoever runs it; you always hit the current version.
Portability. A local server exists on one machine. A remote server is reachable from any machine and any MCP client, so the same tools and workspace follow you when you switch from your laptop to your desktop, or from Cursor to Claude.
A Side-by-Side Comparison
| Dimension | Local (STDIO) server | Remote (HTTP) server |
|---|---|---|
| Where it runs | A process on your machine | At a URL, over the internet |
| Transport | STDIO | Streamable HTTP |
| Install | Package + dependencies | Nothing — just the URL |
| Auth | Env vars / local config | OAuth in the browser |
| Updates | You maintain the version | Maintained for you |
| Works across machines | No | Yes |
| Works across clients | Per-machine setup | Same URL everywhere |
| Best for | Local files, offline tools | Hosted services, infrastructure |
Why Remote Is Becoming the Default
For anything that isn't strictly about your local filesystem, remote wins on friction. There's no install step to document, no dependency to break, no version drift between team members. Authentication is a browser sign-in instead of a secrets file. And because the server is addressable from anywhere, your setup is identical on every machine and in every client you use.
This is the model the Matagi MCP server is built on: one remote endpoint — https://mcp.matagi.ai/mcp — served over Streamable HTTP, with OAuth 2.1 authentication and no API keys. Connect it once from any client and the same workspace, agents, and resources are there. Because it's remote and hosted, it can also do things a local process can't practically offer: provision databases, deploy functions, and proxy 3,000+ tools with credentials kept server-side.
When a Local Server Still Makes Sense
Remote isn't always right. A local server is the better choice when the tool's whole job is your machine — reading and writing local files, driving a local application, or operating fully offline. In those cases the data never needs to leave your computer, and a local process is simpler and keeps everything on-device. The rule of thumb: if the capability is inherently local, run it locally; if it's a hosted service or shared infrastructure, go remote.
What to Look For in a Remote Server
Since a remote server holds credentials and runs code on your behalf, a few things matter more than for a local one. Look for standard OAuth (2.1 with PKCE) rather than pasted API keys, so secrets aren't sitting in config. Look for credentials that are proxied server-side and kept out of the model's context and any generated code. And look for an audit trail, so you can see what was done on your behalf. Matagi does all three — the point of a good remote server is that convenience doesn't cost you control. As always with agent tools: verify, don't trust.
FAQs
What is a remote MCP server in one sentence? An MCP server you connect to by URL over HTTP, with nothing installed locally and OAuth for authentication.
How is it different from a local MCP server? A local server runs as a process on your machine over STDIO and reads local credentials; a remote server lives at a URL, authenticates via OAuth, and works across machines and clients.
Do remote MCP servers need an API key? Usually no — they use OAuth. With dynamic client registration, as Matagi uses, there's nothing to paste at all.
Are remote MCP servers secure? They can be more secure than local ones when built right: OAuth instead of on-disk secrets, credentials proxied server-side, and an audit log of every action.
Which clients support remote MCP servers? Claude (Desktop and Code), Cursor, Codex, ChatGPT, VS Code, and other MCP clients all support remote servers by URL.
Related Reading
- MCP vs API: What's the Difference?
- MCP OAuth: How MCP Authentication Works Without API Keys
- Postgres MCP Server: Give Your AI a Database Without the Setup
- How to Add an MCP Server to Claude Desktop
- How to Add an MCP Server to Cursor
Want a remote MCP server that provisions infrastructure and runs agents, not just reads data? Connect Matagi — one URL, OAuth sign-in, and the same workspace across every client.
Build your first AI agent free
Describe what you want done in plain English. Matagi provisions the infrastructure, wires the integrations, and deploys it.
Get started