When integrating MCP servers with GitHub Copilot’s cloud agent, the agent goes from knowing only what’s in your repo to querying Azure resources, pulling live documentation, reading ADO work items, and searching the web. Here’s what’s in my config and what caught me out setting it up.
Why connecting MCP servers to GitHub Copilot?
Out of the box, Copilot cloud agent only knows what’s in your repository. Your codebase references Azure resources it can’t inspect, ADO work items it can’t read, and APIs whose specs aren’t checked in. MCP servers give it tools to call at runtime, it can query your actual resource configuration, look up current method signatures, and read your ADO backlog directly.
Copilot cloud agent runs in GitHub’s infrastructure, not on your machine. It chains tool calls and opens pull requests without you watching, which is why the tool allowlist matters more here than in VS Code.
Before you copy-paste: the GitHub Copilot MCP schema is not the same as VS Code or Claude Desktop
Every MCP config I found online was missing two fields that GitHub Copilot’s cloud agent requires on every server entry: type and tools. Without them you’ll get schema validation errors and nothing will start.
type is how the agent connects. Use “stdio” or “local” for npx-based servers, “http” or “sse” for remote endpoints.
tools is a required allowlist of the tool names the agent is allowed to call. You can set it to [“*”] for all tools, but the agent runs them autonomously without asking first, so it’s worth being deliberate about it.
Secrets must be stored in a repository environment called copilot and every secret name must start with COPILOT_MCP_. That prefix is enforced. Name a secret anything else and the variable substitution silently fails.
The config goes into Settings > Copilot > Cloud agent > MCP configuration in your repository. The official GitHub documentation has the full schema reference.
The 10 MCP servers I’m running and why
1. GitHub
The obvious one. Gives the agent read access to PRs, issues, and repo content beyond the current working directory. I use a fine-grained personal access token scoped to the repos I actually want it to touch, not a wide org-level token.
"github": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "$COPILOT_MCP_GITHUB_PAT"
},
"tools": [
"get_file_contents",
"search_repositories",
"create_issue",
"list_issues",
"create_pull_request",
"get_pull_request"
]
}2. Azure
Microsoft’s official Azure MCP server. Lets the agent query your actual Azure resources: subscriptions, resource groups, storage accounts, and more. I use [“*”] here because the tool list changes as Microsoft adds coverage, and it’s read-heavy in practice.
"azure": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@azure/mcp@latest", "server", "start"],
"tools": ["*"]
}3. Azure DevOps
Work items, pipelines, boards. I scope the tools to what the agent actually needs rather than opening everything. I don’t want it triggering pipeline runs on its own.
This one requires OIDC setup in an Entra application and an Azure login step in your copilot-setup-steps.yml workflow. Without it the server starts but auth fails silently. Full setup in GitHub’s ADO example.
"azure-devops": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@azure-devops/mcp", "<your-ado-organization>", "-a", "azcli"],
"tools": [
"wit_get_work_item",
"wit_get_work_items_batch_by_ids",
"wit_create_work_item",
"wit_update_work_item",
"pipelines_list",
"pipelines_run"
]
}4. Microsoft Learn
A remote HTTP server that gives the agent live access to Microsoft Docs — no npx needed. When I’m working on Logic Apps, APIM, or Bicep, the agent looks up current API shapes and CLI syntax at query time instead of relying on training data. Probably the most useful server on this list for Azure practitioners.
"microsoft-learn": {
"type": "http",
"url": "https://learn.microsoft.com/api/mcp",
"tools": [
"microsoft_docs_search",
"microsoft_docs_fetch",
"microsoft_code_sample_search"
]
}5. Context7
Pulls up-to-date library and SDK documentation at query time. Stops the agent from hallucinating method signatures that existed two major versions ago. I use it alongside Microsoft Learn: one for official Azure docs, this one for everything else.
"context7": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@upstash/context7-mcp"],
"tools": ["resolve-library-id", "get-library-docs"]
}6. Fetch
Lets the agent pull any URL into context: OpenAPI specs, REST API responses, third-party docs not indexed anywhere else. Simple, but I use it more than I expected.
"fetch": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-fetch"],
"tools": ["fetch"]
}7. Brave Search
Live web search from inside the agent. Good when docs are thin or an SDK has changed since the training cutoff. Requires a Brave Search API key.
"brave-search": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-brave-search"],
"env": {
"BRAVE_API_KEY": "$COPILOT_MCP_BRAVE_API_KEY"
},
"tools": ["brave_web_search", "brave_local_search"]
}8. Playwright
Browser automation. The agent can navigate, screenshot, click, and type. I use this for E2E test generation and for scraping rendered output that isn’t available from a raw API or static HTML. It’s the most powerful tool on this list and the one I’d think hardest about before wildcarding.
"playwright": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"],
"tools": [
"browser_navigate",
"browser_screenshot",
"browser_click",
"browser_type"
]
}9. Sequential thinking
Forces the agent to reason through a problem step by step before acting. On complex architectural tasks or multi-file changes this makes a real difference to output quality. No config, no secrets. Just add it.
"sequential-thinking": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-sequential-thinking"],
"tools": ["sequentialthinking"]
}10. Memory
Persistent knowledge graph across sessions. Useful when you want the agent to remember decisions, ADRs, or context that doesn’t live in the codebase. Still experimenting with this one, but it’s already earning its place on longer-running tasks.
"memory": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-memory"],
"tools": [
"create_entities",
"search_nodes",
"open_nodes",
"add_observations"
]
}The full config in one block
{
"mcpServers": {
"github": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "$COPILOT_MCP_GITHUB_PAT"
},
"tools": [
"get_file_contents",
"search_repositories",
"create_issue",
"list_issues",
"create_pull_request",
"get_pull_request"
]
},
"azure": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@azure/mcp@latest", "server", "start"],
"tools": ["*"]
},
"azure-devops": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@azure-devops/mcp", "<your-ado-organization>", "-a", "azcli"],
"tools": [
"wit_get_work_item",
"wit_get_work_items_batch_by_ids",
"wit_create_work_item",
"wit_update_work_item",
"pipelines_list",
"pipelines_run"
]
},
"microsoft-learn": {
"type": "http",
"url": "https://learn.microsoft.com/api/mcp",
"tools": [
"microsoft_docs_search",
"microsoft_docs_fetch",
"microsoft_code_sample_search"
]
},
"context7": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@upstash/context7-mcp"],
"tools": ["resolve-library-id", "get-library-docs"]
},
"fetch": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-fetch"],
"tools": ["fetch"]
},
"brave-search": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-brave-search"],
"env": {
"BRAVE_API_KEY": "$COPILOT_MCP_BRAVE_API_KEY"
},
"tools": ["brave_web_search", "brave_local_search"]
},
"playwright": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"],
"tools": [
"browser_navigate",
"browser_screenshot",
"browser_click",
"browser_type"
]
},
"sequential-thinking": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-sequential-thinking"],
"tools": ["sequentialthinking"]
},
"memory": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-memory"],
"tools": [
"create_entities",
"search_nodes",
"open_nodes",
"add_observations"
]
}
}
}
How to verify everything is actually working
Assign a test GitHub issue to Copilot and wait for it to open a pull request. Open the session, find the Start MCP Servers step, and check that each server appears with its tools listed. If tools are missing, the server failed to start — usually a misnamed secret. The COPILOT_MCP_ prefix is easy to forget.