Connecting a remote MCP server to Claude, ChatGPT or Cursor comes down to one address and one sign-in: you give the client the server's URL, the client walks the authorisation flow in a browser, and the server's tools appear in that client's tool list. The URL is the same in all three. What differs is where each client keeps that setting, whether it can complete a browser sign-in on your behalf, and what it shows you when the connection half works.
A remote MCP server needs exactly two things from the client: an HTTP address to talk to, and permission to act as you. Everything else is the client's own packaging. For Market4 the address is https://mcp.market4.app/mcp, and the sign-in is your Market4 e-mail and password on the page the client opens; there is no key to paste, because the connection authorises itself and every tool call then runs as your account.
The first fork is older than any of the three clients: MCP servers come in two shapes, and a client that only supports one cannot connect to the other. A local server is a command the client runs on your machine and talks to over standard input and output. A remote server is an HTTP endpoint. If a client's configuration only offers a command and arguments, it is asking for a local server, and pasting an HTTPS URL into the command field will not work — that setup needs a bridge process that runs locally and forwards to the remote endpoint.
The differences between MCP clients are not about the protocol, which is the same wire format everywhere. They are about the surface: where the server list lives, how the client handles the browser round trip that authorisation needs, and how it behaves when a server offers more tools than the client wants to show a model at once.
| What differs | Why it matters | What to check before blaming the server |
|---|---|---|
| Where the server list lives | One client keeps it in a settings panel, another in a JSON file, another behind a command | That you edited the configuration the running client actually reads |
| Remote or local transport | A client with no HTTP transport cannot use a URL at all | Whether the field wants a URL or a command to run |
| Completing the sign-in | Authorisation opens a browser page and hands a token back to the client | That the browser finished and returned, and that you signed in to the right account |
| Tool visibility | Some clients let you disable individual tools or cap how many are exposed | Whether the tool you expected is switched off rather than missing |
| Where errors surface | A failed connection can be a red dot, a log line, or silence | The client's own MCP log before anything else |
The server is the same in both. What differs is which layers the client implements: how it connects, how it discovers the authorisation server, which of the three capabilities it lists, and whether it reads the hints on each tool.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
A remote MCP server that carries your marketing data authorises with OAuth rather than a pasted key, and the reason is where a secret ends up. A key typed into a chat window lives in that conversation, in the transcript, and in every log and context window the conversation passes through. An OAuth flow keeps the credential between your browser and the server, hands the client a token it can refresh, and lets you revoke that token later without changing anything else you own.
The consequence for connecting is that the client has to be able to open a browser and receive the result. On a laptop this is invisible. On a remote machine, in a container, or over SSH, it is the step that fails: the browser opens somewhere you cannot see, or the redirect comes back to a port that is not reachable. When a connection hangs at authorisation rather than failing, that is almost always what happened.
A connected MCP server is one whose tools are listed and one of whose read-only tools has actually answered. Those are two separate proofs and clients routinely give you the first without the second. Ask the assistant to list what the server offers, then ask it to call a read that spends nothing — for Market4 that is listing your apps — and read the answer rather than the assistant's summary of it.
Two failures look identical from the client and are not. A server that answers 401 with invalid_token has been reached and has refused the credential, which is a sign-in problem. A server that never answers at all is a network or address problem. The status code is the difference, and it is in the client's MCP log rather than in the chat.
No. A remote MCP server has one HTTP endpoint and every client that supports remote servers uses the same address. If someone gives you a different URL per client, that is a bridge or a proxy in front of the server rather than the server itself. What changes between clients is where you put the address and how the client stores the token it gets back after you sign in.
Because it is configured for local MCP servers, which the client launches as a process and talks to over standard input and output. Remote servers are HTTP endpoints and need a client that supports that transport. If your client only takes a command, you need a small local bridge that runs as the command and forwards to the remote URL, or a newer version of the client that accepts URLs directly.
The redirect back to the client did not arrive. That happens when the client is running somewhere the browser cannot reach it, typically over SSH, inside a container, or on a machine where the callback port is blocked. Try connecting from a client running on the same machine as the browser first, so you can tell an authorisation problem from a reachability one, and check the client's MCP log for the callback address it was waiting on.
Usually not. Clients ask the server for its tool list when they connect and many refresh it during a session, so a new tool appears without any change at your end. If a tool you know exists is not listed, restart the client to force a fresh list, then check whether the client has that tool switched off. A stale list is far more common than a missing tool.
Dynamic client registration is the one part of MCP's authorization story marked SHOULD rather than MUST. What the specification actually requires, the two alternatives it names for servers that skip registration, and what implementing it costs.
When an assistant works through dozens of your tools in a single turn, there is no transaction around them. Everything before the failure has already happened, and the turn can still end by reporting success.
