MCP Servers in 5 IDE AI Assistants

VS Code: the reference integration

VS Code 1.99 added the .vscode/mcp.json configuration file — a workspace-level server registry that is shared with the team via git. Alongside it, user-level servers can be added to settings.json under the mcp.servers key. When the workspace is trusted, VS Code sends initialize and tools/list to each configured server at startup and whenever MCP: Restart Server is run from the Command Palette.

The configuration format uses a servers object with named entries. Each entry specifies type: "http" (for Streamable HTTP transport, POST/GET/DELETE on a single URL) or type: "stdio" (for subprocess-based servers). HTTP servers support an headers field for authentication — the right pattern is to reference an ${input:var} variable rather than hardcoding keys in a file that lands in git:

{
  "inputs": [
    { "id": "api-key", "type": "promptString", "description": "API key", "password": true }
  ],
  "servers": {
    "my-tools": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": { "Authorization": "Bearer ${input:api-key}" }
    }
  }
}

VS Code prompts each developer once for the value and stores it in OS-level secure storage (macOS Keychain, Windows Credential Manager, libsecret on Linux). The file stays clean in git.

MCP tools are invoked through GitHub Copilot Chat's agent mode — not regular chat mode, not the command palette. This is a hard requirement: VS Code discovers and connects to MCP servers regardless of Copilot, but the tool-call surface is only exposed in agent mode. VS Code reads tool annotations (readOnlyHint, destructiveHint) to color-code the approval prompt — green for read-only tools, red for destructive ones. Permanent "always allow" is available for tools the developer fully trusts.

Silent failure mode: When the MCP server goes down, VS Code shows "Tool unavailable" in the Copilot Chat thread. The message does not mention which server failed or that the failure is a server outage rather than a tool error. Developers on a team sharing a server via .vscode/mcp.json typically file a Copilot bug report rather than checking the server. The MCP Output panel (View → Output → MCP: <server-name>) shows the raw protocol failure — but only developers who know to look there will find it.

GitHub Copilot: token budget and session-start check

GitHub Copilot uses the same VS Code MCP discovery mechanism and reads the same .vscode/mcp.json file. The meaningful differences are in Copilot's subscription requirements and in how it handles tool availability over time.

MCP tool calls in agent mode require a paid Copilot subscription — Copilot Free (available to GitHub Education and some open-source contributors) does not include agent mode at all. Individual, Business, and Enterprise plans all support MCP tools; Business and Enterprise plans add organization-level policy controls under Copilot → Policies → Agent features that let admins restrict which MCP servers organization members can configure.

The token budget consideration is specific to Copilot's architecture. Every tool registered in the agent mode session is serialized into the system prompt as a JSON schema so the LLM can decide which tool to call. A moderately complex tool schema consumes 200–800 tokens. A server registering 20 tools adds 4,000–16,000 tokens to every agent mode context, including messages that never trigger a tool call. On long coding sessions, this token overhead compounds:

Silent failure mode: Copilot checks tool availability at session start — when agent mode activates and Copilot builds its tool registry. A server that goes down after the session begins may still appear in the tool picker for the rest of the session. When Copilot eventually tries to invoke a tool and the server times out or returns an error, it silently stops offering that server's tools or shows "Tool unavailable" without explaining whether the server is down or the tool itself failed. Developers interpret this as a Copilot regression, not a server outage.

Zed: context_servers and three gotchas

Zed's AI assistant configures MCP servers via the context_servers key in settings.json (global, at ~/.config/zed/settings.json) or .zed/settings.json at the project root for team-shared server lists. The schema differs from VS Code's: instead of a servers key with type fields, Zed uses a source object with type: "url" for HTTP or type: "binary" for stdio:

{
  "context_servers": {
    "my-tools": {
      "source": { "type": "url", "url": "https://mcp.example.com/mcp" },
      "settings": { "workspace_id": "proj-alpha" }
    },
    "local-dev": {
      "source": { "type": "binary", "command": "node", "args": ["dist/index.js"] }
    }
  }
}

Three gotchas distinguish Zed from VS Code:

No native auth headers. VS Code's headers field has no equivalent in Zed's context_servers schema. For authenticated HTTP MCP servers in Zed, the options are: expose a local stdio proxy that handles authentication and forwards to the remote HTTP server; use an environment variable read at request time by the server process; or use IP allowlist / mTLS so no per-developer bearer token is needed. The settings field passes arbitrary key-value pairs to the server's initialize request, so a server can read configuration this way — but secrets should not be placed in a file that may be committed to git.

No "always allow" option. Zed requires per-call approval for every tool invocation. There is no session-level or permanent "always allow" — each tool call generates a prompt. This is a deliberate security design but creates friction for frequently-invoked read-only tools that other IDE clients allow permanently approving.

macOS launchd PATH problem. When Zed is launched from the Dock or Finder (rather than from a terminal with zed .), it runs in macOS's GUI launchd environment, which has a minimal PATH of /usr/bin:/bin:/usr/sbin:/sbin. Node.js installed via nvm, Python installed via pyenv, and any tool installed via Homebrew into /opt/homebrew/bin are invisible to this environment. A stdio MCP server configured with "command": "node" will silently fail to start — no binary found, no error in the Zed UI, tools never appear in the assistant panel. The fix: use the absolute binary path from the nvm or pyenv shim directory, or write a wrapper shell script that sources the correct profile before launching the server.

Silent failure mode: When an MCP server goes down, Zed silently removes its tools from the assistant panel. There is no error notification, no banner, no log entry visible to the developer. The assistant continues to work — it simply no longer offers the affected tools. Developers typically do not notice until they try to trigger a tool by name and the LLM responds that it doesn't have access to that capability.

Amazon Q Developer: IAM-aware MCP with two config locations

Amazon Q Developer — AWS's AI coding assistant available as a VS Code extension and in JetBrains IDEs — uses a mcp.json configuration format similar to Claude Desktop's. It reads from two locations:

The format uses a mcpServers key (note: not servers like VS Code, and not context_servers like Zed). Both stdio (command + args) and HTTP (url + headers) transports are supported. Environment variable references in the form ${MY_API_KEY} are resolved from the process environment at configuration read time — set these in your shell profile or use a secrets manager that exports to the environment.

The AWS-specific consideration is IAM scoping. When a stdio MCP server tool calls AWS APIs (S3, DynamoDB, Lambda, CloudWatch), it runs using whatever credentials are available to the server process — by default the developer's full personal AWS credentials from ~/.aws/credentials or the active SSO session. The MCP tool can invoke any AWS API the developer is permitted to use, including destructive operations. For MCP servers that call AWS APIs, the right pattern is to assume a dedicated least-privilege IAM role at server startup rather than relying on developer credentials:

// Assume a scoped role at startup rather than using developer credentials
const role = await sts.send(new AssumeRoleCommand({
  RoleArn: process.env.MCP_TOOLS_ROLE_ARN,
  RoleSessionName: 'mcp-tools-session',
  DurationSeconds: 3600,
}));
const s3 = new S3Client({ credentials: fromTemporaryCredentials(role) });

Amazon Q also needs dual monitoring. AliveMCP's protocol probe catches MCP server process failures, network issues, and protocol-level errors. For AWS-integrated MCP servers, you also want a custom /health/aws endpoint that exercises the actual AWS API calls the tools make — an S3 GetObject or DynamoDB Query that verifies the IAM role assumption and API access are working, not just that the server process is running.

Silent failure mode: Amazon Q logs MCP connection errors in the Amazon Q extension log, accessible via the Output panel with the "Amazon Q" channel selected. This log is not surfaced to the developer in any visible UI element — the Q Chat panel simply stops offering the affected server's tools. For teams using Amazon Q with shared MCP servers, errors are invisible unless someone actively monitors the extension log.

JetBrains AI Assistant: Java HttpClient and restart-only reconnect

JetBrains AI Assistant — available across IntelliJ IDEA, WebStorm, PyCharm, Rider, CLion, and GoLand starting with the 2025.1 platform release — configures MCP servers through either the IDE settings UI (Settings → Tools → AI Assistant → Model Context Protocol (MCP)) or a mcp.json file at the project root. The UI path configures user-level servers (stored in JetBrains' per-user configuration directory, not shared with teammates); the mcp.json file is committed to git for team-shared server lists:

// mcp.json — project root (committed to git)
{
  "servers": {
    "project-tools": {
      "url": "https://mcp.example.com/mcp",
      "headers": { "X-API-Key": "${MCP_API_KEY}" }
    },
    "local-search": {
      "command": "/Users/dev/.nvm/versions/node/v22.0.0/bin/node",
      "args": ["dist/index.js"],
      "env": { "NODE_ENV": "production" }
    }
  }
}

Two JetBrains-specific constraints matter for server authors:

Java HttpClient strict SSL. JetBrains makes HTTP requests from the IDE process via Java's built-in HttpClient — not from a browser, so there are no CORS restrictions. However, Java's HttpClient uses the JetBrains trust store for SSL validation. Self-signed certificates on localhost work only if the certificate is added to the trust store or the IDE's proxy settings bypass certificate checks for localhost. For local development, use plain HTTP rather than HTTPS to avoid certificate issues. For production, use a properly CA-signed certificate — the JetBrains trust store includes standard CAs but not custom enterprise CAs unless explicitly added.

macOS launchd PATH. Same problem as Zed: JetBrains IDEs launched from the macOS Dock or Finder run in the GUI launchd environment with a minimal PATH. Node.js from nvm, Python from pyenv, and tools from Homebrew are not visible. Always use absolute binary paths in mcp.json for stdio servers on macOS.

Per-call approval only. JetBrains offers Run/Skip per tool call. There is no session-level "always allow" and no permanent approval — every tool invocation generates an approval prompt in the AI Assistant panel. This matches Zed's behavior and differs from VS Code and Amazon Q, which both offer session-level and permanent approval options.

Silent failure mode: JetBrains is the most severe case. The IDE establishes MCP connections at startup and at project open time. If the server goes down after the IDE opens, JetBrains does not retry the connection. The monitoring gap is complete: tools may appear to be available in the AI Assistant panel (cached from the initial tools/list) but will fail when invoked. JetBrains discovers the outage only when it tries to call a tool and gets a network error — or when the developer explicitly restarts the IDE or uses the "Reconnect" button in the MCP settings UI. A server that goes down at 9 AM may not be noticed until the affected developer restarts their IDE hours later.

The cross-cutting problem: all five fail silently

The five IDE clients have different config formats, different approval flows, and different transport constraints. What they share is a single architectural pattern: they build a tool registry at connection time and do not continuously verify that the underlying MCP server is still healthy. The consequences when a server goes down:

None of the five clients notify the developer proactively that a server is down. None attribute the failure to the specific server in a way that helps a developer quickly diagnose the issue. And none alert the MCP server author — the person who can actually fix the problem — at all.

The practical result: when a team MCP server goes down, the first reports are Copilot/Zed/Amazon Q/JetBrains bug reports filed by developers who assume their IDE is misbehaving. The server author finds out hours later when someone eventually looks in the right log or thinks to ping the server URL directly.

Monitoring that works across all five clients

Because all five IDE clients abstract away the underlying protocol, a standard HTTP health check (GET /health returning 200) misses the failure modes that actually affect developers. An MCP server can return HTTP 200 on /health while the initialize handshake fails, while tools/list returns an empty array due to a startup exception, or while a tool handler silently throws on every invocation. Each of these states looks fine to a load balancer or uptime monitor checking HTTP status codes.

What catches the actual failure is a full protocol probe:

1. Send initialize — verify the handshake completes and the response contains protocolVersion: "2024-11-05"
2. Call tools/list — verify the server returns at least one tool (an empty list after initialization means tool registration failed at startup)
3. Invoke a sentinel tool — verify the tool execution path works end-to-end, not just the protocol layer

Run this probe on a 60-second interval and alert when any step fails. The probe should run from outside your deployment network — from the same vantage point that VS Code, Zed, and JetBrains access the server. This catches network misconfigurations, TLS issues, and routing failures that internal health checks never see.

AliveMCP runs this full protocol probe every 60 seconds and alerts the server author — not the IDE users — the moment any layer fails. The alert arrives before the first developer files a "Copilot is broken" report. For teams shipping MCP servers to VS Code, Copilot, Zed, Amazon Q, or JetBrains users, add your server URL to AliveMCP monitoring as part of your deployment checklist — it's the one monitoring layer that covers all five IDE clients regardless of their individual failure modes.

Deep dives

• MCP server in VS Code — .vscode/mcp.json, Copilot agent mode, tool debugging
• MCP server with GitHub Copilot — agent mode, tool approval, plan requirements
• MCP server in Zed editor — context_servers configuration, assistant integration
• MCP server with Amazon Q Developer — configuring MCP tools in AWS Toolkit
• MCP server in JetBrains AI Assistant — IntelliJ, WebStorm, PyCharm configuration
• MCP tool annotations — readOnlyHint, destructiveHint, and idempotentHint
• Debugging MCP servers — protocol traces, inspector, and runtime errors
• MCP server health checks — protocol probes and readiness verification
• AliveMCP — continuous protocol monitoring for MCP servers