Connect Cursor to a remote MCP server

Cursor reaches your tunnel over Streamable HTTP at its public URL.

The config entry

{
  "mcpServers": {
    "notes-via-tunnel": {
      "url": "https://notes--acme.mcppipe.dev/mcp"
    }
  }
}

Cursor’s documentation has used both url and endpoint for the same field across revisions. mcppipe’s auto-detect accepts either, so a config written against older Cursor docs still works.

Where the config file lives

Scope	Path
User	~/.cursor/mcp.json (Windows: %USERPROFILE%\.cursor\mcp.json)
Project	<project>/.cursor/mcp.json

Auto-detect and the project-level file

mcppipe up with no arguments scans the user-level file by default. The project-level .cursor/mcp.json in your working directory is not scanned unless you ask:

mcppipe up --scan-workspace

That is deliberate. Walking the current directory by default would mean running mcppipe up inside a cloned repository could pick up a server definition that came with the repo rather than one you chose — so the workspace scan is opt-in.

To see what would be found either way:

mcppipe detect --scan-workspace --json

Cursor and IP allowlists

Cursor is deliberately not offered as a one-click IP preset, and is left out of the Multi-LLM union.

The reason is that Cursor’s only MCP-relevant egress is its Cloud Agent range, which Cursor’s own documentation describes as not stable — served per-cluster through a JSON API and subject to change. Shipping that as a preset would be promising a pinned range we cannot keep pinned.

If you want to restrict a tunnel to Cursor’s cloud agents, paste the current values from Cursor’s egress JSON API into the Custom CIDR field, and re-check when they rotate.

Note that Cursor running on your machine — the normal case — reaches your tunnel from your own IP, so the allowlist entry is simply yours. See IP allowlist & access control.

See also

• Client compatibility — the full matrix
• CLI reference — --scan-workspace, --config
• Quickstart