If your roadmap still includes Copilot Extensions, you’re out of runway. As of November 10, 2025, GitHub has sunset the GitHub App–based Copilot Extensions in favor of Model Context Protocol (MCP) servers. That’s the hard stop. If you do nothing, Copilot Chat flows that depended on @mentions of those Extensions will simply stop working. (github.blog)
What exactly changed on November 10?
Three dates matter. September 24, 2025 blocked the creation of new server‑side Copilot Extensions. November 3–7 was a brownout window to surface breakages. November 10 is the full shutdown of those Extensions. Existing VS Code Copilot extensions and standard GitHub Apps are unaffected—this cut is specifically about Copilot Extensions implemented as GitHub Apps. (github.blog)
MCP is now the path for tool integrations. Practically, you’ll expose capabilities via an MCP server, and compatible hosts (GitHub Copilot in IDEs, Claude Code, and others) can discover and call those tools with consistent semantics. (docs.anthropic.com)
Why GitHub is moving from Extensions to MCP
Extensions locked your work into one assistant. MCP standardizes how assistants talk to tools and data, so you build once and reuse across multiple hosts. Organizations get portable integrations, better admin controls, and a clearer way to govern what tools an agent can run. GitHub cites modularity, cross‑platform reach, and smoother autonomous tool‑calling as reasons for the shift. (github.blog)
Here’s the thing: portability shifts the center of gravity from the assistant to your tool surface. That’s a net win for most teams—and for security, because you can centralize policy, discovery, and audit at the server and registry layers. (docs.github.com)
Copilot Extensions deprecation: what breaks if you wait?
Anything wired to @mention a retired Copilot Extension stops resolving; the call becomes plain text in chat. Marketplace listings for Extension‑only apps are removed; hybrid GitHub Apps can remain listed if you disabled the Extension configuration before the cutoff. Private/internal Extensions go dark on the same schedule. (github.blog)
MCP migration checklist you can run today
Use this pragmatic flow when the clock has already hit zero:
1) Inventory the dependency surface
Scan your repos and docs for @mentions and saved chat prompts that referenced Copilot Extensions. Flag critical flows (release steps, on‑call playbooks, incident bots). Communicate the expected impact window to teams and stakeholders.
2) Define an MVP MCP server
Pick the smallest set of high‑value tools to port first—ideally stateless, idempotent actions (fetch a dashboard, open a ticket, generate a PR). Model each as an MCP tool with explicit input schemas, safe defaults, and thin business logic glued to your underlying APIs. (docs.anthropic.com)
3) Decide remote vs local server
Remote (hosted) MCP servers give easier rollout, centralized logging, and consistent updates. Local servers are useful for sensitive workflows or air‑gapped experiments. GitHub documents both approaches for its own GitHub MCP server, and the same tradeoffs apply to yours. (docs.github.com)
4) Stand up a registry and policy
In Copilot Enterprise settings, enable MCP servers, set an MCP Registry URL, and choose whether to restrict to registry‑listed servers only. Start permissive (Allow all) while you migrate, then tighten to Registry only after you’re confident the catalog is accurate. (docs.github.com)
5) Wire up a first‑party server
For GitHub‑centric automation, the official GitHub MCP server is a fast on‑ramp. You can run it remotely via the MCP Servers marketplace in VS Code or configure it manually in other IDEs. Use it to bootstrap PR creation, issue triage, and repo search. (docs.github.com)
6) Ship a thin vertical slice
Expose one or two tools end‑to‑end, add guardrails, and publish them in your registry. Socialize “how to call” snippets team‑wide. Specifically test Agent Mode and autonomous tool‑invocation paths, because those execution graphs differ from chat‑only flows. (github.blog)
7) Close the loop with governance
Enable organization‑level allowlist controls, document the approval path for new servers, and define a roll‑back plan per server (disable via registry; remove from policy). Capture SLOs for latency and success rate. (docs.github.com)
People also ask: Do VS Code “Copilot extensions” still work?
Yes—the client‑side VS Code add‑ons aren’t part of this sunset. The deprecation applies to the server‑side Copilot Extensions built as GitHub Apps. If you saw @mentions resolving to bot behaviors, those are the ones that stopped. (github.blog)
People also ask: Is there feature parity between Extensions and MCP?
You can reproduce most of the same capabilities with MCP tools, but the architecture is different. Expect to re‑model capabilities as discrete tools with clear inputs/outputs and to rely more on agent‑driven tool calls (rather than chat commands). Several hosts—including Claude Code—already speak MCP. (github.blog)
Security and compliance: registries, allowlists, and reality
MCP’s enterprise controls are solidifying, but they’re not magic. A registry URL lets you present a curated catalog in supported IDEs and optionally restrict agents to only those servers. Today, “Registry only” enforcement is name/ID‑based and can be bypassed by editing local config files, so combine it with user training and periodic audits. (docs.github.com)
Practically, start with Allow all plus telemetry. Track which servers teams actually use, then move to Registry only and lock the catalog. For higher assurance, keep especially sensitive actions behind remote servers with auth and audit, and disable local variants entirely.
Operational gotchas we’ve seen in real rollouts
Token scope drift: it’s easy to over‑grant when you’re under the gun. Scope GitHub and cloud tokens per tool and environment, and prefer short‑lived credentials with OIDC where hosts support it. If you’re juggling npm changes at the same time (classic tokens fully revoked November 19), plan a single secrets refactor. (github.blog)
IDE variance: MCP UIs differ across VS Code, JetBrains, Xcode, and Eclipse. Some features (like registry browsing) sit behind pre‑release builds today, so bake that into your pilot plan. (docs.github.com)
Server placement: remote servers simplify fleet management; local servers reduce blast radius and can isolate data paths. Many teams land on a hybrid: remote for “read” tools, local for “write” tools that touch sensitive systems. (docs.github.com)
Designing good MCP tools: a quick rubric
Be explicit. Define JSON schemas for inputs with tight validation and sensible defaults. Make tools idempotent when possible. Split risky actions (e.g., “merge to main”) into propose and apply variants, and require explicit human confirmation on apply. Return compact, structured results with links to artifacts instead of wall‑of‑text logs. (docs.anthropic.com)
Make failure modes boring. Time out fast on network calls. Backoff and retry on 5xx. Emit metrics for duration, errors, and tool success rate. Log full request/response envelopes for secure servers, and scrub tokens at source.
How to explain this to your CFO
Extensions to MCP isn’t a vanity rewrite. It reduces integration TCO by making your tools portable across multiple assistants and IDEs, it improves control surfaces for compliance, and it consolidates telemetry. If your teams already use Copilot and Claude Code, the reuse alone pays back the migration.
Reference timeline you can actually hit this week
Day 0 (today): Flip a banner in chat and docs announcing the Copilot Extensions deprecation. Enable MCP servers in enterprise settings and attach a registry URL. (docs.github.com)
Day 1–2: Stand up one remote MCP server with two tools: “open‑ticket” and “create‑draft‑pr.” Publish to registry; keep Allow all policy while you test. (docs.github.com)
Day 3–4: Add observability (request count, error rate, latency). Gate keepers in security review scopes and logs. Socialize usage snippets to dev channels. (docs.github.com)
Day 5+: Move to Registry only, add a change‑request process for new tools, and schedule quarterly audits. Tie MCP server releases to your regular change calendar. (docs.github.com)
“Will our Marketplace listing disappear?”
If your app was Extension‑only, yes—it’s removed after November 10. Hybrid GitHub Apps can remain listed, provided you disabled the Extension configuration before the deadline. Users who @mention the retired Extension will just see plain text. (github.blog)
What about model changes inside Copilot itself?
Separate from today’s change, Copilot has been pruning older AI models and prioritizing newer families. Keep an eye on your enterprise model policy so your agents call the models you intend. The point: move your integration layer to MCP now, then tune models safely behind policy later. (itpro.com)
Let’s get practical: a minimal MCP server blueprint
Here’s a thin slice we’ve shipped in similar migrations:
- Server: a stateless Node or Python process exposing three tools—get‑runbook, create‑draft‑pr, and open‑ticket.
- Auth: OIDC for GitHub calls where possible; short‑lived PAT fallback scoped to a service account.
- Policy: published in a private MCP registry; allowlist at the org level set to Registry only after soak. (docs.github.com)
- UX: document “#create‑draft‑pr {repo, title, problem_statement}” snippets and include examples for Agent Mode. (github.blog)
Related playbooks if you’re juggling multiple changes
If you’re also racing the npm token deadlines this month, use our step‑by‑step cutover to avoid CI outages: see this Nov 19 npm token migration playbook. For broader platform changes hitting CI/CD at scale, our take on GitHub Actions changes in November 2025 will help you avoid quota and concurrency surprises. And if you want a deeper, tactical walkthrough for MCP, read our MCP migration plan next.
If you’re planning a wider modernization—security baselines, IDE standardization, supply chain hardening—talk with our team about an accelerated assessment and pilot build. Our services page breaks down typical engagement patterns and pricing bands.
FAQ: What does day‑to‑day look like after MCP?
How do developers discover tools?
In supported IDEs, the MCP catalog appears inside Copilot Chat with your registry’s servers; developers can install or enable servers from that list. JetBrains, Xcode, and Eclipse support is rolling out via pre‑release builds; VS Code has an MCP Servers marketplace path. (docs.github.com)
Can we use a cloud API catalog as our registry?
Yes. Enterprises can wire Azure API Center as a managed MCP registry with governance and discovery. Paste its URL in GitHub’s enterprise or org settings to bind it. (docs.github.com)
Will non‑Copilot hosts see our tools?
That’s the point of MCP. Hosts like Claude Code can connect to your servers now, and more environments are adding native MCP support, including Windows platform integrations. Govern discovery with your registry and keep auth at the server boundary. (docs.anthropic.com)
What to do next (today)
- Post a notice in engineering channels that Copilot Extensions are off and MCP is the replacement path. Link your internal registry and first server’s “Getting Started.” (github.blog)
- Enable MCP servers in enterprise/org settings, add your registry URL, and keep Allow all for 48 hours. (docs.github.com)
- Publish one minimal MCP server with two high‑impact tools; test in VS Code and JetBrains. (docs.github.com)
- Instrument metrics and logs; schedule a 30‑minute daily standup until parity is reached. (docs.github.com)
- Create a backlog to migrate remaining Extension behaviors into MCP tools over the next two sprints.
Zooming out
You’re not just replacing a plugin. You’re standardizing the way your agents act on your behalf. Do the smallest thing that works, ship it, then iterate. By consolidating integrations behind MCP, you’ll spend less time re‑wiring assistants and more time shaping the tools that actually move the needle for your business.
