What is a remote MCP server, and how do you connect one?
A remote MCP server is reached over HTTPS instead of run as a local process. How sign-in works, and how to add one in Claude Code, Codex and Cursor.
A remote MCP server is an MCP server the client reaches over HTTPS rather than starts as a local process. The client sends JSON-RPC over Streamable HTTP and signs in with OAuth as the MCP authorization specification describes. Nothing runs on your machine: you add a URL, authenticate in the browser, and the server's tools appear in the client.
How does a remote server differ from a local one?
A local MCP server is a program the client launches and talks to over stdio. It runs on your machine, with your environment variables, and it stops with the client. Secrets go in the process environment. Each machine installs its own copy.
A remote server is a URL. The client makes HTTP requests to it, one JSON-RPC call per request. Credentials are a bearer token the client obtained by signing in, or an API key for headless use. The server can serve many people, keep state across sessions, and change without anyone reinstalling anything.
| Local (stdio) server | Remote (Streamable HTTP) server | |
|---|---|---|
| Where it runs | Your machine, launched by the client | A host you reach by URL |
| Transport | stdin and stdout | HTTPS, one JSON-RPC call per request |
| Sign-in | Environment variables, config files | OAuth in the browser, or an API key |
| Who it serves | One person, one machine | Many people, many clients |
| Updating | Reinstall on each machine | Nothing to reinstall |
| State across sessions | Whatever the process keeps on disk | Held by the server |
CoreSpeed's server, https://api.corespeed.io/mcp, is stateless on the wire: one JSON-RPC call per HTTP request, batches rejected, and no GET /mcp stream. State lives behind the server, in the organization, and that is what makes the same URL useful from Claude Code, Codex and Cursor in turn.
How does sign-in work on a remote server?
The MCP authorization specification builds on standard OAuth. A client that reaches https://api.corespeed.io/mcp without a token is pointed at protected-resource metadata (RFC 9728), which names the authorization server, login.corespeed.io. The client registers itself there with dynamic client registration (RFC 7591) or presents a client ID metadata document, then runs OAuth 2.1 with PKCE in the browser. Nothing has to be registered by hand first.
The token that comes back is audience-bound to /mcp (RFC 8707) and works only on POST /mcp. The consent screen names the client that is asking, which is worth checking before you approve it.
Clients that cannot open a browser, such as CI or a headless agent, send an API key instead: Authorization: Bearer sk-cs-... for a member key that acts as you, or an sk-csa- agent key that reaches shared connections only. Read the key from an environment variable rather than writing it into a config file. The authentication docs describe the four credentials.
How do you add a remote server in Claude Code, Codex and Cursor?
Add it at user scope, so it applies to every project, and replace any older corespeed entry: duplicate registrations collide on tool names.
# Claude Code: then start claude, type /mcp, pick corespeed and sign in
claude mcp add corespeed https://api.corespeed.io/mcp --transport http --scope user
# Codex
codex mcp add corespeed --url https://api.corespeed.io/mcp
codex mcp login corespeedIn Cursor, add an entry named corespeed with "url": "https://api.corespeed.io/mcp" to the mcpServers map in ~/.cursor/mcp.json. Cursor shows Needs login beside the server; click it to sign in. Copilot in VS Code, OpenClaw, Hermes, claude.ai, Claude Desktop and ChatGPT follow the same pattern, and any other client with an mcpServers map takes the same entry. The MCP server docs have each client's exact steps.
A first browser sign-in creates your organization on its first tool call. Run tools/list afterward and use what it returns. It is caller-specific: the tools of your connected apps, the built-ins you have enabled, and the manage__* account tools.
How do you register your own server for your organization?
CoreSpeed also fronts remote servers you already have. An org admin registers any HTTPS MCP server as a remote connector, from the dashboard, with manage__remote_add, or with POST /connectors/org. Its tools then appear to every member as org__<slug>__<tool>, with the same sign-in, spend holds and activity trail as every other tool. manage__remote_list runs for anyone; add, refresh and remove need an org admin.
Three auth modes exist. With oauth, each member authorizes the server themselves; CoreSpeed discovers the authorization server through RFC 9728 and registers a client by RFC 7591 when a registration_endpoint exists. The redirect URI is always https://app.corespeed.io/connectors/callback, so pre-registering a client with that URI also works. With static_bearer, one org-wide token is stored encrypted at rest. With none, the server takes no credential. A failed registration leaves the slug free; an unknown outcome holds it as dcr_pending until an admin clears it. The remote MCP docs have the request shape.
FAQ
Do I need to register an OAuth client before connecting?
No. CoreSpeed's authorization server supports dynamic client registration and client ID metadata documents, so the URL alone is enough.
Can I use one remote server from several clients?
Yes. Each client signs in with the same URL. Connections, memory and policy live in the organization, so each client sees the same tools for the same caller.
Where should the sign-in happen?
At login.corespeed.io, with a consent screen that names the client asking. A one-click install from a marketplace should point at exactly https://api.corespeed.io/mcp.
What does a batch request return?
A rejection. The transport takes one JSON-RPC call per HTTP request and offers no GET /mcp stream.