GitHub shipped verified MCP connectors to Copilot last week — 26 services, one sign-in, and the connection follows you across every surface you use: the Copilot app, CLI, VS Code, cloud sessions, and GitHub Mobile. If you have been manually editing config JSON files for each Copilot client, that work is now optional.
What Changed
Until now, connecting a service like Sentry or Slack to Copilot meant finding the right MCP server URL, crafting a config file, managing separate credentials per surface, and re-authenticating whenever a session dropped. The process worked, technically, but it was tedious enough that most developers skipped it. Community threads made the frustration clear: “The difference comparing with Claude Code is massive — Claude Code allows connecting services in a couple of clicks.”
GitHub’s answer is verified connectors: pre-configured, GitHub-vetted MCP servers that require a single sign-in. Connect once in any Copilot surface, and GitHub handles the rest — server config, authentication, and cross-surface persistence.
What’s in the Box
At launch, 26 services are available. The confirmed named ones cover the core developer stack:
- Communication: Slack
- Design: Figma
- Productivity: Notion, Atlassian Rovo
- Error monitoring: Sentry
- Project management: Linear
- Cloud/deployment: Cloudflare, Vercel, Work IQ
The connection works across the GitHub Copilot app, Copilot CLI, VS Code, Copilot in the cloud, and GitHub Mobile. Sign in once — Copilot keeps you signed in in the background across all five.
How to Enable GitHub Copilot MCP Connectors
Individual developers on any Copilot plan can try this now.
Via Copilot CLI:
Run /mcp in Copilot CLI
→ Switch to the Connectors tab
→ Select Connect on the service you want
→ Sign in once — doneVia github.com: Navigate to your Copilot customization page, browse the available services, and click Connect.
For teams on Copilot Business or Copilot Enterprise, an admin needs to do four things first:
- Enable the Editor preview features policy (connectors are in public preview)
- Enable the MCP servers in Copilot policy
- Set MCP access restrictions to Allow all — the “Registry only” setting blocks connectors
- If your enterprise uses an MCP allowlist in managed settings, add each connector’s URL or a matching wildcard
Why GitHub Is Doing This
The connectors did not ship in isolation. At GitHub Universe 2026 on October 28, GitHub also launched Copilot Projects (agentic work across multiple repos in parallel managed sessions), Agent Merge (handles failing CI and merge conflicts autonomously), and Shared Automations. GitHub’s stated position: Copilot is no longer a coding assistant — it is “the engine of a complete software delivery system.”
That framing only holds if the agent has context. Code context lives in your repos. Operational context lives in Sentry, Linear, Figma, and Slack. The MCP connectors are what bridge the two. Without them, the agent-first vision is a demo that falls apart the moment the agent needs to know why a sprint ticket was deprioritized or what error is trending in production.
The Security Caveat
Enterprise teams should go in with eyes open. Connectors currently inherit the full permissions of the authenticating user — broader than any single agent task needs. Control is global: enable or disable all MCP, not individual services. And Copilot CLI currently ignores the org-wide MCP disable policy, a gap worth flagging to your security team before rollout. Scalekit has a detailed breakdown of the governance gaps if you need something to bring to that conversation.
None of this is unique to GitHub — it is an industry-wide MCP governance problem. GitHub is ahead of some competitors simply by offering verified rather than arbitrary servers, but per-service controls and audit trails are not there yet.
Bottom Line
The verified connector model is the right call. The alternative — expecting developers to maintain MCP config files across five surfaces — was always going to have poor adoption. For individual developers, this is worth enabling today. For enterprise teams, do the admin policy work first, have a conversation with your security team about the permission scope, and then enable it. The convenience is real, and the governance gaps are not reasons to skip it.
