> ## Documentation Index
> Fetch the complete documentation index at: https://docs.connie.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Client setup
> Copy-paste configurations for Cursor, Claude Code, Claude Desktop, and Windsurf. One URL, one minute per IDE.
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":""}'`. 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\\.cursor\mcp.json`
* **macOS / Linux:** `~/.cursor/mcp.json`
```json theme={null}
{
"mcpServers": {
"connie": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://mcp.connie.ai/api/mcp?client=cursor",
"0",
"--static-oauth-client-metadata",
"{\"client_name\":\"Cursor\"}"
]
}
}
}
```
**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](/mcp/overview).
Two equivalent setups. Pick whichever fits your workflow.
**Option A — CLI (recommended):**
```bash theme={null}
claude mcp add connie -- npx -y mcp-remote https://mcp.connie.ai/api/mcp?client=claude-code 0 --static-oauth-client-metadata '{"client_name":"Claude Code"}'
```
**Option B — settings file** (`~/.claude/settings.json`, or per-project `.claude/settings.json`):
```json theme={null}
{
"mcpServers": {
"connie": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://mcp.connie.ai/api/mcp?client=claude-code",
"0",
"--static-oauth-client-metadata",
"{\"client_name\":\"Claude Code\"}"
]
}
}
}
```
Restart Claude Code (or run `/mcp` and pick **Reload servers**). The first call triggers OAuth in your browser and the consent screen will say **"Claude Code wants to connect to your Connie workspace"**.
Recent Claude Desktop versions speak HTTP + OAuth natively — **no `mcp-remote` bridge needed, and no metadata flag needed**. This is the simplest setup of the four; Claude Desktop's native HTTP client sends its own `client_name` during DCR, so the consent screen attributes correctly out of the box.
**Config file**
* **Windows:** `%APPDATA%\Claude\claude_desktop_config.json`
* **macOS:** `~/Library/Application Support/Claude/claude_desktop_config.json`
```json theme={null}
{
"mcpServers": {
"connie": {
"url": "https://mcp.connie.ai/api/mcp"
}
}
}
```
Fully quit and reopen Claude Desktop. The first tool call opens the Connie consent screen — it will say **"Claude Desktop wants to connect to your Connie workspace"**.
**Older Claude Desktop versions** without native HTTP-MCP support need the bridge — use the Cursor pattern, swapping `?client=cursor` for `?client=claude-desktop` and `"client_name":"Cursor"` for `"client_name":"Claude Desktop"`:
```json theme={null}
{
"mcpServers": {
"connie": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://mcp.connie.ai/api/mcp?client=claude-desktop",
"0",
"--static-oauth-client-metadata",
"{\"client_name\":\"Claude Desktop\"}"
]
}
}
}
```
Same bridge pattern as Cursor. **Settings → MCP → Add server**, or edit the config directly:
```json theme={null}
{
"mcpServers": {
"connie": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://mcp.connie.ai/api/mcp?client=windsurf",
"0",
"--static-oauth-client-metadata",
"{\"client_name\":\"Windsurf\"}"
]
}
}
}
```
Restart Windsurf. First tool call triggers the browser OAuth flow — the consent screen will say **"Windsurf wants to connect to your Connie workspace"**.
***
## 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](/mcp/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:
```bash theme={null}
npx -y mcp-remote https://mcp.connie.ai/api/mcp?client=my-bot 0 \
--static-oauth-client-metadata '{"client_name":"My Internal Bot"}'
```
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.
```bash theme={null}
npx -y mcp-remote https://mcp.connie.ai/api/mcp?client=debug-cli 0 \
--static-oauth-client-metadata '{"client_name":"MCP CLI (debug)"}'
```
Add `--debug` for the full handshake log:
```bash theme={null}
npx -y mcp-remote https://mcp.connie.ai/api/mcp?client=debug-cli 0 --debug \
--static-oauth-client-metadata '{"client_name":"MCP CLI (debug)"}'
```
To force a fresh OAuth flow (clear the local token cache):
```bash theme={null}
# macOS / Linux
rm -rf ~/.mcp-auth
# Windows PowerShell
Remove-Item -Recurse -Force "$env:USERPROFILE\.mcp-auth"
```
***
## What's next
One OAuth grant covers every workspace you're in — here's how to address a specific one per request.
OAuth failures, missing tools, and the `MCP CLI Proxy` placeholder explained.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.