One deployed MCP connector serves every major assistant. Claude, Claude Code, ChatGPT, OpenAI Codex, and any other MCP client that supports remote servers all take the same input: your connector's HTTPS URL. You deploy once, and each client brings its own setup screen to the same endpoint. This post is the recap of the whole series, one URL, four clients, zero client-specific code.
What does each client need?
The same URL, pasted in a different menu. Over the past weeks we walked each one:
- Claude (web and desktop): add the URL as a custom connector. Claude discovers the OAuth flow and walks the user through consent.
- Claude Code: one command, claude mcp add with the HTTP transport, scoped to a project or your whole user.
- ChatGPT: add the URL under connectors in developer mode.
- OpenAI Codex: point its remote MCP config at the same URL.
Client UIs move around, menu names change, but the contract underneath does not: paste https://<slug>.denkops.host/mcp, complete OAuth, call tools.
Why do all four clients accept the same server?
Because the hard parts are standardized, and the platform answers them once:
- Transport. The connector speaks stateless streamable HTTP at
/mcp. Every client that supports remote MCP servers speaks exactly this. - Auth. With connector: true, OAuth discovery, dynamic client registration, and the consent screen are hosted for you. Each client registers itself during setup, so there is no per-client OAuth app to create, no client secret to distribute, and each user gets an individual, revocable grant.
- Access. One policy covers every client, public or an allowed-email list. You do not maintain separate user lists per assistant, because identity is established at login, not by which client happened to connect.
Your server code contains none of this. It defines tools; the clients differ only in which UI asked for the URL.
What would N separate integrations have cost?
The pre-MCP alternative is building against each vendor: one plugin format here, one custom GPT action schema there, an extension API somewhere else. Each with its own auth registration, review process, update cycle, and breakage calendar. Four clients means four codebases that all lag your product by a different amount.
A remote connector inverts that. The integration surface is one MCP server you own, and client support is the vendors' job, they implement MCP once and every connector works. When a new MCP-capable client ships, your connector already supports it, on the day it launches, with no release on your side. That asymmetry is the whole argument: N integrations you maintain, versus one server plus N setup pages you merely document.
Where do I go from here?
If you have not deployed yet, the deploy an MCP server page takes you from a file of tool definitions to a live URL in one command. If your connector is live, two upgrades are worth the afternoon: put it on a custom domain so the URL carries your brand, and review the access policy before sharing it wider. Then share one line with your team or your customers: the URL, and nothing else. Whatever assistant they use, it is the same connector on the other end.