Model Context Protocol went from an interesting idea to something in your review pipeline over the course of July. GitHub shipped support for the next MCP specification on 23 July and took MCP in Copilot code review to general availability on 29 July.
If you are being asked to approve connecting it, here is what the decision actually involves.
What MCP is
A standard way for an AI tool to read from a system it does not own. Instead of every vendor building a bespoke integration with your issue tracker, your documentation and your schema registry, each system exposes an MCP server and any MCP-speaking tool can read it.
The value is straightforward: a reviewer that can see your API contracts catches contract violations. A reviewer that only sees the diff cannot.
What you are actually approving
Connecting an MCP server grants a model read access to whatever that server exposes, on every request that reaches for it. That is not inherently risky, but it is a real expansion of what leaves your perimeter.
Three questions are worth answering before you connect anything:
- What exactly does this server expose — the whole system, or a scoped view of it?
- Does the connection need write access, or is read enough? Read is almost always enough for review.
- Who can see the outputs — is a review comment visible more widely than the source data it was derived from?
A sane rollout
- Connect one server, on one repository, for two weeks
- Compare what the reviewer catches against what it caught before — if there is no difference, the server was not the missing piece
- Keep a human approval on merge throughout; GA means stable behaviour, not correct judgement
Why this is worth doing anyway
The single most common category of production bug is code that is locally correct and globally wrong — it matches its own file and contradicts a contract defined somewhere else. That is precisely the class of problem a reviewer with context can catch and a reviewer without context cannot.