MCP-сервер: как проверить перед подключением за 10 шагов

Что именно добавляет MCP-сервер?

MCP-сервер может открыть агенту prompts, resources и tools. Для проверки особенно важны tools, потому что они позволяют получать данные или выполнять действия. Resources и prompts тоже нужно просмотреть: их содержимое попадает в контекст и может повлиять на дальнейшие решения агента.

Имя вроде search или get_data мало что доказывает. Описание, схема параметров и фактическая реализация могут давать более широкие возможности. Просмотрите весь инвентарь до выдачи рабочих учётных данных.

Если вы пока выбираете между файлом инструкций и внешним подключением, начните со статьи AGENTS.md, CLAUDE.md, SKILL.md и MCP: что выбрать. Здесь MCP уже выбран, а объект проверки - конкретный сервер.

Чем локальный MCP-сервер отличается от удалённого?

Локальный stdio-сервер запускается как процесс на вашей машине, а удалённый сервер принимает сетевые запросы. В первом случае критичны команда запуска, пакет, переменные окружения, файловая система и сеть. Во втором добавляются домен, TLS, оператор сервиса, OAuth и правила хранения отправленных данных.

Документация Claude Code описывает HTTP как основной вариант для удалённых серверов и stdio для локальных процессов. Старый SSE transport помечен как deprecated. Команды конкретного клиента меняются, поэтому перед подключением сверяйте его текущую документацию.

Как проверить источник и команду запуска?

Зафиксируйте владельца, официальный URL, точный endpoint или исполняемую команду, пакет и версию. Для локального сервера раскройте всю команду до исполнения. Для удалённого сопоставьте домен с официальным поставщиком и выясните, кто обслуживает инфраструктуру.

1. 1. Найдите владельца

   Сверьте официальный репозиторий, документацию, домен и канал раскрытия уязвимостей.

2. 2. Зафиксируйте поставку

   Запишите version, tag, commit, digest контейнера или дату выпуска.

3. 3. Раскройте команду

   Проверьте полный executable, args, package download, env и рабочую папку до запуска.

4. 4. Проверьте обновление

   Узнайте, как сервер обновляется и как вернуться к проверенной версии.

Команда npx с автоматической загрузкой, shell-скрипт по URL или контейнер с плавающим тегом могут быть удобны для демонстрации, но усложняют воспроизводимость. Не запускайте непонятный код только ради просмотра списка инструментов.

Как составить карту данных и действий?

Нарисуйте путь от запроса пользователя до конечной системы. Для каждого перехода запишите данные, права, возможное изменение состояния и владельца контроля. Карта нужна до первого вызова, иначе тест легко начнётся с лишним доступом.

Базовая цепочка выглядит так: пользователь -> AI-приложение -> MCP client -> MCP server -> файл, база, API или SaaS.

• Какие данные уходят на сервер и какие данные возвращаются?
• Какие файлы, сети и переменные окружения доступны локальному процессу?
• Какие внешние API вызывает сервер от имени пользователя?
• Какие действия читают, а какие создают, отправляют, изменяют или удаляют?
• Где хранятся access token и refresh token?
• Где человек увидит полные параметры чувствительного вызова?
• Что попадёт в журнал и как из него удаляются секреты и персональные данные?

Как проверить tools, resources и prompts?

Выгрузите полный инвентарь, затем разберите каждую возможность по назначению, входам, выходам и последствиям. Не доверяйте только названию или метке read-only. Для инструмента с изменением состояния нужен отдельный сценарий подтверждения.

Отдельно ищите произвольную shell-команду, любой URL, неограниченный файловый путь, сырой SQL или свободный recipient для отправки сообщения. Такой интерфейс может быть оправдан, но ему нужны более сильная изоляция, validation и ручной контроль.

OWASP рекомендует рассматривать описание и всю schema инструмента как возможную поверхность prompt injection. Результат tool call также нельзя считать доверенной инструкцией: он может содержать текст, который пытается изменить дальнейшее поведение агента.

Какие токены и OAuth scopes выдавать?

Создайте отдельную тестовую учётную запись или service account и выдайте минимальный набор scopes для одного сценария. Не используйте общий личный токен и не делитесь одним credential между разными MCP-серверами.

Актуальные требования авторизации MCP привязывают токен к целевому ресурсу. Сервер должен проверить, что токен выпущен именно для него. Передача входного токена дальше в сторонний API запрещена спецификацией: upstream получает отдельный токен своего назначения.

• Отдельный credential для сервера и тестового окружения.
• Read-only scope, если проверяется только чтение.
• Доступ только к тестовому проекту, папке, репозиторию или tenant.
• Короткий срок жизни токена, если провайдер это поддерживает.
• Хранение в keychain или secret store, а не в репозитории и открытом config.
• Понятная процедура отзыва сразу после теста.

Как изолировать первый запуск?

Первый запуск проходит без production, реальных клиентских данных и постоянных токенов. Локальный процесс получает отдельную рабочую папку и ограниченную сеть. Удалённый сервер работает с тестовым tenant. В клиенте оставляют один нужный инструмент и ручное подтверждение.

1. 1. Подготовьте данные

   Используйте искусственные или обезличенные записи.

2. 2. Выберите тестовую область

   Отдельный репозиторий, папка, база или tenant не должны содержать рабочие секреты.

3. 3. Изолируйте процесс

   Для local stdio используйте отдельного пользователя или контейнер и откройте только нужную папку.

4. 4. Ограничьте сеть

   Отключите её, если она не нужна, либо разрешите только заранее известные назначения.

5. 5. Оставьте один tool

   Остальные возможности временно отключите или запретите в клиенте.

6. 6. Включите approval

   Все вызовы, которые изменяют или отправляют данные, требуют ручного подтверждения.

7. 7. Сохраните evidence

   Запишите endpoint, команду, версию, scopes, tool calls, сетевые назначения и изменения файлов.

Если подключение поставляется вместе с Agent Skill или плагином, отдельно пройдите чек-лист проверки AI-навыка. MCP-проверка не подменяет чтение SKILL.md и связанных скриптов.

Какие три сценария прогнать?

Проведите позитивный, негативный и чувствительный сценарии. Позитивный показывает заявленную функцию. Негативный проверяет границы. Чувствительный сценарий должен остановиться на понятном подтверждении до изменения состояния.

1. 1. Позитивный сценарий

   Прочитайте одну тестовую запись или выполните безопасный поиск. Сопоставьте параметры вызова с журналом и проверьте, что соседние объекты не затронуты.

2. 2. Негативный сценарий

   Запросите объект вне разрешённой области или передайте некорректный URL, путь или идентификатор. Ожидаемый результат - отказ без раскрытия лишних данных.

3. 3. Чувствительный сценарий

   Смоделируйте отправку, изменение или удаление тестовой записи. Клиент должен показать действие и полные параметры до выполнения. Отмена оставляет состояние неизменным.

Подход к одинаковым критериям и изолированным запускам подробнее описан в статье как оценить эффективность Agent Skill. Для MCP объект измерения другой, но дисциплина теста остаётся полезной.

Что считать красным флагом?

Остановите подключение, если источник или команда не подтверждены, сервер требует непропорциональные права, скрывает состав инструментов, расходится с заявленным поведением либо не оставляет человеку контроля над чувствительным действием.

• Плавающая версия или пакет с похожим названием без подтверждённого владельца.
• Секрет предлагается положить в общий config, репозиторий или историю shell.
• Для чтения одной тестовой записи нужен административный токен.
• Инструмент с нейтральным названием может отправлять, удалять или менять данные.
• Schema принимает произвольную команду, URL или путь без ограничений.
• Tool response содержит указания отключить ограничения или передать данные другому серверу.
• Нет подтверждения чувствительных действий или его можно обойти.
• Фактические сетевые обращения и файлы не совпадают с документацией.
• Нельзя отозвать доступ, отключить сервер или получить журнал вызовов.

Известный поставщик и запись в каталоге снижают часть неопределённости, но не заменяют проверку конкретной версии. Anthropic предупреждает, что Directory review не означает security audit MCP-сервера.

Как принять решение после проверки?

Привяжите решение к версии, конфигурации и тестовой области. Возможны четыре исхода: отклонить, вернуть на доработку, оставить в ограниченном пилоте или подключить с постоянными контролями. Обновление сервера, endpoint, schema или scopes открывает новый цикл проверки.

Принцип похож на выпуск обновления Agent Skill: новая поставка требует нового diff и регрессионной проверки. Порядок описан в статье как обновлять Agent Skill.

Можно ли считать официальный MCP-сервер безопасным?

Официальный источник даёт понятного владельца и историю изменений, но не доказывает отсутствие ошибок или соответствие вашему окружению. Проверяйте конкретную версию, права, данные и сценарии использования.

Каталожная проверка, подпись релиза или известный поставщик дополняют evidence. Least privilege, approval и испытание конкретной версии всё равно остаются обязательными контролями для чувствительного процесса.

Достаточно ли read-only инструмента?

Нет. Метка или название помогают классифицировать tool, но фактические права зависят от реализации и credential. Read-only вызов всё равно может раскрыть чувствительные данные или вернуть вредоносный текст в контекст агента.

Сопоставьте аннотацию инструмента с его schema, scopes и наблюдаемым поведением. Критическое ограничение проверяют по конечному состоянию и журналу, а не по одному флагу.

Что опаснее: local stdio или remote HTTP?

У них разные границы риска. Local stdio запускает код с доступами локального процесса. Remote HTTP передаёт данные стороннему оператору и требует проверки transport, OAuth и политики хранения. Выбирайте по задаче и ограничивайте соответствующую область.

Для первого теста local server изолируют по файловой системе и сети, remote server - по tenant, scopes и типу передаваемых данных. Ни один transport сам по себе не снимает необходимость проверки.

Нужно ли читать исходный код MCP-сервера?

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

Начните с entrypoint, регистрации tools, работы с credentials, сетевых вызовов и файловых операций. Большой объём кода повышает ценность автоматического анализа, dependency review и ограниченного теста, но не отменяет ручного решения владельца процесса.

Когда повторять проверку?

Повторите проверку после изменения версии, endpoint, команды запуска, зависимостей, tools/resources/prompts, OAuth scopes, клиента или оператора сервиса. Для постоянно используемого сервера назначьте плановую дату review.

Храните дату, версию и принятое решение рядом с конфигурацией. Если сервер изменился без сопоставимой версии или changelog, временно верните его в ограниченный режим.

Где сверить требования MCP и безопасности?

Для архитектуры и авторизации используйте текущую спецификацию MCP. Для продуктового поведения сверяйтесь с документацией своего клиента. NSA и OWASP дают дополнительные рекомендации по least privilege, изоляции, validation, approval и журналированию.

• Выпуск MCP 2026-07-28Изменения transport и авторизации в актуальном выпуске.
• Примитивы MCP-сервераPrompts, resources и tools.
• MCP authorization security considerationsAudience binding, token validation и запрет token passthrough.
• Claude Code MCPTransports, scopes, OAuth и project approval.
• NSA MCP Security Design ConsiderationsLeast privilege, изоляция и контроль цепочек выполнения.
• OWASP MCP Security Cheat SheetПрактические проверки tools, credentials, sandbox, approval и logs.

Этот чек-лист уменьшает неопределённость конкретного подключения, но не доказывает отсутствие всех уязвимостей. Для чувствительного процесса добавьте профильный security review и повторную проверку после изменений.