Skip to main content

MCP servers

OrbCode connects to external tools via the Model Context Protocol (MCP). MCP servers expose tools that appear alongside the native tools as mcp__<server>__<tool> and can be called by the model like any other tool.

Configuration

settings.json, env vars, custom models, and sessions

Skills & memory

Reusable instruction sets and AGENTS.md project memory
MCP server configs live in settings.json and .mcp.json. The repo-level .orb/ folder holds project memory (.orb/AGENTS.md) and linked-repo metadata (.orb/links.json) — see Configuration → Linked repositories and Usage → /link.

Configuration scopes

MCP servers are configured in three scopes (highest precedence last):
  1. User scopemcpServers in ~/.orbcode/settings.json. Applies to every project on this machine.
  2. Project scope.mcp.json in the project root (and parent directories, closer-to-cwd wins). This is the check-into-git, shared format, compatible with Claude Code’s .mcp.json.
  3. Local scopemcpServers in .orbcode/settings.json. Per-project, per-machine overrides (not checked in).
.mcp.json format (project scope):
settings.json mcpServers (user/local scope) uses the same per-server shape. Environment variables (${VAR}) are expanded from process.env.

Server types

Three server types are supported:
  • stdio (default, omit type) — OrbCode spawns command with args and talks over stdin/stdout. Optional env and cwd.
  • http — Streamable HTTP transport. url + optional headers + optional oauth.
  • sse — Server-Sent Events (legacy remote). url + optional headers + optional oauth.

Adding servers from the command line

The orbcode mcp subcommand manages servers without editing JSON by hand:
OrbCode’s mcp add command is a drop-in replacement for Claude Code’s claude mcp add. Any claude mcp add ... command you find in third-party MCP server docs works as-is — just swap claude for orbcode. For example, claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem becomes orbcode mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem.
Flags go before the server name; everything after the name is the command + args (so stdio servers can take their own flags like -y). Use -- to force the split if needed (a -- immediately after the server name is consumed as the separator, matching Claude Code’s claude mcp add <name> -- <command>). -s/--scope selects project (default, writes .mcp.json), user (writes ~/.orbcode/settings.json), or local (writes .orbcode/settings.json). add and remove print the file they modified:

The /mcp interactive manager

The /mcp command opens an interactive manager at any time:
  • ↑/↓ to select a server. The selected server shows a detail panel with Status, Auth (authenticated / not authenticated / static headers), URL (or stdio command), Config location (the file path), and a numbered action list.
  • enter or 2 toggles enable/disable. r or 3 reconnects. a or 1 authenticates a needs-auth OAuth server (opens a browser for the authorization-code flow; M2M grants exchange directly). esc closes.
  • Each server shows a live status icon: ✓ connected, △ needs-auth, ✗ failed, ○ disabled, ⋯ connecting, plus a tool count when connected.
  • Enable/disable choices are persisted per-project. OAuth tokens are persisted per-server under ~/.orbcode/mcp-auth/.

Enabling & disabling servers

  • User/local-scope servers connect automatically on startup (you wrote them, so they’re trusted).
  • Project-scope servers (from .mcp.json) require a one-time approval: on first launch in a project, OrbCode shows a checklist of detected servers. Select the ones you trust; the decision is persisted to .orbcode/settings.json (enabledMcpServers / disabledMcpServers) so they auto-connect on future sessions.

Authentication

Remote servers (http/sse) often require auth. OrbCode supports three ways: 1. Static headers (API keys, personal access tokens). Use headers with ${ENV_VAR} expansion — the token is read from the environment, never written to disk:
2. OAuth 2.0 flows (for servers that require user login: GitHub, Google Drive, Slack, Notion, …). Set oauth: true (or { "scope": "..." }) on an http/sse server. OrbCode runs the full authorization-code flow via the SDK: RFC 9728 protected-resource discovery, RFC 8414 authorization-server metadata, PKCE, dynamic client registration, and token refresh. A one-shot loopback HTTP server receives the browser redirect. Tokens, client info, code verifiers, and discovery state are persisted per-server under ~/.orbcode/mcp-auth/<server>.json (mode 0600) so re-auth is only needed when a token expires or is revoked.
3. Machine-to-machine OAuth (no browser). For service-to-service auth, use client_credentials or private_key_jwt grants:
When a server needs auth, its status shows needs-auth in /mcp; press a to re-authenticate (clears stored tokens and re-runs the flow). Secrets in oauth blocks support ${ENV_VAR} expansion like headers, so client secrets and private keys can be sourced from the environment rather than committed to .mcp.json.

Headless mode

In orbcode -p, there’s no interactive approval, so project-scope servers are only connected if they were previously approved (via an interactive /mcp session). Unapproved project servers are skipped with a stderr note. User/local servers connect as usual.

Figma MCP servers

OrbCode ships a native figma_fetch tool that fetches a Figma design’s full node tree, components, styles, and rendered image URLs, authenticated through the MatterAI backend using your org’s configured Figma access token. Because that native integration is the supported path, external Figma MCP servers are blocked — the desktop dev server, the hosted mcp.figma.com endpoint, and figma-developer-mcp via npx are rejected on connect, config load, orbcode mcp add, and /migrate (both live and dry-run), and Figma-specific tools are filtered out of general servers’ tool listings. Use figma_fetch (or just paste a Figma URL into a prompt — it’s auto-fetched) instead.