TNWS AI

Гайд · TNWS AI

Как проверить один MCP-сервер через copilot mcp get

GitHub CopilotCopilot#GitHub Copilot#Copilot CLI#MCP
6 мин—

Диагностика конкретного MCP server командой copilot mcp get: status, tools, JSON-вывод, источник plugin и проверка без утечки секретов.

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

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

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

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

Проверено 13 сентября 2026 года. copilot mcp get <name> [--json] показывает конфигурацию и tools конкретного server. Для plugin-provided server вывод также включает имя и версию source plugin; текстовый формат содержит строку Status: Enabled/Disabled.

Точные команды сверены с официальной 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.

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

  1. Сначала выполните copilot mcp list, чтобы скопировать точное имя.
  2. Запустите copilot mcp get "SERVER NAME"; используйте кавычки для пробелов.
  3. Проверьте строку Status и источник конфигурации.
  4. Повторите copilot mcp get "SERVER NAME" --json > server.json для структурированного отчёта.
  5. Сверьте tools с минимально необходимым набором.
  6. Для plugin server зафиксируйте source plugin name/version из фактического вывода.
  7. Не применяйте --show-secrets в общем терминальном логе.
  8. После диагностики удалите server.json, если он раскрывает внутренние endpoint или пути.

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

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

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

Server: <точное имя>
Команда: copilot mcp get "<name>" --json
Status: <Enabled/Disabled>
Source: <user/workspace/plugin>
Source plugin/version: <если есть>
Tools: <список>
Лишние tools: <список>
Секреты в отчёте: отсутствуют
Дата проверки официальной документации: 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 Issue Tracker; нужно подтвердить, что он enabled и предоставляет только read_issue/search_issues.

Ожидаемый результат. Get-вывод показывает точный status и tools. Если обнаружен create_issue, инженер фиксирует избыточное право и отдельно меняет фильтр, не выдавая просмотр за исправление.

Не считайте текстовое сообщение агента доказательством. Подтверждение — это list/get, JSON-поле, отсутствие tool в новой session, успешный безопасный вызов, явный отказ или audit event. Сохраните только несекретные признаки: timestamp, server name, tool name, status и request ID.

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

Позитивный тест отвечает на вопрос: работает ли минимально разрешённая возможность? Используйте read-only tool и заранее известный объект. Запишите expected output без закрытого содержимого. Проверьте exit code и фактический status.

Негативный тест отвечает на вопрос: действительно ли граница закрыта? Меняйте только одно условие. Например, отключите server, обратитесь к исключённому tool или используйте invalid test credential. Если меняются одновременно transport, name и permissions, причина результата становится неясной.

Если тест завис, не повышайте timeout и права вслепую. Сначала разделите discovery, соединение, authentication и конкретный tool call. Проверьте DNS/TLS для remote transport, executable/args для stdio, enabled status и tool filter. Затем повторите один минимальный вызов.

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

  • Вводить имя без кавычек при пробелах.
  • Считать get командой enable.
  • Сохранять вывод с секретами в публичный issue.
  • Не сверять tools с задачей.

Общая опасная ошибка — включить all tools или вывести secrets ради быстрой диагностики. Это расширяет последствия prompt injection и оставляет credentials в логах. Используйте least privilege, краткоживущие токены, redaction и отдельный audit trail. После эксперимента удаляйте временные конфигурации и отзывайте credentials у issuer.

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

  • Свежий каталог публикаций проверен; title и slug уникальны.
  • Команда сверена с официальной документацией на 13.09.2026.
  • Server source, transport, name и enabled status записаны.
  • Разрешён только минимальный набор tools.
  • Секреты отсутствуют в prompt, history, screenshots и shared logs.
  • Позитивный read-only тест выполнен.
  • Негативный тест не изменяет production data.
  • Проверены list/get и новая CLI session.
  • Для remote вызова сопоставлен server audit log.
  • Откат и отзыв credentials выполнены или документированы.

FAQ

Можно ли получить JSON?

Да, добавьте --json.

Что видно у plugin server?

Имя и версия source plugin наряду с конфигурацией и tools.

Меняет ли get статус?

Нет, для изменения есть enable/disable.

Где увидеть статус в тексте?

В строке Status: Enabled или Disabled.

Итог

MCP-настройка считается готовой не после появления server в списке, а после подтверждения минимального tool set, безопасной аутентификации, позитивного и негативного тестов. Храните несекретную карточку вместе с изменением. При обновлении CLI повторяйте инвентаризацию и перепроверяйте официальный reference: команды, defaults и доступность могут измениться.

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

ГайдыGitHub CopilotCopilot13 сентября 2026

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

Инвентаризация MCP-серверов GitHub Copilot CLI через list и --json: источники, enabled status, plugins и безопасный diff.

6 мин 
ГайдыGitHub CopilotCopilot13 сентября 2026

Как добавить второй каталог в Copilot CLI через --add-dir

Безопасное использование --add-dir в GitHub Copilot CLI: доступ к файлам, доверенные skills/agents, относительные пути и проверка.

6 мин 
ГайдыGitHub CopilotCopilot13 сентября 2026

Как отключить MCP tools для Copilot Code Review

Отключение MCP-инструментов именно для Copilot Code Review, проверка последствий на тестовом PR и документирование отката.

6 мин 

Подбор

Какую нейросеть выбрать

Пройти опрос

Комментарии

Пока тихо. Скажите первое слово