MCP Adoption Week: Copilot Code Review Goes GA

MCP adoption crossed a threshold this week. On July 29, 2026, GitHub moved Copilot code review’s Agent skills and MCP server connections from public preview to general availability — across every paid Copilot tier, not just Enterprise — exactly one day after the Model Context Protocol’s 2026-07-28 spec formally shipped.

Neither event alone is the story. Together they mark the point where MCP stops being an early-adopter flag and becomes a procurement checkbox: a versioned protocol with a formal deprecation policy on one side, and a mainstream vendor shipping MCP behind a plan tier on the other. We’ve already published a full breakdown of what actually breaks in the July 28 spec migration — this post deliberately doesn’t re-cover that ground.

Instead, this is the adoption view: what GitHub actually shipped, how the read-only scoping decision should shape your own agent integrations, the preview-to-GA delta in one table, the spec-to-spec deltas that matter to a team flipping this on, and a rollout sequence for going from a single repo to org-wide.

Per GitHub’s changelog, two capabilities inside Copilot code review moved from public preview to general availability on July 29, 2026: Agent skills — repository- or org-specific instructions that extend the review analysis with your own coding standards and tooling context — and MCP server connections, which pull context from third-party systems (issue trackers, documentation systems, service catalogs) into the review itself.

The availability detail matters more than it looks. GA spans Copilot Pro, Pro+, Business, and Enterprise — every paid tier. That’s a different posture from gating agentic features behind Enterprise, and it’s the clearest signal in the release: GitHub is treating skill-extended, MCP-connected code review as a mainstream product surface, not a controlled experiment.

One more GA-level feature deserves a highlight: Copilot code review now visibly attributes which comments were informed by an agent skill or by MCP-sourced context. For anyone who has tried to debug why an AI reviewer raised a particular objection, that attribution line is the difference between a black box and an auditable system — and it’s the kind of feature that ships when a vendor expects compliance teams, not just enthusiasts, to be looking.

The timing is the tell. The MCP 2026-07-28 spec shipped on July 28 — its headline change makes the protocol core stateless, so MCP servers can sit behind standard load balancers with no session store. GitHub’s GA followed on July 29. That’s an ecosystem move sequenced right behind the spec revision, not simultaneous with it: the protocol formalizes, then the biggest developer platform on earth ships it as a GA product feature. For the full engineering picture — what breaks, deprecation windows, migration order — see our stateless-migration guide; we won’t re-explain the spec here.

The scale numbers in the MCP team’s announcement back the mainstreaming read. Tier-1 SDKs collectively exceed 500 million monthly downloads, and the TypeScript and Python SDKs have together crossed one billion total downloads combined. The Tier-1 list itself widened to TypeScript, Python, Go, and C#, with Rust added at beta support — first-party language coverage broadening beyond the original TS/Python pairing.

Mechanically, an agent skill for code review is a SKILL.md file inside a skill subdirectory under .github/skills in the repository. GitHub’s docs describe skills as folders of instructions, scripts, and resources that Copilot can load when relevant to improve its performance in specialized tasks — in the review context, that means encoding your team’s coding standards, architectural conventions, and internal tooling context so the reviewer applies them instead of generic heuristics.

The strategic detail is that skills are a cross-surface primitive, per GitHub’s agent-skills documentation: the same SKILL.md mechanism works across the Copilot cloud agent, Copilot code review, the Copilot CLI, the Copilot app, and agent mode in VS Code and JetBrains. A skill you author once for review is reusable everywhere Copilot runs — which changes the economics of writing them.

The practical implication for engineering leads: your review standards document — the one that lives in a wiki nobody reads during review — now has an enforcement path. Codify it once as a skill, and it applies on every PR, with the attribution line showing when it fired. Start with the two or three standards your team violates most often; a sprawling skill that tries to encode everything tends to be harder to evaluate than several narrow ones.

The most consequential design decision in the GA is easy to skim past: all MCP tool calls invoked during code review are read-only. GitHub scoped the integration deliberately so a reviewing agent can pull context from your issue tracker, docs system, or service catalog — but cannot write back to any of them. The reviewer reads; it never mutates.

Configuration follows the same conservative pattern. Existing MCP server configurations set up for the Copilot coding agent automatically carry over to code review — no second config to maintain. New servers are added per repository under Settings → Copilot → MCP servers, with auth tokens stored under Settings → Secrets and variables → Agents, per GitHub’s MCP configuration docs. Tokens live in a dedicated secrets scope, not in the config itself.

The changelog states the new state; it doesn’t frame the delta for someone planning a rollout. The table below compresses the GA facts — capability, status, and where each is configured — against the rollout question each one answers. The first three columns are sourced from GitHub’s changelog and docs; the final column is our own analysis.

You don’t need the full migration guide to make an adoption call — you need the deltas that change your operational posture. The table below compresses the 2026-07-28 spec against its 2025-11-25 predecessor to the rows that matter for a team deciding whether to lean on MCP in production tooling. As Sean Roberts, VP of Applied AI at Netlify, put it in the MCP announcement: “The stateless core in the 2026-07-28 spec makes MCP a first-class HTTP workload with no session management to work around.”

The GA didn’t land in a vacuum. AWS announced day-one support for the 2026-07-28 spec in AgentCore Gateway, rolled out via a single UpdateGateway API call with no gateway recreation and no per-target migration. The mechanism is the interesting part: a gateway can advertise multiple MCP protocol versions simultaneously — 2025-11-25 and 2026-07-28 side by side — with clients selecting a version per request via the MCP-Protocol-Version header. Requests for an unsupported version are rejected with HTTP 400 and a -32022 JSON-RPC error listing the versions the gateway does support. Version negotiation, in other words, is now an infrastructure-layer concern with concrete error semantics — client and gateway upgrades can run on independent schedules.

Worth keeping in frame: GitHub is not adding MCP support this week. VS Code and GitHub Copilot shipped baseline MCP support to GA in July 2025 (v1.102), roughly a year before this announcement, and the major non-Anthropic hosts — Cursor, Codex CLI, Windsurf among them — all shipped baseline support during 2025. July 29’s news is a feature-specific maturation step layered on an integration that is now about a year old. The server side grew underneath it: third-party registries (PulseMCP, the official registry, Smithery, mcp.so) tracked roughly 10,000+ listed MCP servers by April 2026 — a tracker figure that predates the July spec, cited here as ecosystem scale, not spec data.

Put the pieces together and the trend reads clearly: a protocol that spent 2025 accumulating integrations spent this week accumulating institutions. A formal spec with deprecation windows, a GA feature behind GitHub plan tiers, day-one support from AWS infrastructure — these are the artifacts of a technology crossing from adopted-by-engineers to purchasable-by-organizations. Our forward read: expect the “MCP supported” checkbox to show up in procurement questionnaires and vendor security reviews over the coming quarters, the way “SSO/SAML” did — and expect GitHub’s read-only-in-review scoping to be cited as the reference pattern when those questionnaires ask how agent integrations are constrained.

GA removes the “is this stable enough” question and replaces it with a sequencing one. Four postures cover most teams:

Two governance habits are worth installing on day one, whichever posture fits. First, treat skills as code: they live in the repo, so review skill changes with the same rigor as CI config — a modified skill silently changes what your AI reviewer enforces. Second, decide now what you’ll log and disclose when an agent-informed review goes wrong; our piece on agent incident-disclosure standards covers what mature teams track once tool-calling agents run in production. If you’re standing up agentic development practices — review agents, MCP wiring, skill libraries — across an organization, that rollout design is exactly what our AI transformation engagements are built around.