Copilot Extensions End Nov 10: Your MCP Migration Plan

The GitHub Copilot Extensions deprecation is here. On November 10, 2025, GitHub is disabling Copilot Extensions built as GitHub Apps in favor of Model Context Protocol (MCP) servers. If your org relies on Extensions for docs lookup, internal tooling, or code-gen workflows, you have hours—not weeks—to land a safe plan. (github.blog)

Here’s the thing: this isn’t just a rename. Extensions (as GitHub Apps) used to live inside Copilot Chat’s UI model; MCP is an interoperability standard that exposes tools to many agents, not just Copilot. That’s why this shift changes how you authenticate, govern, and observe AI-powered actions in your stack. Done right, though, MCP will reduce lock‑in and make your tools usable across Copilot, Claude Code, and others.

What exactly is changing on November 10?

GitHub will disable Copilot Extensions that are implemented as GitHub Apps. New creation was blocked September 23; tomorrow, November 10, existing ones stop working. Visual Studio Code “Copilot extensions” (client‑side) are not affected. (docs.github.com)

• Disabled: Copilot Extensions built as GitHub Apps (the server‑side integrations listed in GitHub Marketplace for Copilot Chat).
• Not affected: the VS Code Copilot extension and IDE-specific add‑ons that don’t use the GitHub App‑based Extensions model. (docs.github.com)
• Replacement path: Implement MCP servers that expose the same capabilities as your retiring Extension. (github.blog)

If you do nothing, Copilot Chat commands that relied on those Extensions will fail after November 10, 2025. That means frustrated developers and confused stakeholders. Let’s not do that.

Why the move to MCP matters

MCP—short for Model Context Protocol—is a standard way to connect AI agents to tools and data. Instead of bespoke APIs per vendor, you run or subscribe to MCP servers that advertise capabilities (tools, resources, prompts) over a simple transport, typically JSON‑RPC streams. GitHub ships an official GitHub MCP server; admins can also point Copilot to other servers and registries. (docs.github.com)

Strategically, MCP de‑risks your investment: the same server can be consumed by multiple AI “hosts.” If you built an extension solely for Copilot, you were locked to one client. With MCP, one server can power Copilot today and other IDE agents tomorrow. That’s a cleaner architecture for enterprises who want choice.

GitHub Copilot Extensions deprecation: fast facts

Let’s anchor on concrete dates and scope, since teams plan around calendars, not vibes:

• September 23, 2025: Creation of new Copilot Extensions blocked. (docs.github.com)
• November 10, 2025: App‑based Copilot Extensions disabled. (github.blog)
• Successor pattern: MCP servers configured in IDEs or in Copilot’s coding agent context. (docs.github.com)

If your production workflows depend on Extensions, treat November 10 as a hard change window.

Your 1‑Day MCP Cutover Checklist

No time for a months‑long program? Use this pragmatic sequence and you’ll get from red risk to stable in a day.

1) Inventory what will break

List every Copilot Chat command or slash action your teams use that calls an Extension. Categorize by capability: “docs search,” “repo triage,” “incident notes,” “build & deploy hints,” “design review.” Prioritize the ones used daily.

2) Map features to MCP tools

For each capability, decide whether to adopt an existing MCP server or write a minimal server that wraps your internal API. Many needs are covered by community servers; GitHub’s own MCP server already exposes GitHub repo, PR, and issue operations. (docs.github.com)

3) Decide hosting: remote vs local

Copilot can talk to hosted MCP servers (OAuth/PAT) or local ones you run in the developer environment. Start with hosted for speed; fall back to local only where data residency or offline access requires it. GitHub documents both flows, including a managed remote option and a Docker‑based local pattern. (docs.github.com)

4) Set authentication and policy

Enterprises must explicitly enable “MCP servers in Copilot” to let users attach servers in IDEs. Enforce least privilege: use fine‑grained PATs for read‑only repos, or OAuth scopes approved by admins. (docs.github.com)

5) Configure the server in your IDE or repo

Developers can add MCP server definitions via IDE settings (e.g., a server id and URL), and administrators can configure MCP for the Copilot coding agent at the repository level with a small JSON block and environment secrets prefixed with COPILOT_MCP_. (docs.github.com)

6) Smoke‑test the critical path

Run two or three realistic chats that mirror daily use: “Summarize open PRs affecting checkout,” “Find relevant incident runbooks,” “Create a test plan from this issue.” Validate outputs, rate limits, and latency. Keep a human in the loop for any write‑action at first.

7) Announce and monitor

Post a short Loom or screenshot how‑to, and ask teams to try the new tools. Watch for error spikes and adjust scopes or tool prompts. Treat this as a change rollout, not a silent flip.

How do I migrate a Copilot Extension to MCP?

If your old Extension made HTTP calls to an internal service, your MCP server can implement equivalent tools and expose them with guardrails. A minimal approach:

1. Build a tiny service (Node, Python, Go—your choice) that implements tool handlers, validates inputs, and calls your internal API.
2. Wrap authentication in your standard proxy or use PAT/OAuth where GitHub access is needed.
3. Declare tool schemas with strict parameter types; return compact, structured results.
4. Ship an allowlist of repos or environments where write actions are permitted; everything else read‑only.
5. Publish the server in your internal MCP registry (or point clients directly at the URL) and document one‑step setup.

For GitHub‑centric tasks, you may not need to write anything: the official GitHub MCP server already covers repo content, issues, and PR context from Copilot Chat. (docs.github.com)

Will Copilot break in our org after Nov 10?

Baseline Copilot (chat, completions) will still work. What breaks are chats and automations that depended on App‑based Copilot Extensions. If you replaced those with MCP servers and flipped the enterprise policy switch, your users can keep working with minimal friction. (docs.github.com)

Security: what’s different with MCP?

Two things worth calling out to CISOs and platform teams:

Scope clarity beats blanket access. MCP configurations are explicit. If your server only needs read access to two repos, grant a fine‑grained PAT with those scopes and store it as a COPILOT_MCP_ secret or use OAuth with tight scopes. Keep write tools disabled until you’ve run tabletop exercises. (docs.github.com)

Policy is real. In Copilot Business/Enterprise, MCP servers in Copilot is off until you enable it. Use groups to stage rollout (pilot → dev tools team → entire org). If you’re in a regulated environment, maintain a curated MCP registry so teams consume only vetted servers. (docs.github.com)

Gotchas we’ve seen in real teams

Remote OAuth vs coding agent. Copilot’s coding agent currently supports tools from MCP servers, but doesn’t support remote servers that require OAuth in that specific agent path; plan PAT‑based access for the agent until support expands. (docs.github.com)

Over‑permissive tokens. Some pilots toss a wide‑open classic PAT into a server “just to test.” Don’t. Use fine‑grained or org‑scoped tokens and rotate them on your normal cadence.

Silent failures from bad schemas. If a tool schema doesn’t match what the server returns, the host may drop the response without a pretty error. Keep payloads small and stick to your declared types.

Shadow servers. Without a registry, teams will wire random servers they found on GitHub. Stand up an internal registry entry and point IDEs to it. Governance matters. (docs.github.com)

People also ask

“Do we need to rebuild everything we had in Extensions?”

Not necessarily. Start by mapping usage to the GitHub MCP server and a handful of common servers (docs search, knowledge base, incident notes). Only build a custom server for gaps or proprietary workflows. (docs.github.com)

“Is MCP only for GitHub Copilot?”

No. MCP is a broad, vendor‑neutral standard that multiple agents and IDEs can use. That’s the long‑term play—reduce integration churn, increase reuse. GitHub’s deprecation accelerates that shift. (docs.github.com)

“How do we keep costs from spiking?”

Two levers: minimize verbose tool outputs and cap write actions. Also educate users—structured prompts and fewer retries mean fewer tokens across whichever model you use. If you manage Copilot budgets, borrow tactics from our Copilot budget playbook and put alerts on premium requests.

A practical example: replace a docs Extension in under an hour

Scenario: your Extension queried internal engineering docs. Rebuild it as a lean MCP server that exposes one tool: search_docs(query, product, depth). For hosting, deploy a tiny Node service behind your standard API gateway. Authentication: your gateway checks SSO; the MCP server only needs a short‑lived service token. In the IDE, teams add your server URL and select the tool. Now when developers ask, “Find our 2025 checkout feature flags,” Copilot calls search_docs and returns the top three pages with permalinks.

Want GitHub context right in that answer? Also enable the GitHub MCP server so Copilot can pull relevant PRs and issues alongside your docs hits. (docs.github.com)

Observability for MCP

Treat MCP traffic like any other production API. Capture structured logs (tool name, latency, tokens in/out if available, error codes), ship to your standard telemetry, and build a minimal dashboard. In week one, you’re looking for two things: response time (users abandon after ~5–7 seconds) and failure clusters (bad scopes, schema mismatches). Add circuit breakers so write‑tools degrade to read‑only during incidents.

Where MCP lives in Copilot

You’ll touch MCP in two places:

• IDE clients (VS Code, JetBrains, etc.): users configure servers from the MCP marketplace or a custom registry. Start there to unblock individuals quickly. (docs.github.com)
• Copilot coding agent (repo‑level automation): admins declare MCP servers and secrets in GitHub settings. Use this for repeatable, team‑wide flows like PR grooming or release checklists. (docs.github.com)

Budget and policy sidebars worth sharing with leadership

Even though the GitHub Copilot Extensions deprecation isn’t primarily about pricing, any workflow change can nudge usage. If you’re enabling more powerful tools, put a lightweight approval flow around premium model usage and track token burn. Our clients have avoided most surprises by limiting long‑context requests and setting alerts on premium tiers; you can adapt these tactics from our guide on avoiding Copilot surprises.

Decision tree: build, buy, or reuse?

When the deadline is tomorrow, reuse wins. Ask:

• Can the official GitHub MCP server cover 60–80% of our needs today? If yes, start there. (docs.github.com)
• Is there a vetted server in our registry for the rest? If yes, wire it up. (docs.github.com)
• Only then build a minimal custom server. Keep it tiny, auditable, and easy to rotate.

“But we also automate builds and deployments—any overlap?”

Yes, indirectly. The Copilot coding agent and your CI system will coexist, and sometimes coordinate. As you grant tools more power, ensure your GitHub Actions policies, concurrency, and runner limits are sane. If you haven’t already, review what changed this month in Actions and tighten permissions; our rundown of November GitHub Actions changes is a useful companion.

Rollout template you can copy

Here’s a simple, low‑risk rollout plan many teams can finish today:

1. Enable policy: Turn on MCP servers in Copilot for a pilot group. (docs.github.com)
2. Provision: Add the GitHub MCP server and one internal server for docs/search to your IDE profiles. (docs.github.com)
3. Scope tokens: Create fine‑grained PATs with read‑only permissions; store as COPILOT_MCP_ secrets (coding agent) or use OAuth in IDEs. (docs.github.com)
4. Test scripts: Run three scripted chats per team; sign off when outputs match the old Extension experience.
5. Communicate: Post a 3‑paragraph internal note with setup steps and a 60‑second video.
6. Monitor: Add temporary on‑call for MCP errors this week; relax once baseline stabilizes.

What to do next (engineers and leaders)

For developers

• Add the GitHub MCP server in your IDE and try your top two Copilot chats with it today. (docs.github.com)
• File a one‑pager on any missing tool you need. Keep parameters explicit and outputs tight.
• If your team uses the coding agent, validate the repo‑level MCP config and secrets.

For engineering leaders

• Enable the MCP servers policy for a pilot group; stage the org‑wide rollout this week. (docs.github.com)
• Stand up an internal MCP registry entry with only vetted servers.
• Assign a product owner for AI tooling who owns governance, budget controls, and metrics. Adapt budgets with our budget playbook.

Need help? If you want a partner to stand up a secure MCP stack or convert high‑value Extensions fast, our services team can jump in this week. Or reach out directly via contacts.

Zooming out

Tomorrow’s shutdown is inconvenient, but the direction is right. Teams get a standard that survives client churn; admins get better policy and auditability; developers get tools that travel with them across IDEs and agents. The GitHub Copilot Extensions deprecation is a forcing function—use it to simplify, standardize, and future‑proof your AI tooling. (github.blog)

FAQ: a few edge cases

Do we need admin rights to add MCP in IDEs? Users can add servers, but Copilot Business/Enterprise admins can centrally enable or disable the capability; align with your governance first. (docs.github.com)

Can we point to a custom MCP registry? Yes. You can swap the registry URL in supported IDEs to curate approved servers. (docs.github.com)

Where do we find GitHub’s official server docs? GitHub maintains both docs and a repository for the GitHub MCP server; start there for capabilities and configuration details. (docs.github.com)