Skip to main content
Connie’s MCP server is the same URL for every client — only the ?client= query parameter changes. Pick your IDE below.
The query alias (?client=cursor, ?client=claude-code, etc.) is there so mcp-remote keeps a separate OAuth cache per IDE on the same machine. Without it, connecting Cursor and Claude Code on the same laptop would share one row in Connected Apps; with it they each get their own with independent revoke. It’s a cache-buster only — the server treats every alias as the same endpoint.
Every mcp-remote snippet below includes --static-oauth-client-metadata '{"client_name":"<IDE>"}'. This is the bit that makes the OAuth consent screen show “Cursor wants to connect” (or your IDE’s actual name) instead of the generic MCP CLI Proxy placeholder that mcp-remote registers with by default. Don’t strip the flag — the placeholder name confuses users at the consent step.

​
Pick your IDE

Cursor speaks stdio MCP only — it needs the mcp-remote bridge.Config file
  • Windows: C:\Users\<you>\.cursor\mcp.json
  • macOS / Linux: ~/.cursor/mcp.json
Restart fully. A window reload is not enough — Cursor only re-spawns the MCP subprocess on a full app restart.On the first tool call, your browser opens to the Connie consent screen — it will say “Cursor wants to connect to your Connie workspace”. After you click Allow, Cursor’s AI can call every tool listed on the Overview.

​
Why port 0?

mcp-remote runs a tiny local HTTP server to receive the OAuth callback. The positional 0 tells your OS to pick any free ephemeral port, so you can’t hit EADDRINUSE collisions with another local process — including stale runs of mcp-remote itself. The chosen port is included in the OAuth redirect, so the callback resolves correctly. If you’re seeing port-related errors anyway, jump to Troubleshooting.

​
Advanced

Building a custom MCP host or internal bot? Use the same pattern as the IDE snippets above — just set client_name to whatever you want shown on consent screens and in the Connected Apps row:
Casing and punctuation are normalized server-side — "cursor", "Cursor", and "CURSOR" all land as Cursor. Unknown names (anything outside Connie’s canonical list of Cursor / Claude Code / Claude Desktop / Windsurf) pass through verbatim, so a custom name shows up in Connected Apps exactly as you wrote it.
mcp-remote registers as a generic placeholder (MCP CLI Proxy in current builds, MCP CLI Client in older ones) when no --static-oauth-client-metadata is passed. That string is what the OAuth consent screen renders to your user — they see “MCP CLI Proxy wants to connect to your Connie workspace” with no indication it’s actually Cursor. That’s a real UX issue: users hesitate or refuse the grant.Connie has a fallback that lazily upgrades the Connected Apps row to the right IDE name once the first MCP tool call arrives (it reads clientInfo.name from the MCP initialize handshake), but the consent screen has already been rendered by that point. The lazy upgrade only fixes Connected Apps after the fact — it doesn’t help the consent screen.Bottom line: keep the --static-oauth-client-metadata flag in every snippet. The fallback is a safety net for misconfigured clients, not a substitute for correct attribution.
Useful for end-to-end OAuth debugging without an IDE in the loop. Verbose output goes to stderr.
Add --debug for the full handshake log:
To force a fresh OAuth flow (clear the local token cache):

​
What’s next

Multi-workspace

One OAuth grant covers every workspace you’re in — here’s how to address a specific one per request.

Troubleshooting

OAuth failures, missing tools, and the MCP CLI Proxy placeholder explained.