Every MCP client connects the same way: one URL and one header. What differs is which file the client keeps its config in.
<server-name> is the name shown on the server in the dashboard. The key is
one you created under Settings → API Keys.
Danger
Connect to the gateway, never to a server's own address. A server's
endpoint is the gateway's internal proxy target — reaching it directly
bypasses the permission check, the credential injection and the audit log, which
is to say it bypasses Statio entirely.
| Client | Config file |
|---|---|
| Claude Desktop | ~/Library/Application Support/Claude/claude_desktop_config.json |
| Cursor | ~/.cursor/mcp.json |
| Windsurf | ~/.codeium/windsurf/mcp_config.json |
| VS Code | ~/.vscode/mcp.json |
| Cline | ~/Library/.../cline_mcp_settings.json |
| Continue.dev | ~/.continue/mcpServers/mcphub.json |
| Zed | ~/.config/zed/settings.json |
| Amazon Q | ~/.aws/amazonq/mcp.json |
Paths are macOS; Linux and Windows equivalents differ per client.
For a client that supports remote MCP servers with custom headers:
Add one entry per server. The key at the top ("github" here) is the name your
agent sees; it does not have to match the server name in the URL, though keeping
them the same saves confusion later.
Note
Client support for remote MCP servers is uneven and moving quickly. A client that only speaks stdio needs a local bridge process rather than the config above — check its current documentation for remote-server support before assuming this shape works.
Ask your agent to list its available tools. You should see the tools you were granted, not every tool the server exposes — that difference is the product doing its job.
Then check Audit in the dashboard. The listing itself is recorded, so a call that appears there confirms the whole path end to end.
Almost always a missing grant rather than a broken connection. A server you can reach exposes only the tools you hold permission for; see Permissions.
If nothing at all appears, check in this order: