Как проверить использование MCP в Copilot Code Review

Проверено 13 сентября 2026 года. GitHub рекомендует проверять атрибуции внизу review comments, открывать связанную review session из timeline pull request и смотреть session logs/tool calls. В репозиторном контексте GitHub и Playwright MCP servers включены по умолчанию; это изменяемая доступность, подтверждённая на дату проверки.

Основные первоисточники: использование Copilot Code Review, настройка Copilot Code Review и MCP для Copilot в репозитории. Для этого материала использованы только названия функций и поведение, прямо описанные GitHub. Тарифы и цены не приводятся: они не нужны для выполнения процедуры и могут меняться.

Перед началом убедитесь, что у вас есть административные права для нужного уровня — репозитория или организации. Сделайте снимок текущей конфигурации: запишите значение переключателей, имя ruleset, его targets и обязательные checks. Такой baseline позволяет отличить эффект новой настройки от уже существующей политики и быстро вернуть рабочее состояние.

Пошаговая настройка

1. Выберите PR, где внешний контекст проверяем: например, описание ссылается на issue с точными acceptance criteria.
2. Убедитесь, что в Settings → Copilot → Code review разрешено использование MCP tools для review.
3. Добавьте в описание PR конкретный идентификатор issue или incident, доступный через настроенный MCP, без секретов.
4. Запросите Copilot review обычным способом и дождитесь завершения.
5. Откройте каждый релевантный review comment и проверьте атрибуции внизу: ссылка должна указывать на использованный внешний контекст.
6. В timeline PR найдите связанную review session и откройте её.
7. В session logs найдите tool calls: сопоставьте имя инструмента, входной идентификатор и полученный контекст с выводом комментария.
8. Проведите негативный тест на безопасном примере без ссылки на внешний объект и сравните, исчезла ли MCP-атрибуция. Не публикуйте ложный вывод, если лог не подтверждает вызов.

После сохранения не переходите сразу к массовому включению. Откройте страницу ruleset или Code review повторно и убедитесь, что значение сохранилось. Затем проверяйте поведение на отдельной ветке и безопасном PR. В описании PR укажите цель теста, ожидаемый эффект и человека, который подтвердит результат. Это превращает разовую настройку в проверяемую процедуру.

Готовый шаблон для копирования

Скопируйте карточку в issue, change request или описание тестового PR и заполните угловые скобки. Она одновременно служит планом работы и журналом проверки.

Проверка MCP-attribution
PR: <URL>
Внешний объект: <issue/incident ID>
Ожидаемый MCP server/tool: <имя>
Комментарий Copilot: <URL>
Attribution внизу комментария: <URL или отсутствует>
Review session: <URL>
Tool call в session log: <имя + безопасный фрагмент входа>
Вывод подтверждён: да/нет
Причина, если нет: <что именно отсутствует>
Дата проверки продукта: 13.09.2026
Ссылка на официальную документацию: https://docs.github.com/en/copilot/how-tos/copilot-on-github/set-up-copilot/configure-code-review

Если команда использует внутреннего ассистента для подготовки change request, можно дать ему следующий промпт. Он не просит модель менять настройки и поэтому оставляет действие администратору:

Подготовь план изменения GitHub Copilot Code Review по карточке ниже.
Не придумывай текущие значения, права, тарифы или результат проверки.
Раздели ответ на: предпосылки, точный путь в интерфейсе, позитивный тест,
негативный тест, наблюдаемые критерии успеха, риски и откат.
Если в карточке нет факта, пометь его как «нужно проверить».

<вставьте заполненную карточку>

Реалистичный пример входа и результата

Вход. PR #52 заявляет исправление ISSUE-741: таймаут должен быть 3 секунды. Issue доступен GitHub MCP, а diff устанавливает 30 секунд.

Ожидаемый результат. Если MCP использован, комментарий о несоответствии содержит атрибуцию, а review session показывает tool call, получивший ISSUE-741. Если этих свидетельств нет, результат нельзя приписывать MCP.

Результат считается подтверждённым только по интерфейсу GitHub и, где применимо, по timeline, merge box, атрибуциям или session log. Фраза модели, предположение администратора или отсутствие комментариев не являются достаточным доказательством. Сохраните URL тестового PR и краткую запись того, что наблюдалось до и после изменения.

Как провести позитивный и негативный тест

Позитивный тест должен попадать точно в разрешённую область: выбранный репозиторий, целевая ветка, подходящие пути и завершённые обязательные checks. До запуска запишите ожидаемое событие — например, автоматическое назначение Copilot, появление approval, видимый комментарий или MCP tool call.

Негативный тест меняет ровно одно условие. Это может быть исключённый репозиторий, файл вне glob, отсутствующий внешний идентификатор или выключенный переключатель. Если одновременно изменить несколько условий, невозможно понять причину результата. Для обоих тестов используйте безопасные изменения, которые можно закрыть без merge.