Copilot Code Review Now Pulls from MCP Servers

GitHub shipped two public previews on June 2, 2026: agent skills and MCP server connections for Copilot code review. The changelog entry frames this as "bringing your team's context into every review." That's one way to read it. Another: the model deciding whether your PR passes now takes instructions from servers your security team may not control.

What actually shipped

The update has two parts. First, custom agent skills: you drop a SKILL.md file into .github/skills/code-review/ and Copilot reads it when reviewing PRs. Think of it as a system prompt that lives in your repo. Second, MCP server connections: you configure JSON endpoints under repository settings, and Copilot calls those servers during the review to pull context from issue trackers, documentation, service catalogs, or internal tooling.

GitHub also announced that any MCP configurations already set up for Copilot's cloud agent automatically apply to code review too. There's no separate opt-in. If your org had MCP servers wired up for Copilot chat or coding assistance, those servers now influence the merge gate.

The trust problem with external context at review time

Code review has a simple contract: look at the diff, evaluate it against known standards, and flag problems. MCP connections change that contract. The review model now consults external servers before deciding what to flag, and whatever those servers return becomes part of the review context.

That creates a few concrete risks:

• Stale or wrong context changes what gets flagged. If an MCP server returns outdated documentation or incorrect service metadata, Copilot's review inherits that error. A security-relevant pattern might not get flagged because the external context said it was fine.
• A compromised MCP server can suppress findings. If an attacker gains access to an MCP endpoint, they can return context designed to make Copilot ignore specific vulnerability patterns. The review model has no way to distinguish legitimate context from adversarial context.
• MCP configuration lives in the repo or org settings. A malicious PR could modify MCP server configuration (or the skill files that reference them), changing review behavior for itself and subsequent PRs. The code under review and the review instructions now share an input channel.

That last point is the critical one. It's a prompt injection surface. An MCP server can return instructions that alter how Copilot evaluates the very PR that triggered the review. The reviewer and the reviewed are no longer separated.

Why extensibility at the merge gate is the wrong tradeoff

GitHub's direction is clear: make Copilot code review extensible. MCP connections, agent skills, configurable Actions workflows for review compute, shared configuration across review and cloud agent. Each feature adds a knob that platform teams need to audit and manage.

Extensibility is great in an IDE, where the developer is in the loop and can evaluate suggestions in context. It's great in a chat interface. It's less great at the merge gate, where the whole point is a consistent, predictable check that doesn't vary based on which external services happened to respond and what they returned.

Consider the audit question: when an MCP-augmented Copilot review approves a PR, what influenced that decision? The diff, the skill files, the model weights, and whatever N external servers returned at that moment. Reproducing that decision later, for a postmortem or a compliance audit, means replaying every external call with the same state. That's not realistic.

The CI-boundary alternative

There's a different architecture for automated code review: run it inside your CI pipeline, scoped to what the runner already has access to.

Tenki's code reviewer works this way. It runs as a CI step, inside the CI boundary. It doesn't make external MCP calls. The review behavior is determined by the code in the PR, the repository context the runner already has, and the review model. No external servers inject context at review time.

That means a few things concretely:

• No external attack surface. There's no MCP endpoint to compromise, no external server that can alter review output. The trust boundary is the CI runner itself.
• Reproducible results. Given the same code and the same model version, you get the same review. No variance from MCP server state or availability.
• Simpler audit trail. The inputs to the review decision are the diff and the repo state at that commit. No external call logs to reconstruct.

This isn't anti-MCP. It's about where extensibility belongs.

MCP is a genuinely useful protocol. Connecting an AI assistant to your issue tracker, your documentation, your internal APIs: that's valuable. The question isn't whether MCP is good. It's whether the merge gate is the right place to add that kind of extensibility.

In a code review that gates merges, you want the opposite of extensibility. You want predictability, isolation, and a minimal set of inputs. You want to know exactly what influenced the decision and be confident nothing outside your control changed the outcome. Every MCP connection is another variable, another server to monitor, another potential point of failure or compromise.

GitHub is betting that teams want customization above all else. For some teams, that's the right call. But if you're a security engineer evaluating Copilot code review for a regulated environment, or an engineering lead who needs to explain to auditors why a specific vulnerability wasn't caught, the MCP-at-the-merge-gate model introduces questions you didn't have before.

The alternative is architecturally boring, and that's the point. Run the review inside CI. Don't call external servers. Keep the trust boundary tight. Let MCP do its work in the IDE and the chat interface, where a human is evaluating the output in real time. At the merge gate, simplicity is a security property.