Connect over MCP

The first form signs in through the browser when you run /mcp. In .mcp.json (project root), ${MCPBYTES_API_KEY} is read from the environment when Claude Code connects. Claude Code docs

claude mcp add --transport http mcpbytes \
  https://api.mcpbytes.com/mcp

Codex reads the key from the environment variable each time it connects. The same table can go in ~/.codex/config.toml by hand; codex mcp add has no --header flag. Codex docs

codex mcp add mcpbytes --url https://api.mcpbytes.com/mcp \
  --bearer-token-env-var MCPBYTES_API_KEY

~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project). Remote servers take no "type". Without the header, the client signs you in with GitHub or an email link (OAuth). Cursor docs

{
  "mcpServers": {
    "mcpbytes": {
      "url": "https://api.mcpbytes.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:MCPBYTES_API_KEY}"
      }
    }
  }
}

.vscode/mcp.json, or "MCP: Open User Configuration". The top-level key is "servers". VS Code asks for the key once and stores it securely. Without the header, the client signs you in with GitHub or an email link (OAuth). VS Code docs

{
  "inputs": [
    {
      "type": "promptString",
      "id": "mcpbytes-api-key",
      "description": "MCPBytes API key (mcpb_...)",
      "password": true
    }
  ],
  "servers": {
    "mcpbytes": {
      "type": "http",
      "url": "https://api.mcpbytes.com/mcp",
      "headers": {
        "Authorization": "Bearer ${input:mcpbytes-api-key}"
      }
    }
  }
}

~/.gemini/settings.json or .gemini/settings.json. The key is "httpUrl" ("url" means the older SSE transport). Without the header, the client signs you in with GitHub or an email link (OAuth). Then sign in with /mcp auth. Gemini CLI docs

{
  "mcpServers": {
    "mcpbytes": {
      "httpUrl": "https://api.mcpbytes.com/mcp",
      "headers": {
        "Authorization": "Bearer ${MCPBYTES_API_KEY}"
      }
    }
  }
}

opencode.json or ~/.config/opencode/opencode.json. Variables are written {env:NAME}. "oauth": false makes a wrong key an error instead of a sign-in; remove it and the headers to sign in with OAuth. OpenCode docs

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "mcpbytes": {
      "type": "remote",
      "url": "https://api.mcpbytes.com/mcp",
      "enabled": true,
      "oauth": false,
      "headers": {
        "Authorization": "Bearer {env:MCPBYTES_API_KEY}"
      }
    }
  }
}

.omp/mcp.json (project) or ~/.omp/agent/mcp.json (user). Without the header, the client signs you in with GitHub or an email link (OAuth). Then run /mcp reauth mcpbytes in a session. omp also picks up servers already set up for Claude Code, Cursor, VS Code, Gemini CLI and Codex. oh-my-pi docs

{
  "mcpServers": {
    "mcpbytes": {
      "type": "http",
      "url": "https://api.mcpbytes.com/mcp",
      "headers": {
        "Authorization": "Bearer ${MCPBYTES_API_KEY}"
      }
    }
  }
}

pi has no MCP support, by design: its author recommends command-line tools described by a skill. Install the MCPBytes skill (it drives the REST API with a small script), or add MCP with the pi-mcp-adapter extension. pi docs

mkdir -p ~/.pi/agent/skills/mcpbytes
curl -fsSL https://mcpbytes.com/skills/mcpbytes/mcpbytes.tar.gz \
  | tar -xz -C ~/.pi/agent/skills/mcpbytes

DeepSeek's API does not run MCP servers itself: the agent you use DeepSeek models in does (Claude Code, OpenCode, oh-my-pi, Cline: use that agent's entry here). DeepSeek's own agent, DeepSeek Harness (dsh, a developer preview), takes this patch in ~/.dsh/cordis.patch.yml; it supports headers, not OAuth. DeepSeek docs

- insert:
    - id: mcp-mcpbytes
      name: '@deepseek-ai/dsh-mcp-client'
      config:
        serverName: mcpbytes
        transport: streamable-http
        url: https://api.mcpbytes.com/mcp
        headers:
          Authorization: !!js '`Bearer ${process.env.MCPBYTES_API_KEY}`'

~/.codeium/windsurf/mcp_config.json. Without the header, the client signs you in with GitHub or an email link (OAuth). Cascade allows 100 tools in total, so a single-family endpoint helps. Windsurf docs

{
  "mcpServers": {
    "mcpbytes": {
      "serverUrl": "https://api.mcpbytes.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:MCPBYTES_API_KEY}"
      }
    }
  }
}

~/.config/goose/config.yaml (Windows: %APPDATA%\Block\goose\config\config.yaml), or "goose configure" > Add Extension > Remote Extension (Streamable HTTP). The key is "uri". Without the header, the client signs you in with GitHub or an email link (OAuth). Goose docs

extensions:
  mcpbytes:
    type: streamable_http
    name: mcpbytes
    enabled: true
    uri: "https://api.mcpbytes.com/mcp"
    headers:
      Authorization: "Bearer ${MCPBYTES_API_KEY}"
    env_keys:
      - MCPBYTES_API_KEY
    timeout: 300

settings.json, or Settings > AI > MCP Servers > Add Server > Add Remote Server. Zed's settings cannot read environment variables, so sign in instead of storing a key: with no Authorization header, Zed starts the OAuth sign-in. Zed docs

{
  "context_servers": {
    "mcpbytes": {
      "url": "https://api.mcpbytes.com/mcp"
    }
  }
}

These add remote servers as connectors and sign in with OAuth; there is no field for an API key. Claude: Customize > Connectors > Add custom connector. ChatGPT: turn on Developer mode in Settings, then create an app. Enter this URL: Claude docs

https://api.mcpbytes.com/mcp

mcp-remote runs locally and forwards to the endpoint. The header is written without a space and takes its value from "env", because some clients on Windows break arguments that contain spaces. Use it for Cline too. Without the --header arguments and "env", mcp-remote signs you in with OAuth. Any client that only starts local docs

{
  "mcpServers": {
    "mcpbytes": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://api.mcpbytes.com/mcp",
        "--transport",
        "http-only",
        "--header",
        "Authorization:${MCPBYTES_AUTH}"
      ],
      "env": {
        "MCPBYTES_AUTH": "Bearer <your key>"
      }
    }
  }
}