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

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

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

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

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

Не считайте текстовое сообщение агента доказательством. Подтверждение — это 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. Затем повторите один минимальный вызов.

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

• Считать list командой подключения.
• Игнорировать группировку по источнику.
• Публиковать сырой JSON с внутренними путями.
• Удалять неизвестный server до определения его владельца.

Общая опасная ошибка — включить 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

Меняет ли list конфигурацию?

Нет, это команда инвентаризации.

Как увидеть disabled в JSON?

Проверить поле enabled со значением false.

Показываются ли plugin servers?

Да, официальная справка прямо включает plugin-provided servers.

Зачем два снимка?

Они подтверждают, что изменился ровно ожидаемый элемент.

Итог

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