Гайд · TNWS AI

Как ограничить tools MCP-сервера в Copilot CLI

GitHub CopilotCopilot#GitHub Copilot #Copilot CLI #MCP

13 сентября 2026 6 мин—

Фильтрация MCP tools параметром --tools: точный список, *, пустой набор, позитивные и негативные проверки.

Задача и применимость

Этот гайд решает конкретную задачу: сократить доступный Copilot набор MCP tools до минимально необходимого для конкретной интеграции. Он нужен администраторам и разработчикам, которые управляют Model Context Protocol в GitHub Copilot CLI и хотят доказуемо контролировать источники, инструменты и права. MCP server расширяет возможности агента, поэтому даже read-only интеграцию следует рассматривать как границу доверия.

Перед началом зафиксируйте пользователя, copilot version, рабочий каталог и цель изменения. Не добавляйте server «на будущее»: перечислите один сценарий, нужные tools и владельца. Сделайте baseline через list/get, чтобы после операции увидеть ровно ожидаемое изменение. Если конфигурация командная, оформляйте её через review, а секреты храните отдельно.

Проверенные факты и первоисточники

Проверено 13 сентября 2026 года. Опция --tools <tools> принимает * для всех tools, comma-separated list либо пустую строку для none. Фильтр задаётся при copilot mcp add и должен проверяться через get/list и фактическую сессию.

Точные команды сверены с официальной Copilot CLI command reference и инструкцией GitHub по добавлению MCP servers. Изменяемые цены, тарифы и модели не используются. Указанные default или availability относятся к дате проверки; перед будущим изменением откройте источники заново.

Важно различать user, workspace, plugin и session configuration. Одинаковое имя может разрешаться по приоритету источников, а команда удаления может работать только для одного уровня. Поэтому в журнале изменения храните не только server name, но и source, transport, enabled status и список tools.

До изменения нарисуйте короткую цепочку данных: кто инициирует запрос, какой tool вызывается, куда уходит input и где сохраняется output. Отдельно отметьте, может ли server выполнять запись. Эта схема нужна не для формальности: по ней легко увидеть, что «чтение документации» на деле включает отправку фрагмента закрытого репозитория внешнему endpoint. Если маршрут данных неясен, не подключайте интеграцию до ответа владельца сервиса.

Также определите критерий остановки. При неожиданном tool, неизвестном source, ошибке TLS, запросе лишнего scope или появлении секрета в логе завершите session, отключите server и отзовите test credential. Не продолжайте эксперимент расширением прав: сначала устраните конкретную причину и снова начните с read-only проверки.

Модель угроз перед подключением

Проверьте четыре направления. Первое — происхождение executable или remote endpoint. Второе — данные, которые tools читают и меняют. Третье — credentials и место их появления в history/logs. Четвёртое — инструкции самого MCP server, способные влиять на поведение агента.

Для первой проверки используйте отдельный test credential с минимальным scope, безопасный read-only tool и объект без персональных данных. Не используйте production delete/update/create как негативный тест. Если нужен отказ, применяйте несуществующий тестовый ID, disabled state, исключённый tool либо недействительный временный credential.

Пошаговые действия

Получите полный tool catalog server в тестовой среде.
Разделите tools на read и write, отметив минимально нужные.
Добавьте server с точным фильтром, например --tools "search_docs,read_doc".
Проверьте get --json: доступны только выбранные имена.
Выполните позитивный read-only вызов.
Попробуйте безопасно обратиться к исключённому write tool и ожидайте отсутствия/запрета.
Не используйте *, если задача не требует всех возможностей.
После изменения server обновите карточку прав и повторите негативный тест.

После каждого изменения снова запускайте list/get и открывайте новую CLI session, если проверяется persistence. Старый процесс мог загрузить конфигурацию до изменения. Для remote server сопоставляйте client result с server-side audit log; для local process дополнительно проверяйте command path и отсутствие секретов в stdout/stderr.

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

Заполните карточку в change request:

Server: docs
All tools: search_docs, read_doc, update_doc, delete_doc
Allowed: search_docs,read_doc
Excluded: update_doc,delete_doc
CLI argument: --tools "search_docs,read_doc"
Позитивный тест: read_doc
Негативный тест: delete_doc недоступен
Дата проверки официальной документации: 13.09.2026
Источник: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference

Готовый prompt для внутреннего помощника:

Подготовь безопасный план изменения MCP в GitHub Copilot CLI.
Используй только факты из заполненной карточки. Не придумывай status,
tools, transport, token, exit code или успешный результат.
Раздели ответ на: baseline, точную команду, позитивный read-only тест,
негативный тест без изменения данных, критерии успеха, очистку и откат.
Любой отсутствующий факт пометь «нужно проверить вручную».

<вставьте карточку>

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

Вход. Документационный server предоставляет чтение и изменение, но Copilot нужен только для поиска и чтения.

Ожидаемый результат. Get и live session показывают два read tools. Delete/update недоступны; попытка негативного теста не меняет данные.

Как ограничить tools MCP-сервера в Copilot CLI

Задача и применимость

Проверенные факты и первоисточники

Модель угроз перед подключением

Пошаговые действия

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

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

Позитивный и негативный тест

Типичные ошибки

Чек-лист финальной проверки

FAQ

Как разрешить все tools?

Как указать несколько?

Можно ли разрешить none?

Как проверить фильтр?

Итог

Читайте также

Как добавить HTTP MCP-сервер в Copilot CLI

Как добавить локальный MCP-сервер в Copilot CLI

Как посмотреть MCP-серверы через copilot mcp list --json

Комментарии