Skip to content
Guideintermediate

Best MCP servers for GitHub Copilot: what to install from the new Customize tab

Published August 27, 2026 · Updated August 27, 2026 · by Pondero Reviews

The short version

GitHub's Customize tab went GA on August 25, 2026, and it is the first browse-and-install marketplace for MCP servers inside Copilot. Here is the ranked list of which MCP servers to add, which to skip, and how to lock the whole thing down for a team.

Table of Contents

Best MCP servers for GitHub Copilot: what to install from the new Customize tab

GitHub shipped the Customize tab for the Copilot app to general availability on August 25, 2026, and it changes the boring part of extending Copilot: finding the extension. Until now, adding a Model Context Protocol server meant hand-editing a JSON config or hunting for the right CLI command. The Customize tab replaces that with a browse-and-click flow that pulls MCP servers, plugins, skills, and canvases into one screen. The interesting question is no longer "how do I add one." It is "which ones are worth the tool slot."

Here is the short version. Install the GitHub MCP server first, because it feeds Copilot the issues and pull requests it is already reasoning about. Add Firecrawl if your agent tasks need live web data. If you run backlogs in Azure DevOps, turn on the featured Azure DevOps canvas. Pick exactly one of n8n or Make for workflow automation, not both. Everything else can wait until you hit a real gap. The rest of this piece is the reasoning, a comparison table, the servers to skip, and the enterprise config that keeps developers from installing something they shouldn't.

How the Customize tab actually works

The Customize tab groups four things GitHub calls customizations: MCP servers, plugins, skills, and canvases. MCP servers are the ones that matter for connecting Copilot to outside systems. The tab gives you three ways in: a Featured view with hand-picked options across every type, a browse-by-category view for MCP servers specifically, and a Trending list. GitHub's launch screenshot features Figma, Impeccable Design, and Microsoft Foundry as examples of what shows up there.

The Featured view is the useful default when you do not yet know what you need. GitHub's own framing is that it gives you "a simpler starting point when you do not already know which MCP server, plugin, skill, or canvas you need," per the changelog. Once you know the shape of what you want, the per-type sections are faster.

Installing from the tab is a click path, not a config file:

  1. Open the GitHub Copilot app and select the Customize tab.
  2. Choose a lane: start in Featured, or open the MCP servers section and browse by category or Trending.
  3. Open a server's card and read what it connects to and what it can do before you commit a tool slot to it.
  4. Install it. Remote MCP servers run an authorization handshake on first use, so expect to grant access to the third-party account behind the server.
  5. Confirm the server shows up in your active tools. Copilot writes it into your MCP configuration so it persists across sessions.

That last point matters for teams: the tab is a front end over the same config that admins can govern centrally, which is the enterprise section further down.

The MCP servers worth installing

Copilot has a finite attention budget. Every server you add is another set of tools the model has to choose between, so the goal is a short, high-signal list, not a full cart. These are the ones that earn their slot, ranked by how often they pay off.

MCP serverWhat it plugs into CopilotCopilot sideIts own costLink
GitHub MCP serverYour issues, pull requests, code, and Actions runsAny paid plan; on by default in code reviewFree, open source/go/github-mcp-server
FirecrawlLive web pages and search results for agent tasksAny paid planFirecrawl account and API key/go/firecrawl
Azure DevOps canvasBacklog triage, issue assignment, hand-off to CopilotFeatured canvas in the Customize tabAzure DevOps subscriptionCustomize tab (no affiliate)
n8nTrigger and expose self-hosted automations as toolsAny paid planFree self-hosted, or n8n Cloud/go/n8n
MakeFire scenarios across a large app catalogAny paid planMake account, usage-metered/go/make

Prices for the Copilot side are covered in the enterprise section; every plan from Copilot Pro at $10 per user per month up can use MCP servers from the Customize tab.

GitHub MCP server, first, every time. This is the one server almost every Copilot user should turn on, and it is open source at github/github-mcp-server. It gives Copilot structured access to the issues, pull requests, and repository data you are already asking it about, which means a prompt like "summarize the open PRs touching the billing module and flag the risky ones" resolves against real repo state instead of guesses. GitHub already treats it as table stakes: in Copilot code review, which went GA on July 29, 2026, the GitHub and Playwright MCP servers are turned on by default. The candid con is small. It is another authorization surface, and in code review, MCP tool calls are read-only by design, so do not expect it to open PRs on its own there.

Firecrawl, when the task leaves your repo. Copilot is strong on code it can see and weak on the live web. Firecrawl closes that gap by giving an agent a clean way to fetch and search real pages. It works over MCP, and its Lockdown Mode, which serves results from Firecrawl's own index with no outbound requests, is available in the MCP integration as of the v2.10 release on May 15, 2026. The case for it is any task where the answer lives on a docs site, a changelog, or a competitor's pricing page rather than in your codebase. The catch: it is a separate product with its own account and API key, so this is the recommendation with a real second bill attached.

Azure DevOps canvas, if that is where your work lives. GitHub featured an Azure DevOps canvas in the launch, built to "triage issues, prioritize backlogs, assign follow-ups, and hand work to Copilot to investigate, implement, or prepare for review," per the changelog. A canvas is not an MCP server, but it belongs on this list because it solves the same problem for the specific reader who plans work in Azure DevOps and codes in Copilot. If that is you, it is the shortest path from a backlog item to a Copilot task. If it is not, skip it entirely.

n8n or Make, pick one. Both connect Copilot to the rest of your stack: send a Slack message, open a Jira ticket, kick off a deploy, all triggered from an agent run. n8n is the pick if you want to self-host and keep the automation logic in your own infrastructure; it exposes workflows as MCP tools through its MCP server trigger. Make is the pick if you want a hosted MCP server and a broader catalog of prebuilt app connectors without running anything yourself. They occupy the same slot in Copilot's tool list, so installing both just makes the model's routing harder. Choose on hosting preference: your servers, n8n; someone else's, Make.

What to skip or deprioritize

The Customize tab makes installing easy, which is exactly why restraint is the skill now. A few categories are usually not worth the tool slot on day one.

Skip anything that duplicates a default. The GitHub and Playwright MCP servers already come on by default inside Copilot code review, so adding a third browser-automation or GitHub-data server on top rarely buys you anything except a more confused tool router. Prove you have a gap before you fill it.

Deprioritize heavy self-hosted servers unless you already run the infrastructure. A database or internal-service MCP server can be powerful, but standing one up, securing it, and keeping it patched is real work that a two-person team will feel. If the payoff is "Copilot can now read our staging Postgres," weigh that against the maintenance before you install it from a card in ten seconds.

Be wary of trusting a server by its name. GitHub is explicit that the serverName matcher "is only supplied as a convenience, not a security control, since users can rename servers," per the managed settings changelog. A friendly label in the Trending list is not a vouch. For anything that touches private data or runs code, check what it actually connects to on the card before you grant it access.

Enterprise config: governing what gets installed

A browse-and-install marketplace is a governance problem the moment more than one developer is involved. GitHub shipped the answer on August 6, 2026: enterprise owners can control which MCP servers Copilot clients may run using the allowedMcpServers and deniedMcpServers keys in copilot/managed-settings.json, per the changelog. Each key holds a list of matchers that identify servers by remote URL (serverUrl, which supports * wildcards and canonicalizes URLs to block evasion), by local command (serverCommand), or by label (serverName, the convenience-only matcher above).

Here is a fail-closed baseline: allow the two servers your team actually depends on, deny a known-bad one, and let nothing else through.

{
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.firecrawl.dev/*" },
    { "serverName": "github" }
  ],
  "deniedMcpServers": [
    { "serverCommand": "npx -y untrusted-mcp-server" }
  ]
}

The behavior that makes this safe is the default. Policies fail closed, so "a malformed or unverifiable configuration is blocked rather than allowed," and when policies stack across layers, a server must pass every layer to run. In practice that means a developer who tries to install a server outside the allowlist gets nothing, not a silent pass. The keys are enforced today on the GitHub Copilot app, Copilot CLI, and VS Code. You store the file in your source organization's .github-private repository and commit it to the default branch. If you want teams to extend the baseline, mark the keys overridable so a team can add its own allow and deny lists on top of yours.

This pairs with the other governance change that landed the day after the Customize tab. Global model policy went GA on August 26, 2026 for Copilot Business and Enterprise, with enforcement rolling out through September 1. It sets a default enablement state for generally available models, and it excludes open-weight models such as DeepSeek and Kimi K2, plus any model not covered by GitHub's data retention agreement, from default enablement regardless of your policy. Read the two together: MCP allowlists decide which tools Copilot can reach, and model policy decides which brains it can use to reach them. For a regulated team, you want both set before you tell developers to open the Customize tab.

Start here

Solo developer on Copilot Pro ($10 per user per month, per GitHub). Install the GitHub MCP server and stop. It is free, it makes Copilot better at the repo work you already do, and it adds no second bill. Add Firecrawl only when you hit a task that genuinely needs live web data, and treat its separate account as a real cost, not a free extra.

Small team on Copilot Business ($19 per granted seat per month, per GitHub docs). Same GitHub MCP server for everyone, plus one automation server. Pick n8n if you already self-host and want the logic in your own infrastructure, Make if you would rather not run anything. Set a light allowedMcpServers baseline now so the list stays curated as the team grows, even before you think you need it.

Enterprise on Copilot Enterprise ($39 per granted seat per month, per GitHub docs). Lead with the config, not the marketplace. Ship a fail-closed copilot/managed-settings.json with an explicit allowlist, deny anything you have not vetted, and set your global model policy before enforcement completes on September 1. Then let developers loose in the Customize tab, where the only servers they can install are the ones you already approved. That is the whole point of shipping the marketplace and the guardrails in the same month.