GitHub Copilot Code Review: Skills and MCP Guide

GitHub made agent skills and MCP support generally available for Copilot code review on July 29, 2026. Availability covers Copilot Pro, Pro+, Business, and Enterprise. The feature can pull repository procedures and external context into a review, with attribution when a comment used a skill or MCP source.

This is not permission to connect arbitrary servers. GitHub says code-review MCP calls are read-only, while its shared repository-MCP documentation also says agents call enabled tools autonomously without asking. Configure for the broader shared surface, not only the reviewer you intended to enable.

What reached GA

Two customization paths moved from public preview to GA:

• Agent skills: task-specific instructions in .github/skills/NAME/SKILL.md, selected when relevant to a review.
• Repository MCP servers: external context providers configured in repository settings, shared with Copilot cloud agent.

The built-in GitHub and Playwright MCP servers are enabled by default for code review. Repository settings also enable Allow Copilot to use MCP tools when reviewing pull requests by default. Administrators can disable that toggle while retaining MCP configuration for the cloud agent.

Attribution helps with observability: a review comment can indicate that skill or MCP context contributed. Attribution is evidence that context was used, not evidence that the conclusion is correct.

Copilot code review and GitHub Code Quality solve different jobs. Review provides advisory feedback on a pull request. Code Quality adds systematic rules, coverage signals, repository-wide analysis, and optional merge gates. Use deterministic gates where a property can be computed.

Choose the right customization file

GitHub's current guidance separates always-on rules from on-demand procedures:

Put “all database changes require a rollback path” in standing instructions. Put the multi-step procedure for checking a migration against schema, deploy order, and rollback in a database-migration-review skill.

Avoid copying the same rule into all four surfaces. Duplication makes later edits inconsistent and consumes review context. AgentPedia's AGENTS.md code-review guide explains how to turn repository policy into checks that work across tools.

Create a review-focused skill

GitHub says a review-focused directory name such as code-review makes Copilot more likely to select the skill. A minimal project skill can look like this:

---
name: code-review
description: Review pull requests for authorization, data exposure, migration safety, and missing tests.
---

# Repository review workflow

1. Identify changed trust boundaries and persisted-data formats.
2. Check authorization before each new read or write path.
3. Require forward and rollback steps for schema changes.
4. Match behavior changes to tests, including negative cases.
5. Report file and line evidence. Do not approve or merge.

Save it as:

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

A useful skill names observable checks and expected evidence. “Review carefully” adds little. A skill also should not instruct Copilot to run destructive scripts, reveal secrets, or treat an issue description as trusted instructions.

GitHub's skill documentation says a selected SKILL.md is injected into context and can include scripts or examples from its directory. Review every file in an installed skill. GitHub warns that skills are not verified and can contain prompt injection, hidden instructions, or malicious scripts.

For third-party skills, preview before installing:

gh skill preview OWNER/REPOSITORY SKILL
gh skill install OWNER/REPOSITORY SKILL

The gh skill command itself is still public preview and currently requires GitHub CLI 2.90.0 or later. That preview status is separate from GA support for skills in Copilot code review.

Test changes from the head branch

Copilot reads repository custom instructions, root AGENTS.md, and agent skills from the pull request's head branch, not the base branch. This allows a pull request to test a new review skill before merging it.

It also creates a review boundary. A contributor can change code and the instructions used to review that code in the same head branch. Treat changes under these paths as security-sensitive:

.github/copilot-instructions.md
.github/instructions/
.github/skills/
AGENTS.md

For an untrusted or high-risk pull request:

1. inspect instruction and skill diffs before relying on the automated review;
2. compare them with the base branch's approved policy;
3. request a separate human review for configuration changes;
4. ensure branch protections cover the owners of review policy;
5. rerun the review after suspicious instructions are removed.

The head-branch behavior is deliberate, but it means an attributed skill comment does not prove the skill was the approved base-branch version.

Configure MCP with an explicit allowlist

Repository administrators add MCP JSON under Settings → Copilot → MCP servers. Authentication values belong under Settings → Secrets and variables → Agents.

GitHub accepts local server types (local or stdio) and remote types (http or sse). Each server needs a tools list. GitHub strongly recommends listing specific read-only tools because the agent can invoke them autonomously and does not ask first.

This illustrative shape follows the documented fields:

{
  "mcpServers": {
    "service-catalog": {
      "type": "http",
      "url": "https://catalog.example.internal/mcp",
      "headers": {
        "Authorization": "Bearer $COPILOT_MCP_CATALOG_TOKEN"
      },
      "tools": [
        "get_service",
        "get_owner",
        "get_runbook"
      ]
    }
  }
}

Agent secrets or variables referenced by MCP configuration must start with COPILOT_MCP_. The reference may use $COPILOT_MCP_NAME or ${COPILOT_MCP_NAME} syntax. Expose a secret to the server under the minimum environment variable or header needed; do not place literal tokens in the configuration.

Read-only needs to be true at several layers:

A tool named get_issue can still be unsafe if its server runs arbitrary queries, follows untrusted redirects, or returns sensitive fields. Review the server and credentials; do not infer safety from the method name.

Account for shared repository settings

Repository MCP configuration applies to both Copilot code review and Copilot cloud agent. A change made to improve review context can therefore alter the cloud agent's tool surface. Conversely, an MCP server added for implementation work becomes available to review unless the code-review MCP toggle is disabled.

The practical rule is to evaluate permissions against the most capable shared consumer. GitHub's current docs warn that configured tools can be called autonomously. Prefer separate read-only server endpoints and narrowly scoped credentials even though code-review calls are limited to read-only.

The default GitHub MCP uses a specially scoped token with read-only access to the current repository. GitHub documents an optional wider personal access token for access outside the repository and recommends a fine-grained token with read-only permissions on specific repositories. Wider access expands both confidentiality and prompt-injection risk.

Playwright is also enabled by default. Browser access can retrieve useful documentation or application state, but pages are untrusted input. Do not rely on it for secrets, production mutation, or authorization decisions.

Verify tools and attribution

Test the complete path on a harmless pull request:

1. Add a review-focused skill on the head branch.
2. Mention a real issue or incident identifier that the configured MCP can retrieve.
3. Request a Copilot review.
4. Open View session from the pull request timeline.
5. Inspect Setting up environment for started MCP servers and called tools.
6. Confirm the called tool is on the allowlist and used the expected credential scope.
7. Inspect comments for skill or MCP attribution.
8. Compare the comment's factual basis with the retrieved source.

Test negative cases too: an unknown issue key, an unauthorized service, a server timeout, malformed output, and content containing instructions aimed at the reviewer. The correct result is a bounded failure or an explicit lack of context, not an invented answer.

The Cisco Antares vulnerability-localization guide offers a related verification pattern: model output should identify evidence to inspect, while reproducible checks decide whether a finding holds.

Budget for Actions and AI-credit usage

Copilot code review has two usage components:

• AI credits for the model interaction;
• GitHub Actions minutes for agentic context gathering and tool use.

GitHub uses standard hosted runners by default. Larger hosted runners cost more per minute; self-hosted runners do not consume Actions minutes. If hosted runners are disabled, GitHub says the agentic capabilities are unavailable and the review falls back to a more limited form. A review can still be generated when Actions is unavailable or its workflow fails, but it lacks those additional agentic capabilities.

Review effort also matters. GitHub documents Low as the default and Medium as a longer, higher-reasoning review that uses more AI credits and Actions minutes. Track usage before enabling automatic review on every push.

Automatic review usage is normally attributed to the pull request author; manual review usage goes to the requester. Business and Enterprise budget controls can block reviews when user, cost-center, or enterprise limits are exhausted. Users without a plan that includes review can create paid additional usage for the organization when administrators enable that policy.

Plan for predictable failures and human limits

GitHub explicitly says Copilot is not guaranteed to find every issue and can make mistakes. Human reviewers must own architecture, security, authorization, data migration, regulatory requirements, and the merge decision.

Roll out in controlled stages

• Inventory existing instructions, AGENTS.md, skills, and repository MCP settings.
• Remove duplicated or contradictory rules.
• Add one review-focused skill with observable checks.
• Protect review-policy paths with appropriate ownership.
• Configure one server with specific read-only tools and a least-privilege COPILOT_MCP_ secret.
• Review how the same server affects Copilot cloud agent.
• Test success, no-access, timeout, malformed-data, and injection cases.
• Verify session logs and comment attribution.
• Measure AI credits and Actions minutes on Low and Medium effort.
• Keep required CI and human approvals independent of Copilot comments.
• Document how to disable MCP for code review without breaking cloud-agent workflows.

Practical verdict

Use skills when a review needs a repeatable procedure, and MCP when correctness depends on current context outside the repository. Keep broad conventions in instructions and AGENTS.md. This division makes the setup easier to audit and reduces irrelevant context.

The GA feature is useful precisely because it can connect policy and live context to a diff. That same reach makes least privilege mandatory. An allowlisted retrieval tool can improve a review; an arbitrary autonomous server is not made safe by the words “read-only.”

Official sources

• GitHub GA announcement: Copilot code review agent skills and MCP
• GitHub Docs: Copilot code review concepts, usage, customization, and limits
• GitHub Docs: Configure MCP servers for a repository
• GitHub Docs: Add agent skills