Configuring MCP In Vs Code Extension

The Claude Code VS Code extension shares its MCP engine with the CLI — same mcpServers schema, same .claude/settings.json files — but it wraps configuration in a GUI panel and adds a few IDE-specific conveniences (and a couple of quirks) that are worth knowing before you roll it out to a team that lives in VS Code rather than a terminal.

Installing the Claude Code VS Code Extension

Install it from the Extensions marketplace inside VS Code, or from the command line if you script your dev environment setup:

code --install-extension anthropic.claude-code

Requirements worth checking first:

• VS Code 1.85 or newer (the extension uses the Language Model Tool API surface that stabilized around that version).
• The Claude Code CLI does not need to be separately installed for the extension to work standalone, but if you also use the CLI in the integrated terminal, keep both on the same major version — mismatched versions have, in my testing, produced inconsistent mcpServers parsing between the two.

After install, open the Command Palette (Cmd+Shift+P / Ctrl+Shift+P) and run:

> Claude Code: Sign In

Authenticate the same way as the CLI (OAuth browser flow, or paste an API key when prompted). Once signed in, open the Claude Code sidebar icon in the Activity Bar — this is your main interaction surface, and it's where the MCP panel lives.

Verify the extension loaded correctly by checking the Output panel:

View → Output → select "Claude Code" from the dropdown

You should see an initialization log with no red error lines before proceeding to MCP setup.

Tips
- If you use VS Code workspaces (multi-root), install the extension at the user level, not per-workspace — per-workspace MCP config still comes from .claude/settings.json inside each root folder.
- Restart the extension host (Developer: Restart Extension Host) after any manual settings file edit — unlike the CLI, the extension doesn't always hot-reload .claude/settings.json mid-session.

Opening and Editing the MCP Settings Panel in VS Code

The GUI path: open the Claude Code sidebar, click the gear icon, and select MCP Servers. This panel lists every server currently resolved from both user and project scope, with a status dot (green/yellow/red) per entry.

From here you can:

• Click Add Server to open a form (name, transport type, command/URL, env vars) — this writes directly to .claude/settings.json or ~/.claude/settings.json depending on the scope toggle you select.
• Click an existing server to edit its command, args, or headers inline.
• Toggle a server on/off without deleting its config — useful when debugging which server is causing a slow startup or tool-selection noise.

For anyone who prefers text over forms (most mid/senior devs, in my experience), there's a faster path: open the raw file directly.

> Claude Code: Open MCP Settings (JSON)

This opens .claude/settings.json in the editor with schema-aware autocomplete — VS Code will suggest command, args, env, type, url, and headers keys as you type, and flag an invalid shape with a red squiggle before you even try to run it.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

One quirk specific to the extension: it resolves ${VAR} references from the environment VS Code itself was launched in, not necessarily your shell's interactive environment. If you launch VS Code from the macOS Dock rather than a terminal, it may not inherit variables exported in .zshrc. Launch VS Code from a terminal (code .) when you need shell-exported secrets to reach MCP servers reliably.

Tips
- Use Claude Code: Open MCP Settings (JSON) over the form UI once you're managing more than two or three servers — the JSON schema autocomplete catches typos the form UI won't.
- If ${VAR} isn't resolving, launch VS Code with code . from the same shell session where the variable is exported, or set it in a .vscode/settings.json-adjacent .env loaded by your shell profile.

Adding Local vs Remote MCP Servers in the Extension

The trade-off between local (stdio) and remote (SSE/HTTP) servers is the same as in the CLI, but the extension surfaces it more visibly through its status panel, which is genuinely useful for diagnosing issues.

Local stdio servers spawn a child process managed by the extension host:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "${workspaceFolder}"]
    }
  }
}

Note ${workspaceFolder} — the extension supports this VS Code-native variable inside MCP args, which the CLI does not. It resolves to the currently open workspace root, making project-relative config portable across machines without hardcoding absolute paths.

Remote SSE/HTTP servers connect over the network and don't spawn anything locally:

{
  "mcpServers": {
    "figma": {
      "type": "sse",
      "url": "http://127.0.0.1:3845/sse"
    },
    "notion": {
      "type": "http",
      "url": "https://mcp.notion.com/mcp",
      "headers": {
        "Authorization": "Bearer ${NOTION_MCP_TOKEN}"
      }
    }
  }
}

Trade-offs I weigh when choosing between them for a team:

For something like the Figma desktop app's local MCP server, SSE against 127.0.0.1 is the only option since it runs inside the desktop app itself. For SaaS integrations like Notion or Linear, remote HTTP is standard and avoids asking every teammate to manage a local process.

Tips
- Prefer ${workspaceFolder} over absolute paths in any project-scoped config you intend to commit — it's the difference between config that works for the whole team and config that only works on your laptop.
- For remote servers requiring OAuth (not a static bearer token), use the extension's Add Server form once — it handles the browser redirect and stores the resulting token in VS Code's secret storage rather than plaintext JSON.

Verifying MCP Tools Are Available in Your VS Code Workspace

Confirming tools are live involves two checks: the extension's own status panel, and Claude actually choosing to use the tool during a real request.

First, the panel check — open the MCP Servers panel again and confirm every server shows a green dot. Click a connected server to expand its tool list; you should see each tool's name and a one-line description pulled straight from the server's own schema.

Second, the functional check. In the Claude Code chat panel, ask something that can only be answered via a specific tool:

> List the open pull requests on this repo using the GitHub MCP server

Watch the response stream — Claude Code surfaces a distinct "Using tool: github.list_pull_requests" indicator inline before the tool result appears. If that indicator never shows and Claude instead answers generically or says it doesn't have access, the tool likely isn't registered correctly even if the panel shows green (a stale panel is a known rough edge — refresh with Developer: Reload Window).

For scripted verification across a team's machines, use the CLI's list command in the integrated terminal — since it reads the same config files, it's a fast way to sanity-check without opening the GUI panel at all:

claude mcp list

github       npx -y @modelcontextprotocol/server-github   ✓ connected
figma        http://127.0.0.1:3845/sse (sse)               ✓ connected
notion       https://mcp.notion.com/mcp (http)             ✗ auth expired

Tips
- Don't trust a green status dot alone after a config change — run one real tool-invoking prompt to confirm Claude actually picks the tool up.
- When onboarding a new teammate, have them run claude mcp list in the integrated terminal as a first check — it's faster to screen-share and debug than walking through GUI panels.

Tips

Tips
- Keep project-scoped .claude/settings.json committed for shared servers, and rely on ${workspaceFolder} so paths stay portable across every teammate's checkout location.
- Reload the extension host after manual JSON edits — the GUI doesn't always pick up file changes live the way the CLI's file-watcher does.
- When a server works in the CLI but not the extension (or vice versa), the usual culprit is environment variable resolution differing between how you launched the terminal versus how VS Code itself was launched.