Custom SSE MCP Server (Remote HTTP Endpoint)

Stdio vs SSE: When You Need HTTP

Stdio is great when the server lives on your machine. For a server that runs in Docker, on a remote host, or as an internal microservice, MCP also supports HTTP with Server-Sent Events (SSE) for the response stream.

Cursor (native SSE support)

Cursor reads a url field directly:

{
  "mcpServers": {
    "remote-tools": {
      "url": "https://mcp.internal.example.com/sse",
      "headers": {
        "Authorization": "Bearer your-token-here"
      }
    }
  }
}

Claude Desktop (via mcp-remote bridge)

Claude Desktop currently expects stdio servers, so wrap a remote endpoint with the official mcp-remote bridge:

{
  "mcpServers": {
    "remote-tools": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.internal.example.com/sse",
        "--header",
        "Authorization: Bearer your-token-here"
      ]
    }
  }
}

The bridge runs locally as a stdio server and proxies JSON-RPC frames to the remote SSE endpoint.

Why SSE for the response

MCP responses can be large (tool results, resource listings). SSE streams them as the server produces them, so the model sees the first bytes immediately rather than waiting for the entire response. The request side is plain HTTP POST with a JSON body.

When NOT to use SSE

• Single-user, single-machine setups — stdio is simpler and faster.
• When the server depends on local files or Unix sockets that aren't reachable over HTTP.
• When latency matters more than centralization — every SSE round-trip is at least one TCP round-trip.

Auth patterns

Bearer tokens in headers are the simplest. For multi-tenant setups, use OAuth and refresh tokens — our OAuth2 flow visualizer walks through the standard exchange.