Official starting points
| Topic | Official resource |
|---|---|
| Remote connections (Claude-oriented guide) | Connect to remote MCP servers |
| Local stdio connections | Connect to local MCP servers |
| Transport rules | Transports — 2025-11-25 |
| Auth | Authorization — 2025-11-25 |
| Ecosystem client list (examples) | What is MCP? — broad ecosystem support links Claude, ChatGPT, VS Code, Cursor, and others |
Host UIs change frequently — always confirm syntax in that product’s current docs:
- Cursor — MCP
- Claude connectors / remote and Claude product docs
- VS Code — MCP servers
Before you configure
- Deployment running and reachable over HTTPS
- Transport is Streamable HTTP for new remotes (current standard) — or you knowingly support legacy HTTP+SSE per the backwards-compatibility guide
- Auth material ready (OAuth or HTTP bearer/API key as your server requires)
- Exact MCP endpoint path (spec example uses a path like
/mcp)
MCPLambda product path: Connecting AI Clients.
Local vs remote config shapes
| Mode | Typical host config | Protocol basis |
|---|---|---|
| Local stdio | command + args (+ env) | Client launches subprocess (stdio) |
| Remote HTTP | Server URL (+ auth headers / OAuth) | Streamable HTTP |
Do not mix them for the same server entry.
Cursor
Use Cursor’s current MCP docs (cursor.com/docs/context/mcp). Remote servers are URL-based; local servers still use command/args. Reload MCP after config changes.
Claude Desktop / Claude remote
- Local:
claude_desktop_config.jsonwithmcpServerscommand/args — see official build server and connect local guides (macOS path:~/Library/Application Support/Claude/claude_desktop_config.json). - Remote: follow Connect to remote MCP servers and current Claude product connector UI — prefer product docs over outdated screenshots.
VS Code
Microsoft documents MCP server configuration for VS Code Copilot Chat: MCP servers in VS Code. Use that page for the live JSON schema and UI steps.
Auth
- Prefer mechanisms aligned with the Authorization specification for OAuth-capable HTTP servers
- Architecture overview notes HTTP bearer tokens, API keys, and custom headers as transport-layer options, with OAuth recommended for obtaining tokens: Architecture
- Never commit tokens to git
Verify
- Client shows the server as connected
tools/list(or host UI tool list) matches expectations- One successful tool call
- Failures appear in server logs
Optional: MCP Inspector.
Common failures
| Issue | What to check |
|---|---|
| Wrong path | Endpoint must match server’s MCP path (often /mcp) |
| stdio config for remote | Switch to URL-based remote config |
| 401 / 403 | Auth scheme, token, Origin validation on server |
| Works in one client only | Protocol version / transport support; try Streamable HTTP probe rules |
| Legacy remote only | HTTP+SSE backwards-compatibility path in transports |
Worked scenario: Three hosts, one URL
After deploy, Cursor works with a URL + header, Claude needs the connector OAuth flow, and VS Code uses its own MCP settings schema. Engineers assume the server is broken when only one host is misconfigured.
You publish a short matrix: server URL, transport (Streamable HTTP), auth method, and per-host deep links to current official docs. You forbid pasting long-lived tokens into git. Verification is always: connected → tools visible → one successful tool call → server logs show it.
Checklist for this topic
- Confirm server Running and endpoint path
- Use URL config for remote, command/args for stdio
- Follow each host’s current official docs for JSON shape
- Prefer HTTPS Streamable HTTP
- Store tokens outside git
- Verify with a real tool call, not only “connected”
Topic-specific failure modes
| Failure | Likely cause | Fix |
|---|---|---|
| Only one host works | Host-specific config | Per-host docs matrix |
| 401 everywhere | Auth header/scheme | Align with server auth |
| Wrong path | Missing /mcp | Copy exact deployment endpoint |
| Legacy SSE only client | Transport generation | Back-compat or upgrade client |
Related guides
Transports · Auth patterns · Debugging
In practice: host matrix doc
Keep a living table in your wiki:
| Host | Config location | Remote fields | Auth notes | Last verified |
Update “last verified” when the vendor changes settings UI. Stale screenshots cause more outages than broken servers.
Smoke test script for humans
After any host config change:
- Reload/restart MCP in the host
- Confirm server status connected
- Invoke a harmless read tool
- Confirm server logs show the call
- Revoke a token in staging and confirm failure mode is clear
If step 4 never happens, you are debugging the wrong layer.
Takeaways
For Connect a Remote MCP Server to Cursor, Claude, and VS Code, remember three things:
- Be specific to this problem — the worked scenario “Three hosts, one URL” is the failure mode you should design against, not a generic outage narrative.
- Validate the same Deployment URL in each host you ship for — Cursor, Claude, and VS Code each have different config surfaces.
- Treat host config drift as a release risk: document the exact JSON/UI steps and re-test after host updates.
If you only remember one habit: one green host is not three green hosts — smoke each client after every server deploy.
Sources
- Connect to remote MCP servers
- Connect to local MCP servers
- Transports — 2025-11-25
- Authorization — 2025-11-25
- Cursor MCP docs
- VS Code MCP servers
- MCPLambda — AI clients
