Начните с проверки команды запуска и разрешений MCP-сервера, прежде чем подключать его к рабочему проекту в Claude Code. Затем проверьте, какие инструменты он предлагает агенту и нет ли в их описаниях скрытых указаний. MCP-сервер связывает ИИ с внешними инструментами: например, с репозиторием или базой данных. Ниже — порядок проверки, который поможет владельцу бизнеса обсудить риски с разработчиком, ограничить доступ и проверить подключение на тестовом проекте без рабочих ключей.
Что проверить до первого запуска MCP-сервера?
Попросите разработчика показать настройки подключения целиком. Для локального сервера нужны команда запуска, её аргументы и список переменных окружения. Для удалённого — адрес подключения и способ авторизации. Значения ключей в документ для обсуждения не вставляйте: достаточно названий и назначения.
Локальный MCP-сервер — это программа, которая работает с правами процесса, запустившего её. Поэтому подтверждение отдельных инструментов в Claude Code не заменяет проверку самой программы. Если команда сначала скачивает пакет, а затем запускает его, его код начинает работать ещё до того, как агент предложит воспользоваться инструментом.
- Найдите исходный проект и инструкцию автора. Сверьте название пакета в инструкции с названием в настройках подключения.
- Разберите команду запуска. Попросите объяснить каждый аргумент, особенно пути к папкам, запуск оболочки и загрузку дополнительных файлов.
- Уточните версию пакета. Для повторяемой проверки зафиксируйте конкретную версию вместо автоматического выбора самой свежей.
- Определите границы доступа: какую папку сервер видит и с какими внешними системами связывается.
- Подготовьте отдельный тестовый проект без рабочих ключей и доступа к действующему сайту.
Если назначение аргумента непонятно, отложите запуск до объяснения. Красивое описание проекта не отвечает на вопрос, зачем инструменту для чтения документации доступ ко всему домашнему каталогу.
Какими командами проверить подключения Claude Code?
В терминале выполните команду claude mcp list. Она поможет увидеть настроенные подключения. Чтобы посмотреть сведения об отдельном сервере, используйте claude mcp get ИМЯ_СЕРВЕРА: вместо ИМЯ_СЕРВЕРА подставьте имя из списка. Формат вывода зависит от установленной версии, поэтому при расхождениях откройте справку командой claude mcp --help.
Проверяйте подключения в контексте того проекта, где будет работать агент. Настройки бывают общими для пользователя и отдельными для проекта; незнакомый сервер мог появиться вместе с чужим репозиторием. Сопоставьте вывод команд с файлами настроек и выясните, откуда взялась каждая запись.
- Сверьте имя сервера с его назначением: название само по себе ничего не гарантирует.
- Для локального подключения проверьте исполняемый файл, аргументы и доступные ему переменные окружения.
- Для удалённого подключения сверьте адрес с инструкцией проекта и уточните, кто управляет сервером.
- Отметьте подключения, которые больше не нужны, и запланируйте их отключение после проверки зависимостей.
Вывод команд показывает настройки, но не доказывает безопасность кода сервера. Не пересылайте его целиком в публичный чат: сначала проверьте, нет ли там ключей. Сам порядок настройки разобран в статье о том, как подключить MCP-серверы к Claude Code для GitHub и базы данных.
Какие разрешения оставить для первой проверки?
Начните с доступа только на чтение и только к тестовым ресурсам. Если сервер нужен для просмотра задач в репозитории, не выдавайте ему право менять код. Если задача связана с отчётами, подготовьте отдельный тестовый набор данных и учётную запись без права записи.
Проверяйте доступ на каждом уровне. Ограничения в Claude Code управляют действиями агента, права ключа ограничивают внешнюю систему, а права операционной системы — локальную программу. Разрешение «читать» в одном месте не отменяет широких прав в другом.
- Запишите разрешённое действие обычной фразой, например: «читать файлы только из папки тестового проекта».
- Создайте отдельный ключ с правами под эту задачу, если внешняя система поддерживает такие ограничения.
- Оставьте подтверждение действий, которые меняют файлы, отправляют данные или запускают команды.
- Проверьте, что сервер не получает рабочие секреты из окружения процесса.
Отказ по правам на этом этапе полезен: он показывает, где проходит граница. Не снимайте все ограничения ради одного успешного запуска. Сначала выясните, какое действие заблокировано и нужно ли оно задаче. Для более широкой проверки проекта пригодится разбор прав доступа после вайбкодинга с Claude Code.
Как найти скрытые инструкции и проверить реакцию агента?
Попросите показать список инструментов сервера, их описания и параметры. Затем изучите примеры ответов на тестовые запросы. Агент читает эти тексты, поэтому указание сменить цель задачи может попасть к нему вместе с обычными данными. Такой приём называют внедрением инструкций, или prompt injection.
Ищите просьбы игнорировать прежние ограничения, прочитать файлы с ключами, отправить содержимое проекта на посторонний адрес или выполнить команду без согласования. Особенно внимательно смотрите на действия, которые никак не связаны с назначением сервера. Инструмент поиска документации не должен требовать секреты проекта для выдачи справки.
Внешний текст следует рассматривать как данные для задачи. Сам по себе он не даёт разрешения расширять доступ. При этом одна фраза в настройках агента не гарантирует защиту: нужны ограничения прав и проверка поведения.
- Подготовьте в тестовой папке безвредный файл с узнаваемой строкой и явно запретите агенту его читать.
- Смоделируйте ответ инструмента, который предлагает открыть этот файл. Используйте тестовую заглушку или помощь разработчика.
- Проверьте журнал действий: агент не должен вызывать инструмент чтения этого файла или передавать его содержимое дальше.
- Проверьте отказ внешней системы: попытка записи с ключом только для чтения должна завершиться без изменений.
- Повторите проверки после обновления сервера, его настроек или набора инструментов.
Успешный тест — это конкретное наблюдение: разрешённый запрос выполнен, запрещённый доступ не состоялся. Ответ агента «я соблюдаю правила» без проверки вызовов инструментов ничего не подтверждает. Чтобы отличать проверку от формальности, используйте подход из статьи о том, как проверить, что тесты Claude Code находят ошибки.
Такой порядок соответствует принципу управления процессом по отдельным задачам, который описывает материал «Как работать с Claude Code, Antigravity и Codex в 2026: база вайбкодинга» (Хабр). Сначала проверьте подключение на узкой задаче, затем отдельно согласуйте расширение доступа.
Типичные ошибки при проверке MCP-сервера
- Запускать незнакомую команду сразу в рабочем проекте. Причина риска — код получает доступ к доступным процессу ресурсам. Исправление: отдельное тестовое окружение без рабочих ключей.
- Выдавать полный доступ, чтобы убрать ошибку авторизации. Исправление: найти конкретное действие, которому не хватает прав, и проверить его необходимость.
- Считать описание инструмента гарантией его поведения. Исправление: сопоставить описание с вызовами, ответами и фактическими изменениями.
- Проверять только успешный сценарий. Исправление: добавить запрещённое чтение, отказ записи и ответ со скрытым указанием.
- Оставлять прежнее доверие после обновления. Исправление: повторить тесты для новой версии и сравнить разрешения.
Если проверку выполняет подрядчик, попросите передать настройки без секретов, перечень разрешений и результаты тестов. В задачу на технический аудит удобно включить проверку команды запуска, доступов и реакции агента на посторонние инструкции. Результатом должен быть список найденных проблем с исправлениями и повторной проверкой каждого пункта.
Следующий шаг на две минуты: запишите для одного MCP-сервера фразу «ему разрешено…» и перечислите только действия, которые нужны вашей задаче. Это станет исходным требованием для проверки разрешений.
