Configure MCP Servers in VS Code

Use this reference to configure MCP servers for GitHub Copilot chat in VS Code with .vscode/mcp.json (workspace) or profile-level mcp.json (user scope).

Where Configuration Lives

VS Code supports two MCP configuration locations:

Workspace scope: .vscode/mcp.json in the repository.
User profile scope: open with the MCP: Open User Configuration command.

Use workspace scope for shared team configuration, and user scope for personal or machine-specific servers.

Minimal mcp.json

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp"
    },
    "playwright": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@microsoft/mcp-server-playwright"]
    }
  }
}

The servers object keys are logical server names shown in VS Code MCP management surfaces.

Add Servers Through VS Code UI

Run MCP: Add Server from the Command Palette.
Choose Workspace or Global target.
Review generated config in mcp.json.
Start or restart the server from MCP: List Servers.

This guided flow is usually safer than manual edits when onboarding teammates.

Security and Secrets

Do not hardcode tokens or API keys in mcp.json.
Prefer input variables or environment-file patterns supported by the MCP configuration schema.
Start only trusted servers, because local servers can execute code on your machine.
Use trust prompts as a checkpoint instead of bypassing review.

Security Best Practices

Apply least privilege by default.
Keep workspace mcp.json limited to team-safe, non-secret configuration.
Keep personal credentials and machine-specific settings in user-scope configuration, not repository files.
Prefer explicit allowlists for filesystem writes and outbound network access when sandboxing is enabled.
Use one server per trust boundary instead of one large multi-purpose server.
Review server command and args as code during pull requests.
Disable or uninstall unused MCP servers to reduce attack surface.
Use HTTPS endpoints for remote MCP servers whenever available.
Pin server packages or versions where practical to avoid accidental supply-chain drift.
Reset trust and re-review configuration after major server changes.

Operational Guardrails

Treat MCP resources as publishable unless an explicit access control layer exists.
Capture server logs during onboarding so failures and suspicious behavior are easier to detect.
Define ownership for each server entry, including who approves changes and who rotates secrets.
Document upgrade triggers: if a server starts reading private data or executing side-effectful actions, require stronger access controls before rollout.

Team Review Checklist

Use this checklist before merging workspace MCP configuration changes:

No plaintext secrets in mcp.json.
command and args are from trusted publishers and expected binaries.
Server scope is correct (workspace vs user profile).
Sandboxing is enabled for local stdio servers when supported.
Sandbox allowlists are narrow (minimum paths and domains).
The change includes an owner and rollback path.

Sandbox Local stdio Servers (Linux/macOS)

For local stdio servers, enable sandboxing when possible:

{
  "servers": {
    "myServer": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@example/mcp-server"],
      "sandboxEnabled": true
    }
  },
  "sandbox": {
    "filesystem": {
      "allowWrite": ["${workspaceFolder}"]
    },
    "network": {
      "allowedDomains": ["api.example.com"]
    }
  }
}

Sandboxing is currently available on Linux and macOS, not Windows.

Troubleshooting Checklist

Open server logs from MCP: List Servers -> Show Output.
Confirm trust state (or run MCP: Reset Trust if needed).
Confirm server command and arguments run outside VS Code.
Confirm workspace-vs-user scope matches where you expect the server to run.
If using remote development, configure the server in the remote scope when needed.

4.7 KiB Raw Blame History