If you use more than one AI client — Claude Desktop, Claude Code, Cursor, VS Code, ChatGPT — and you want the same MCP server in all of them, the default answer is yes: each client keeps its own config, its own connection, and usually its own OAuth grant to that server. Nothing under the hood shares a connection between clients unless you deliberately point them at the same place. Here’s what that actually costs you, and the one way to avoid it.
Why each client connects separately by default
An MCP client — Claude, Cursor, VS Code’s agent mode, whatever you use — reads its own local config file (or its own remote-connector setting) and opens its own connection to a server’s URL. There’s no shared registry across clients on your machine. Add a remote server to Claude Desktop and it knows nothing about the identical server you already added to Cursor five minutes earlier. From the server’s point of view, they’re two unrelated clients showing up cold.
For a server that needs OAuth, “unrelated clients” means two separate authorization flows. You click through the same vendor’s consent screen twice, approve the same scopes twice, and end up with two separate access tokens the server has to track. Some vendors handle this cleanly. Others — see why some MCP servers reject a client outright — only admit clients they’ve pre-approved, which means adding a second client can mean a second wait for allow-listing, not just a second click.
What duplicate connections actually cost you
- Config drift. You add a server to Claude, forget to add it to Cursor, and six weeks later you’re debugging why a tool works in one app and not the other. The answer is usually “you never configured it there,” but that’s not obvious from inside either client.
- Duplicate grants to revoke. If you ever need to cut a server’s access — a credential looks compromised, someone leaves the team — you have to find and revoke every client’s separate grant, not one. See how to revoke an MCP OAuth grant for how easy it is to miss one of them.
- No shared record of what happened. Each client, at best, keeps its own local log of what it called and when. There’s no single place to answer “did any AI tool touch this customer record last week,” because the answer is split across however many clients you’ve wired up.
- Rules that don’t travel. If a server exposes both a read tool and a delete tool, and you only want the delete tool available from one trusted client, there’s no built-in way to say that. MCP’s OAuth scopes are usually all-or-nothing per server — see what an OAuth scope actually covers — so “allowed in this client, blocked in that one” isn’t something the server itself can enforce.
None of this shows up with one server and one client. It shows up the moment you’re running two or three servers across two or three clients, which for anyone using MCP seriously happens faster than expected.
The alternative: one connection, many clients
A gateway sits between your AI clients and your MCP servers as a single URL. You connect each server to the gateway once, then point every client at that one gateway URL instead of at each server directly. The OAuth grant, the tool list, and the allow/ask/block rules live in the gateway — not duplicated per client. Add a new client and it inherits everything you’ve already set up, instead of starting from zero. See how gate’s gateway works for the one-URL setup, or the current server list at /mcp-servers.
This also fixes the audit-log gap: every call from every client goes through the same gateway, so there’s one log to check instead of several, regardless of which client made the call.
When separate connections are actually fine
If it’s just you, using one client, connecting to one or two servers, a gateway is more setup than the problem calls for — wire the server in directly and move on. The tradeoff flips once a second person, a second client, or a server with real write access enters the picture, which is roughly the same threshold covered in what to look for in an MCP gateway.
Before you connect the same server twice
Whether you go direct or through a gateway, run the server itself through a quick check first — a server you’re about to wire into three clients at once is worth a second look before the first one, not after. gate’s free MCP security scanner checks a server’s tool descriptions for prompt injection and hidden instructions before you rely on it, no signup required.
The bottom line
MCP doesn’t share connections across clients on its own — every client you add is a separate config, a separate grant, and (for OAuth servers) a separate consent screen. That’s fine for one client and one server. Past that, it’s worth deciding once whether you want to keep managing N separate connections or collapse them into one.