MCP server with GitHub Copilot

Agent mode vs Copilot Chat: what's different

GitHub Copilot Chat has two modes — Chat mode (default) and Agent mode. MCP tools are only available in agent mode:

Switch to agent mode using the mode toggle at the top of the Copilot Chat panel. In agent mode, Copilot has access to the tool registry built from all connected MCP servers plus VS Code's built-in tools (read file, run terminal command, create/edit file). The LLM chooses which tools to call based on your prompt — you do not explicitly invoke tools by name.

Configuring MCP servers for GitHub Copilot

GitHub Copilot uses VS Code's MCP discovery mechanism, which reads from .vscode/mcp.json at the workspace level and from the user-level settings.json at the mcp.servers key. The format is identical regardless of whether Copilot or another MCP client reads it:

// .vscode/mcp.json — shared with team via git
{
  "inputs": [
    {
      "id": "api-token",
      "type": "promptString",
      "description": "API token for the project MCP server",
      "password": true
    }
  ],
  "servers": {
    "project-tools": {
      "type": "http",
      "url": "https://mcp.myproject.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${input:api-token}"
      }
    },
    "code-search": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@myorg/code-search-mcp"]
    }
  }
}

For Copilot-specific configuration, you may want to restrict which tools Copilot can invoke. This is controlled by the tool approval mechanism (see below) rather than by filtering in the server configuration — all tools from a connected server are presented to Copilot regardless of the configuration. To expose only a subset of tools, implement filtering in your MCP server itself by returning only the intended tools from tools/list.

Tool approval workflow

Before Copilot executes any MCP tool call, VS Code shows an approval prompt displaying the tool name, description, and the exact arguments Copilot intends to pass. The developer must explicitly approve or block each call. This is a security boundary — it prevents Copilot from silently taking destructive actions via MCP tools.

The approval prompt shows:

• Tool name (e.g., delete_issue)
• Description from the tool's description field
• Arguments as formatted JSON — the developer can inspect exactly what will be sent
• Three options: Allow (once), Always Allow (for this session), Block

VS Code also reads MCP tool annotations to color-code the approval prompt:

Always set readOnlyHint: true on tools that only read data — it gives Copilot users confidence in the tool and reduces friction on frequently-invoked read operations. Set destructiveHint: true on tools that delete records, send emails, or make irreversible changes — the warning prompt reduces the chance of accidental destructive invocations.

Copilot subscription plan requirements

MCP tool calls in agent mode require a paid GitHub Copilot subscription. The free Copilot tier (available to verified students and some open-source contributors) does not include agent mode at all:

For organizations on Copilot Business or Enterprise, GitHub admins can set MCP-related policies in the organization settings under Copilot → Policies → Agent features. These policies control whether members can configure arbitrary MCP servers or only organization-approved servers.

Token budget impact of large tool schemas

Every tool registered in the Copilot agent mode session is serialized into the system prompt as a JSON schema — the LLM needs to read it to decide which tool to call. Large tool schemas increase token consumption on every Copilot Chat message in agent mode, even messages that don't result in tool calls.

Rule of thumb: each tool with a moderately complex schema consumes 200–800 tokens. A server registering 20 tools with detailed schemas adds 4,000–16,000 tokens to every agent mode context. With GPT-4o's context window, this is manageable; with models that have smaller effective context windows, it degrades response quality on long coding sessions.

Strategies to reduce token overhead:

Monitoring MCP servers used in Copilot workflows

Copilot agent mode fails silently when an MCP server is unavailable. If your server goes down mid-session, Copilot does not display an error — it simply stops offering your tools in the agent mode picker, or shows "Tool unavailable" when it tries to invoke a cached tool. Developers typically interpret this as a Copilot bug rather than a server outage, which means you may not receive a report until hours later.

The monitoring gap is compounded by Copilot's architecture: tool availability is checked at session start, not before each tool call. A server that goes down after the session begins may still appear in the tool picker — Copilot only discovers it's unavailable when it tries to make the tool call and the server returns an error or times out.

AliveMCP probes your server every 60 seconds with a full initialize + tools/list cycle, alerting you the moment the protocol handshake fails. Add your MCP server URL to AliveMCP monitoring as part of the server's CI/CD deployment pipeline — wire the alert to your team's Slack channel so outages get addressed before the next stand-up.

Further reading

• MCP server in VS Code — .vscode/mcp.json configuration and debugging
• MCP tool annotations — readOnlyHint, destructiveHint for client approval UX
• MCP server authentication — Bearer tokens, OAuth 2.0, API keys
• MCP server in Cursor — configuring MCP for Cursor's AI features
• MCP tool design — writing descriptions that LLMs select correctly
• AliveMCP — continuous protocol monitoring for MCP servers