How to Give Copilot Code Review More Context Without Giving It Write Access

GitHub’s Copilot code review support for agent skills and MCP servers reached general availability on July 29, 2026. The useful part is not “AI reviews more code.” It is the boundary: repository instructions and external context can shape a review, while MCP calls made by Copilot code review remain read-only. GitHub also attributes comments that used skills or MCP context.

That makes this a practical control-plane problem: how do you add project context without quietly turning code review into an agent with mutation privileges?

The workflow

A safe starting design has four layers:

1. Versioned review policy in the repository.
2. Read-only external context for tickets, architecture notes, or service catalogs.
3. Attribution so reviewers can see which comments depended on that context.
4. Human approval before anything changes code, labels, issues, or deployments.

The model may produce an incorrect comment. Read-only access does not make the comment correct. It does reduce the blast radius of a bad tool call.

Put review policy next to the code

GitHub’s format is a skill-specific directory under .github/skills, containing a SKILL.md file. Start with narrow, testable instructions rather than a giant engineering handbook. For example:

.github/skills/api-review/SKILL.md

---
name: api-review
description: "Review changes to public HTTP APIs"
---

When a pull request changes a public endpoint:

- Check backward compatibility for field removal, type changes, and enum narrowing.
- Require an explicit migration note for response-shape changes.
- Check that authorization behavior is covered by a test.
- Treat generated client updates as evidence, not as proof of compatibility.
- If the repository does not contain enough evidence, say what is missing instead of guessing.

The important word is evidence. A skill should tell the reviewer where to look and what to verify, not force a conclusion. Keep the file small enough to review like production configuration.

Add context, not authority

MCP can connect a review to systems such as an issue tracker, documentation platform, or service catalog. Use those connections to answer questions like:

• What behavior does the linked issue actually require?
• Is this endpoint still supported?
• Which service owns the changed schema?
• Is there an approved deprecation date?

Do not treat retrieved context as an authorization decision. A ticket can be stale, a document can contradict the repository, and a service catalog can lag reality. The review should surface the source and uncertainty.

A useful review comment has this shape:

The PR changes POST /v2/orders by making currency required. The linked migration issue says old clients remain supported until September. I could not find a compatibility test for requests without currency; please add one or explain why the issue no longer applies.

That is much safer than: “This is a breaking change, revert it.”

Treat attribution as an audit signal

GitHub says comments generated with agent skills or MCP context are attributed. Use that signal during review triage:

Attribution is not a correctness score. It tells you what to inspect when a comment looks authoritative.

A small rollout checklist

Before enabling this for every repository, test one low-risk project:

• Add one skill for one review category, such as API compatibility.
• Connect one read-only MCP server.
• Store credentials in the repository’s Agents secrets, not in SKILL.md or the workflow.
• Open pull requests containing known good, known bad, and ambiguous changes.
• Record whether the reviewer found the expected issue, cited the right source, and stated uncertainty.
• Check that no connected tool can create, edit, merge, label, or deploy.
• Review the attribution on every context-dependent comment.

For a simple test matrix:

What this does not solve

Read-only MCP limits mutations, not hallucinations. Repository skills can become stale or contradictory. External context adds latency and another authorization surface. A comment can cite a real ticket and still misunderstand the implementation.

So measure the workflow, not just comment volume: useful findings confirmed by maintainers, false-positive rate, source freshness failures, time to resolve a finding, and how often reviewers had to correct the agent’s interpretation. GitHub’s announcement establishes availability and behavior; it does not provide an independent evaluation of review accuracy.

The practical rule is simple: give the review agent more evidence, but keep authority in the repository’s tests and the human approval path.

What would you connect first in your code-review workflow: issue context, architecture documentation, or a service catalog?

Sources:

• GitHub: Copilot code review support for agent skills and MCP servers
• GitHub Docs: Configure MCP servers for Copilot
• GitHub Docs: About agent skills