Add a Remote MCP Server to GitHub Copilot CLI: /mcp add and Fixes
How to add a remote MCP server to GitHub Copilot CLI with /mcp add or mcp-config.json, keep its token out of the file, sign in with /mcp auth, allow its tools, and fix one that will not connect.
Inside Copilot CLI, type /mcp add. A form opens: give the server a name, press the number for HTTP, paste the server's URL, leave Tools at *, and press Ctrl+S. The server is available straight away, without a restart [1].
From your shell, the same thing is one command [1]:
copilot mcp add --transport http my-server https://mcp.example.com/mcp
Either way it lands in ~/.copilot/mcp-config.json [2]. /mcp show my-server confirms it connected and lists its tools [1].
Everything below is checked against GitHub's Copilot CLI documentation on 14 October 2026 [1][2][3].
TL;DR:
- Choose HTTP, not SSE. HTTP is Streamable HTTP; SSE is the deprecated transport [1].
--transport httpon the command line. The default isstdio, which treats your URL as a program to run [2]./mcp auth my-serveropens the browser sign-in again when a token expires [2].- Every MCP tool call asks first, read-only ones included.
--allow-tool='my-server'approves a server's tools [2].
Add the server
With /mcp add
The form has five fields; Tab moves between them [1]:
| Field | What to put |
|---|---|
| Server Name | A unique name. It becomes the prefix of every tool, so keep it short |
| Server Type | HTTP for a current server; SSE only for an old one |
| URL | The MCP endpoint itself, usually ending in /mcp |
| HTTP Headers | Optional JSON, such as {"Authorization": "Bearer ..."} |
| Tools | * for all, or a comma-separated list of tool names |
With copilot mcp add
From the shell, --header adds one header per flag [1]:
copilot mcp add --transport http \
--header "Authorization: Bearer $MY_SERVER_TOKEN" \
my-server https://mcp.example.com/mcp
copilot mcp list shows what is configured, and copilot mcp remove my-server deletes one [2].
In mcp-config.json
The file is ~/.copilot/mcp-config.json, or under COPILOT_HOME if you set it [3]. A remote entry needs a type, a url and a tools list [2]:
{
"mcpServers": {
"my-server": {
"type": "http",
"url": "https://mcp.example.com/mcp",
"headers": {
"Authorization": "Bearer ${MY_SERVER_TOKEN}"
},
"tools": ["*"]
}
}
}
type takes http, sse or local; streamable-http is accepted and treated as http [2]. headers supports variable expansion, so ${MY_SERVER_TOKEN} is read from your environment and the token stays out of the file [2].
VS Code's documentation names this same file for servers you want in every workspace, so a server added here can show up there too (VS Code guide). The reverse is not true: Copilot CLI does not read .vscode/mcp.json, which uses a different top-level key, servers [1]. GitHub gives a one-line conversion [2]:
jq '{mcpServers: .servers}' .vscode/mcp.json > .mcp.json
For one project
Copilot CLI also reads .mcp.json from any folder between your working directory and the repository root, and .github/mcp.json. Those win over the user file, and load only after you trust the folder [1].
Sign in to a server that needs it
Copilot CLI signs in with OAuth on its own: by default it registers itself with the server and opens your browser [2]. When a token expires, the server shows needs-auth; /mcp auth my-server starts a fresh sign-in [2].
Self-registration is what nearly every guarded server expects. We read the authorization metadata of 169 servers that ask for credentials, from our registry census on 9 October 2026: 162 offered Dynamic Client Registration [4]. For one that does not, register an app with the provider and set oauthClientId on the entry, which skips registration [2].
For a machine with no browser, an entry can use "oauthGrantType": "client_credentials" with a client secret, and Copilot CLI skips the browser entirely [2].
Allow its tools
Every MCP tool call asks for permission, even one that only reads [2]. To approve in advance, name the server, or one tool on it [2]:
copilot --allow-tool='my-server'
copilot --allow-tool='my-server(create_issue)'
--deny-tool takes the same patterns and always wins over an allow [2]. Approve a whole server only after you have vetted it, and check its tool list for anything that writes or deletes.
Copilot CLI ships with GitHub's own MCP server already set up [1]. --disable-builtin-mcps turns it off, and --disable-mcp-server=my-server turns one of yours off for a session [2].
When it will not connect
GitHub has no troubleshooting page for MCP in the CLI, so these come from its reference and from what each setting does [2].
| What you see | Usual cause | Fix |
|---|---|---|
| The server tries to start as a program | Added without --transport http |
Remove it and add it again with --transport http |
| A known-good server fails | Saved as SSE | Change type to http |
needs-auth |
Token expired, or another account needed | /mcp auth my-server |
401 with a header set |
The variable is unset where copilot starts |
Export it in that shell |
Your .vscode/mcp.json servers are missing |
Copilot CLI does not read that file | Convert it with the jq line above |
A project's .mcp.json is ignored |
The folder is not trusted yet | Accept the trust prompt |
| "was blocked by your enterprise" | Your organisation's allow list | Ask your admin |
| Slow to connect | A slow first answer | Raise timeout (milliseconds) on the entry |
/env shows which MCP servers loaded, and /mcp show my-server shows one server's status and tools [2]. MCP server errors covers what a 406, a CORS failure or a -32601 means on the server's side.
Check it from outside before you share it
Our MCP connection test calls your server from our network, runs the handshake and tools/list, and reports what a stranger on the internet gets back, with a dated URL you can share. If it passes there and fails in Copilot CLI, the problem is in your config, not the server.
The same setup in other clients is in VS Code, Claude Code, Codex, Gemini CLI, Cline, Cursor, Claude Desktop and ChatGPT, and remote MCP server vs stdio covers whether your server should have a public address at all.