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

A form opens; use Tab to move between fields. Give the server a name, choose HTTP as the server type (SSE is also offered for servers still on the legacy transport, and Local / STDIO are for command-based servers), paste the URL, and add any HTTP headers the server needs, commonly an Authorization: Bearer token, as JSON. Enter * for all tools (the default), or a comma-separated list to limit which tools Copilot can call. Press Ctrl+S to save; the server starts immediately, no restart needed.

The same thing from a plain shell, without entering a session:

copilot mcp add --transport http my-server https://mcp.example.com/mcp

Add --header "Authorization: Bearer YOUR-TOKEN" (repeatable) for a static token, --tools to restrict the tool list, and --timeout MS if the server is slow to start. --transport defaults to stdio, so always pass http (or sse) for a remote server. Either way the entry lands in ~/.copilot/mcp-config.json.

Configuring by file instead

Copilot CLI keeps its user-level server list in ~/.copilot/mcp-config.json (under $COPILOT_HOME instead, if you set that 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": ["*"]
    }
  }
}

Set "type": "http". Every example GitHub publishes includes it, and it is what tells Copilot CLI this is a Streamable HTTP server rather than a local command ("type": "local") or a legacy "type": "sse" server. headers is where a static token goes. 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 project-scoped files. When you start it inside a Git repository, it walks from your working directory up to the repository root and loads these along the way:

• .mcp.json in any directory on that path, commonly the project root. GitHub recommends it for local or per-checkout configuration.
• .github/mcp.json, the committed, team-shared location.

Both accept either the same mcpServers-wrapped shape as the user-level file, or bare server-name keys at the top level. If both files exist in the same directory, .mcp.json wins. When names collide, a file closer to your working directory overrides one further away, and project-level entries override ~/.copilot/mcp-config.json. GitHub rates repository and workspace servers as medium trust (review recommended) and remote servers as low trust (always review).

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. In prompt mode (copilot -p) an untrusted directory's project servers are skipped too, unless you set GITHUB_COPILOT_PROMPT_MODE_WORKSPACE_MCP=true. 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 shows, but OAuth is supported and documented elsewhere in GitHub's docs: the command reference says a remote OAuth server shows a needs-auth status when its token expires or a different account is needed, and /mcp auth opens a browser sign-in and reconnects the server. The CLI's changelog fills in the timeline: a browser callback sign-in flow for MCP servers in v1.0.69 (July 7, 2026), automatic reconnection after a mid-session token expiry in v1.0.66 (a 401 during a tool call triggers a silent reconnect, and servers that need an interactive sign-in are retried at the start of the next turn), Client ID Metadata Document support in v1.0.83 (September 4, 2026), and pre-registered OAuth clients honoring configured oauthScopes in v1.0.89. If a server uses OAuth, run a current CLI, leave headers out, and complete the sign-in when the CLI prompts (or run /mcp auth yourself).

Managing servers with /mcp

Inside a Copilot CLI session:

Command	Does
/mcp or /mcp list	Open the dashboard of configured servers, or print the same list as text
/mcp show <name>	Show a server's status and the tools it exposes
/mcp edit <name>	Edit a server's configuration
/mcp auth	Re-run the OAuth sign-in for a remote server that shows needs-auth
/mcp disable <name> / /mcp enable <name>	Turn a server off or on without deleting it; persists across sessions
/mcp delete <name>	Remove a server

The same actions are available outside an interactive session via copilot mcp list, copilot mcp get, copilot mcp add, copilot mcp remove, copilot mcp disable, and copilot mcp enable; list and get accept --json for scripting. remove only works on user-level servers; workspace servers are edited in their files.

The /mcp dashboard also has a Connectors view (GitHub labels connectors public preview): pick a service, select Connect, and GitHub handles that server's configuration and sign-in for you across Copilot surfaces. If your organization provides your seat, an admin may need to allow connectors first.

The built-in GitHub MCP server

Copilot CLI ships with the GitHub MCP server already configured; you don't need to add it, and GitHub documents that built-in servers are exempt from enterprise allowlist enforcement. The github-mcp-server install guide notes that read-only tools are enabled by default, that /mcp show github-mcp-server displays it, and that if you want a different configuration (another toolset, for example) you can name your own entry github-mcp-server to replace the built-in one or use a different name to run alongside it.

Plans and org policy

GitHub documents Copilot CLI as available with all Copilot plans, and it has been generally available since February 25, 2026. If you receive Copilot from an organization or enterprise, the Copilot CLI policy has to be enabled in that organization's settings before the CLI itself will work.

MCP inside the CLI is governed a little differently from Copilot in the IDE. GitHub's Copilot CLI page lists two organization-level MCP policies the CLI "can't currently support": MCP servers in Copilot (the on/off switch for MCP across Copilot clients) and MCP Registry URL. What does apply to the CLI, per GitHub's setup page and command reference, is an enterprise allowlist of permitted MCP servers: when one is active, the CLI evaluates each non-default server against it before connecting and reports a blocked server by name. So on a managed Business or Enterprise seat, if a server you added shows as blocked, ask your admin to add it to the allowlist; the built-in GitHub server is always exempt. GitHub's pages differ on whether a configured registry URL applies to the CLI, so treat that as an open question.

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 (or set GITHUB_COPILOT_PROMPT_MODE_WORKSPACE_MCP=true for prompt mode)
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, then run /mcp auth if the server shows needs-auth
Tools from the server aren't available to Copilot	Check the tools allow-list in the config; a tool not listed there is 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
A server shows as blocked on a Business/Enterprise seat	Your enterprise enforces an MCP allowlist; ask the admin to add the server. If the CLI itself won't start, ask whether the Copilot CLI policy is enabled

How this differs from VS Code

Copilot CLI and VS Code's Copilot Chat are separate MCP clients, each with its own configuration and its own authentication rules:

• VS Code reads .vscode/mcp.json with the root key servers; Copilot CLI does not read that file. GitHub documents a one-line migration, jq '{mcpServers: .servers}' .vscode/mcp.json > .mcp.json, that remaps the key. Newer VS Code builds can also write the portable .mcp.json and the ~/.copilot/mcp-config.json file Copilot CLI uses (root key mcpServers). VS Code runs browser OAuth for remote servers, including in the default Copilot harness; see the VS Code guide for the full walkthrough.
• Copilot CLI, covered here, uses mcpServers in ~/.copilot/mcp-config.json, supports headers and OAuth, and also reads project-level .mcp.json / .github/mcp.json 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, and /mcp auth re-runs it if the token expires. This is an example of the config shape, not a tested integration.