Adding MCP Servers to GitHub Copilot CLI

GitHub Copilot CLI already talks to GitHub through a built-in MCP server, so issues, pull requests and Actions runs work with no setup. For anything else you add a server once: copilot mcp add from the shell or /mcp add inside a session. Local servers take a command after --, remote ones take --transport http and a URL, and both land in ~/.copilot/mcp-config.json. A remote server that uses OAuth opens your browser to sign in, and /mcp auth <name> repeats that when a sign-in expires. Every MCP tool call then asks for your approval unless you allow it with --allow-tool.

If you have not installed the CLI yet, start with GitHub Copilot CLI: install, sign in and your first session. Everything below assumes copilot runs and you are signed in.

The servers that come built in

GitHub’s Copilot CLI command reference↗ (opens in a new tab) lists four built-in servers: github-mcp-server for issues, pull requests, labels, commits, code search and Actions, plus playwright for browser automation, fetch for HTTP requests and time. They show in copilot mcp list and /mcp beside the ones you add.

• The GitHub server starts with a default CLI subset of its tools. Add more for a session with --add-github-mcp-toolset or --add-github-mcp-tool (repeatable), or everything with --enable-all-github-mcp-tools.
• --disable-builtin-mcps turns all built-in servers off; --disable-mcp-server <name> turns off one server of any kind.
• Built-in servers are exempt from an enterprise allowlist, so they keep working when your own additions are blocked.

Adding a server: /mcp add or copilot mcp add

GitHub’s page on adding MCP servers to Copilot CLI↗ (opens in a new tab) gives two routes. Inside a session, /mcp add opens a form: a name, a type (Local/STDIO or HTTP/SSE), then the command and environment variables or the URL and headers, and finally which tools to enable, * for all. Save with Ctrl+S and the server is available at once, without a restart. From the shell, copilot mcp add does the same in one line:

# A local (stdio) server: the server's own command goes after --
copilot mcp add docs --env DOCS_API_KEY=YOUR_KEY -- npx -y @example/docs-mcp

# A remote server over streamable HTTP
copilot mcp add --transport http fenbs https://fenbs.ai/api/mcp

# A remote server with a fixed token instead of a sign-in
copilot mcp add --transport http --header "Authorization: Bearer YOUR_TOKEN" fenbs https://fenbs.ai/api/mcp

# Check what you have
copilot mcp list
copilot mcp get fenbs

--transport accepts stdio (the default), http and sse; SSE is the older transport and new servers use HTTP. --tools limits which tools are enabled (*, a comma-separated list, or "" for none), and --timeout sets how long tool discovery and tool calls may take, in milliseconds. copilot mcp disable and enable switch a server off and on without deleting it, and copilot mcp remove deletes a user-level server.

The config file

Servers you add are written to ~/.copilot/mcp-config.json, or under the folder COPILOT_HOME names if you set it. You can edit it by hand; servers sit under mcpServers:

{
  "mcpServers": {
    "docs": {
      "type": "local",
      "command": "npx",
      "args": ["-y", "@example/docs-mcp"],
      "env": { "DOCS_API_KEY": "${DOCS_API_KEY}" },
      "tools": ["*"]
    },
    "fenbs": {
      "type": "http",
      "url": "https://fenbs.ai/api/mcp",
      "tools": ["*"]
    }
  }
}

• The reference marks tools as required for both kinds: ["*"] for everything, or a list of names to expose only some.
• env and headers expand $VAR, ${VAR} and ${VAR:-default}, so a key can stay in your environment instead of the file.
• Project servers go in .mcp.json or .github/mcp.json in the repository. They are read from your working directory up to the Git root, take precedence over your user file when names clash, and load only once you have trusted the folder.
• A .vscode/mcp.json uses servers, not mcpServers. The reference gives a one-line migration: jq '{mcpServers: .servers}' .vscode/mcp.json > .mcp.json.
• For one session only, --additional-mcp-config takes a JSON string or @file and overrides a configured server of the same name.

OAuth and /mcp auth

A remote server that supports OAuth needs no token in the file. The first time the CLI connects it opens your browser, you sign in to that service and approve, and the CLI keeps the result. When a token expires or you need a different account, the server shows as needing authentication; run /mcp auth <name> to start a fresh sign-in, after which it reconnects on its own.

• On Windows, servers protected by Microsoft Entra ID sign in through the operating system’s broker, usually with no prompt. --device-code forces the device-code flow instead.
• For CI or cron with no browser, the reference describes a client_credentials grant: set oauthGrantType, a static oauthClientId and oauthPublicClient: false, with the client secret in the system keychain.
• If the service offers hand-issued tokens, an Authorization header works too, and the fix for an expired one is simply a new token.

Tool permissions

The reference is blunt: all MCP tool invocations require explicit permission, even read-only ones on external services. Each call prompts you to allow it once, for the session, or refuse. To stop the prompts, allow tools when you start. According to GitHub’s page on allowing and denying tool use↗ (opens in a new tab), an MCP rule is the server name, optionally with a tool in brackets:

# Every tool on one server
copilot --allow-tool='fenbs'

# Only the reading tools; anything else still asks
copilot --allow-tool='fenbs(fenbs_get_context), fenbs(fenbs_list_items), fenbs(fenbs_get_item)'

# Allow a server but never one tool on it
copilot --allow-tool='fenbs' --deny-tool='fenbs(fenbs_delete_item)'

Deny rules win over allow rules, over --allow-all and over approvals you saved with “don’t ask again”, which live in ~/.copilot/permissions-config.json for that repository. Command-line rules last for the session only. --available-tools and --excluded-tools work one layer earlier: they hide tools from the model altogether, so it does not even try them. The model sees MCP tools as the server name and tool name joined by a hyphen, capped at 64 characters, so a short server name helps.

Copilot CLI MCP not working: fixes by symptom

• A project server never appears. Project .mcp.json and .github/mcp.json servers are silently skipped in untrusted folders. Restart copilot in the folder and trust it. In copilot -p they load only if the folder is already trusted, or with GITHUB_COPILOT_PROMPT_MODE_WORKSPACE_MCP=true.
• You fixed the URL but the old one is still used. A project server shadows a user server of the same name. copilot mcp list groups servers by source; /mcp edit refuses a workspace server and names the file to edit instead.
• The server shows as needing authentication. Its sign-in expired or was revoked. Run /mcp auth <name>.
• “MCP server was blocked by your enterprise”. An allowlist is in force and this server is not on it. Ask an administrator; the CLI blocks non-default servers when it cannot reach the policy, too.
• A local server fails to start. Run its command yourself in a terminal. Only PATH is inherited from your shell; every other variable it needs, such as an API key, must be in the entry’s env. Its logs belong on stderr, because stdout is reserved for protocol messages.
• Tool calls time out. timeout covers tool discovery and tool calls and defaults to 30 seconds; raise it on the entry or with --timeout. slowConnectionThresholdMs only changes when the CLI warns that a connection is slow.
• Tools are missing. Check the tools field, then any --disable-mcp-server or copilot mcp disable you set earlier. /env lists what loaded in this session.

What an organisation controls

On Copilot Business or Enterprise, administrators decide whether the CLI can be used at all, and the “MCP servers in Copilot” policy decides whether MCP servers run in any Copilot client. GitHub’s overview of MCP server usage in your company↗ (opens in a new tab) recommends keeping MCP on and restricting it to an approved list, preferably through the enterprise’s managed settings file, which matches servers by name, URL or stdio command; a self-hosted registry is the weaker alternative. The CLI checks each non-default server against the policy before connecting and fails closed if it cannot reach it. If your servers vanish at work but not at home, that is the first thing to check.

Putting a task board behind the CLI

A board is one of the more useful servers to add, because a CLI session ends with a transcript and nothing anyone else can read. fenbs is a remote HTTP server with OAuth: copilot mcp add --transport http fenbs https://fenbs.ai/api/mcp, then sign in when asked, tick what the assistant may do (reading is always on; adding and changing tasks, and commenting, are your choice) and approve. The sign-in gives it an hour-long token that refreshes on its own. If someone revokes the connection under Settings, “Connect an AI assistant”, the server shows as needing authentication and /mcp auth fenbs signs in again. For a headless machine, issue a token there with a name, scopes and an optional expiry, and pass it with --header as above.

Allow the reading tools up front so the assistant can check the board without interrupting you, and leave writes on prompt until you trust what it reports. Every change it makes is recorded under its name and yours. The instruction that makes it use the board belongs in AGENTS.md; GitHub Copilot hooks can back that up with a reminder when it commits.