Connecting Claude, Cursor and Codex to a remote MCP server

Two kinds of MCP server, and why it matters

Nearly every MCP integration you have installed is a local server: a package your client launches as a child process, talking JSON-RPC over stdin and stdout. It holds your API key, translates tool calls into HTTP requests against some vendor's API, and dies when your editor closes.

A remote server skips the middle layer. The vendor's service speaks MCP itself, over HTTPS, and your client is just an HTTP client. Nothing is installed, nothing runs locally, and there is no npm package sitting between your credentials and the API.

The practical differences show up fast. A local server needs a runtime you have to keep current, and a key pasted into a config file in plaintext. A remote server needs a URL, and authenticates through OAuth so the token lives in your client's credential store and can be revoked from the vendor's dashboard. When a local server breaks you debug a subprocess; when a remote one breaks you read an HTTP status code.

Streamable HTTP in one paragraph

Streamable HTTP replaced the older HTTP+SSE transport. Your client POSTs a single JSON-RPC message to one endpoint URL and reads the response. The server may answer with plain JSON, or upgrade to an SSE stream if it needs to send several messages for one request. A server is free to implement only the JSON half, and many do, because most tool calls are a simple request and response.

That freedom is the source of the most common setup failure. A client configured for the old SSE transport opens a long-lived GET against the endpoint expecting an event stream. A JSON-only server has nothing to serve on GET and answers 405 Method Not Allowed. The client reports that the server is unreachable, which is misleading: the server is fine, the verb is wrong.

What the handshake actually exchanges

Before debugging any client, it helps to have seen the raw conversation. It is three messages, and you can drive all of them with curl.

# 1. initialize — agree on a protocol version
curl -s -X POST https://c1k.me/mcp/org_EXAMPLE \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
    "jsonrpc":"2.0","id":1,"method":"initialize",
    "params":{
      "protocolVersion":"2025-11-25",
      "capabilities":{},
      "clientInfo":{"name":"curl","version":"1.0.0"}
    }
  }'

# 2. notifications/initialized — a notification, so 202 and no body
curl -s -i -X POST https://c1k.me/mcp/org_EXAMPLE \
  -H "Authorization: Bearer $TOKEN" \
  -H "MCP-Protocol-Version: 2025-11-25" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"notifications/initialized"}'

# 3. tools/list — what this token is actually allowed to see
curl -s -X POST https://c1k.me/mcp/org_EXAMPLE \
  -H "Authorization: Bearer $TOKEN" \
  -H "MCP-Protocol-Version: 2025-11-25" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'

Two details trip people up. First, after initialization every request must carry MCP-Protocol-Version; omitting it is a protocol error, not a warning, and servers are entitled to answer 400. Second, a notification has no id and therefore no response — a 202 with an empty body is success, not a failure.

If those three calls work with curl and your client still cannot connect, the problem is in the client configuration and not in the server. That single fact saves a lot of time.

The OAuth part, without the spec language

When you connect without a token, a well-behaved remote server answers 401 with a WWW-Authenticate header pointing at its protected-resource metadata. Your client fetches that, discovers the authorization and token endpoints, opens a browser, and you approve a consent screen naming the scopes. The client exchanges the resulting code for an access token using PKCE, so the code is useless to anyone who intercepts it.

Three things about that flow cause real-world failures.

Why your tool list is shorter than the docs

A well-built remote server filters tools/list by the scopes your token actually holds. If you granted read access, the write and delete tools are not merely rejected when called — they are never advertised. The model cannot attempt them, cannot hallucinate arguments for them, and cannot tell you it “tried but was blocked”.

This is the correct behaviour and it looks like a bug the first time. Before filing one, call the server's capability tool — on c1k.me that is get_capabilities — and compare the effective scope set with what you expected to grant.

While you are there, resist granting more than you need. An assistant that reports on links needs read scopes and nothing else. Destructive scopes for a model should be the exception you can justify out loud, not the default you clicked through.

A debugging table

Two habits worth forming

The first is scope discipline. Grant the narrowest set that completes the task, and create a separate connection when an agent genuinely needs more. Revoking one narrow connection is easy; auditing one over-scoped connection after the fact is not.

The second is remembering that tool output is untrusted input. Titles, descriptions and URLs coming back from a remote server originate with people, and sometimes with strangers. A model reading them should treat them as data rather than as instructions. Servers can help — by never embedding credentials in returned URLs, and by shaping output so it does not read as a command — but the boundary is worth holding on your side too.