How to Add a Remote MCP Server to GitHub Copilot CLI

How do I add a remote MCP server to GitHub Copilot CLI?

From an active Copilot CLI session, run:

/mcp add

Follow the prompts: give the server a name, choose HTTP/SSE as the type (as opposed to Local/STDIO for a command-based server), paste the URL, and add any HTTP headers the server needs — commonly an Authorization: Bearer token — as JSON. Enter * for all tools, or a comma-separated list to limit which tools Copilot can call. Press Ctrl+S to save; the server starts immediately, no restart needed.

Configuring by file instead

Copilot CLI keeps its user-level server list in ~/.copilot/mcp-config.json (the location changes if you set the COPILOT_HOME environment variable). For a remote server, the shape is:

{
  "mcpServers": {
    "my-server": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${MY_SERVER_TOKEN}"
      },
      "tools": ["*"]
    }
  }
}

"type": "http" is required — it tells Copilot CLI this is a remote server rather than a local command. Copilot CLI also accepts "type": "sse" for servers that use the older SSE transport. headers is where authentication goes for a remote server: a static token, not an interactive login. tools is an allow-list — ["*"] grants every tool the server exposes; a specific list restricts Copilot to just those tools.

A local (STDIO) server entry looks different — "type": "local" with command, args, and env in place of url and headers — but that's out of scope here since this guide covers remote servers only.

Project-level configuration

Copilot CLI also reads MCP servers from a project-scoped file, checked in two places in this order of precedence:

• .mcp.json in the repository root (or a subdirectory) — takes precedence
• .github/mcp.json — the more commonly documented, committed location for a team-shared config

Both accept either the same mcpServers-wrapped shape as the user-level file, or bare server-name keys at the top level. A config closer to your working directory overrides one further away, and project-level entries override ~/.copilot/mcp-config.json when names collide.

Project-level servers only load after you trust the folder. The first time you launch Copilot CLI in a new directory, it asks you to confirm you trust it; until you do, any .mcp.json or .github/mcp.json servers are skipped silently, with no error. If a project-level server never appears, check folder trust before anything else.

Authentication

A server that uses a static token authenticates through the headers field, for example an Authorization: Bearer <token> header, with the token itself kept in an environment variable rather than typed directly into the config file:

export MY_SERVER_TOKEN=your_token_here

"headers": { "Authorization": "Bearer ${MY_SERVER_TOKEN}" }

Headers are the only method GitHub's Copilot CLI setup page documents. OAuth is also supported in current builds, per the CLI's release notes: v1.0.83 (September 4, 2026) added Client ID Metadata Document support for MCP OAuth sign-in, v1.0.85 made OAuth-authenticated servers connect reliably at session startup, and v1.0.89 made pre-registered OAuth clients honor configured oauthScopes. If a server uses OAuth, run a current CLI and leave headers out.

Managing servers with /mcp

Inside a Copilot CLI session:

Command	Does
/mcp or /mcp list	List configured servers
/mcp show <name>	Show a server's status and the tools it exposes
/mcp edit <name>	Edit a server's configuration
/mcp disable <name> / /mcp enable <name>	Turn a server off or on without deleting it
/mcp delete <name>	Remove a server

The same actions are available outside an interactive session via copilot mcp list, copilot mcp get, copilot mcp remove, copilot mcp disable, and copilot mcp enable, each of which accepts a --json flag for scripting.

The built-in GitHub MCP server

Copilot CLI ships with the GitHub MCP server already configured — you don't need to add it. It gives Copilot CLI direct access to GitHub.com resources (issues, pull requests, and more) without any setup. If you want to point Copilot CLI at a different GitHub MCP server configuration (for example, a different toolset or read-only mode), you can add a new entry under a different name to run alongside the built-in one, or reuse the name github-mcp-server to replace it.

Org policy on Business and Enterprise

On a Copilot Business or Copilot Enterprise seat, an organization or enterprise admin controls MCP access through the "MCP servers in Copilot" policy, and GitHub documents it as disabled by default. Where this policy governs IDE/Chat access most visibly, GitHub's Copilot CLI documentation notes that an org's configured registries and allow-lists apply to CLI usage too — so on a managed Business/Enterprise account, an admin may need to enable MCP access, and only allow-listed servers may be usable, before /mcp add will work as described here. Free, Pro, and Pro+ personal accounts are not gated by this policy.

Verifying

Run /mcp show <name> and confirm the server shows as connected with its tools listed. You can also just ask Copilot CLI something that would require the new server's tools and see whether it reaches for them.

What usually goes wrong

Problem	Fix
Server added but nothing happens	Confirm "type": "http" is present and the URL is correct; run /mcp show <name> to check its status
Project-level server (.mcp.json / .github/mcp.json) never appears	Folder trust hasn't been confirmed yet for that directory — relaunch Copilot CLI there and accept the trust prompt
Server works in one repo but not others	It's defined in that repo's .mcp.json or .github/mcp.json, which is project-scoped. Add it to ~/.copilot/mcp-config.json instead for it to follow you everywhere
Auth fails immediately	For a header, check the environment variable is set and the token hasn't expired. For an OAuth server, update Copilot CLI (OAuth fixes shipped through v1.0.85–v1.0.89) and retry
Tools from the server aren't available to Copilot	Check the tools allow-list in the config — a tool not listed there is silently unavailable even though the server is connected
/mcp add doesn't seem to save	Press Ctrl+S in the form; the server starts immediately once saved
Nothing works and you're on a Business/Enterprise seat	Ask your org admin whether the "MCP servers in Copilot" policy is enabled — it ships off by default

How this differs from VS Code and Copilot's cloud coding agent

Copilot CLI, VS Code's Copilot Chat, and Copilot's cloud-hosted coding agent are three separate MCP clients, each with its own configuration and its own authentication rules:

• VS Code reads .vscode/mcp.json with a servers root key (not mcpServers) and supports OAuth for remote servers — see the VS Code guide for the full walkthrough.
• Copilot CLI, covered here, uses mcpServers in ~/.copilot/mcp-config.json, supports headers and (in current releases) OAuth, and also reads project-level config files.

Mixing these up — adding a server to the wrong surface's config file — is a common reason a server "isn't working" when it's actually just not configured for the client you're using.

A worked example

With a real server — Tempreon, a hosted MCP server that gives your coding sessions a persistent memory of your architecture decisions and conventions — adding it to Copilot CLI by hand would look like:

{
  "mcpServers": {
    "tempreon": {
      "type": "http",
      "url": "https://api.tempreon.com/functions/v1/tempreon-mcp/mcp",
      "tools": ["*"]
    }
  }
}

Tempreon signs in with OAuth, so there's no header to add; a current Copilot CLI handles the sign-in. This is an example of the config shape, not a tested integration.