Как проверить MCP до подключения: 10 шагов безопасности для агента в 2026

Раз в неделю присылаю разбор одного MCP-инструмента и ошибок, которые нашли на практикуме. Подпишись: без спама, отписка в один клик.

Что такое MCP-сервер

MCP расшифровывается так: Model Context Protocol. Anthropic описывает его как открытый протокол, который стандартизирует способ передачи контекста приложениям с большими языковыми моделями.

MCP-сервер - это отдельная программа-посредник, а не базу данных или API. Она связывает ИИ-приложение с внешней системой и открывает описанный набор возможностей.

Для Claude Code MCP-сервер может дать доступ к инструментам, базам данных и API. Файловый сервер работает с каталогами. SQLite Explorer читает структуру базы и выполняет запросы. Другой сервер может обращаться к GitHub, почте или браузеру.

Здесь и появляется главный риск. По названию «filesystem» нельзя понять, ограничивается ли сервер чтением файлов или также создаёт, изменяет и удаляет их. Слово «browser» тоже не описывает весь набор действий: сервер может не только читать страницы. Реальные действия видны в списке tools, их описаниях, параметрах и фактическом поведении.

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

Как устроен MCP-сервер?

Участники связки разделены:

• Агент - модель, которая получает задачу и выбирает дальнейшие действия.
• Клиент - программа, подключённая к MCP-серверу и передающая его возможности агенту.
• Сервер - программа, которая описывает доступные tools, resources и prompts.
• Внешняя система - файлы, база данных, API, браузер или другой источник.

Для связи используются stdio и Streamable HTTP. При stdio клиент запускает сервер как дочерний процесс. Сервер читает сообщения из stdin и пишет ответы в stdout.

При Streamable HTTP сервер работает отдельно, а клиент обращается к его MCP endpoint через HTTP. Для удалённого соединения появляются дополнительные вопросы: адрес сервера, авторизация, Bearer-токен и права OAuth. SSE тоже встречается в MCP, но в спецификации он обозначен как устаревший способ.

У сервера есть три типа возможностей.

• Tools - исполняемые функции. Модель может вызвать их, чтобы получить информацию или выполнить действие.
• Resources - данные и контекст. Это могут быть файлы, схемы баз данных и другие данные, доступные через URI.
• Prompts - готовые шаблоны и инструкции. Пользователь выбирает их, чтобы направить взаимодействие с моделью.

Разница не формальная. Чтение ресурса не равно вызову инструмента. Наличие prompt не означает, что сервер получил доступ к данным. А tool может не только читать, но и изменять внешнюю систему.

MCP использует JSON-RPC 2.0. Жизненный цикл соединения состоит из инициализации, рабочей фазы и завершения. На этапе работы клиент может запросить список tools и resources, а затем вызвать нужный метод.

Как MCP используется в ИИ-агентах?

Упрощённая последовательность выглядит так:

1. клиент устанавливает соединение с сервером;
2. сервер сообщает доступные возможности;
3. клиент передаёт агенту описания tools;
4. модель сопоставляет задачу с описаниями;
5. агент вызывает один или несколько инструментов;
6. сервер возвращает результат или ошибку.

Модель может построить цепочку. Например, сначала найти файл, потом прочитать его, затем изменить содержимое и записать результат. MCP не превращает эту цепочку в заранее заданный сценарий.

В официальном разделе безопасности MCP это сформулировано прямо.

Модель может вызывать инструменты способом, который пользователь явно не запрашивал. Вызовы инструментов зависят от того, как языковая модель интерпретирует намерение пользователя. Несколько инструментов могут вызываться последовательно. Это ожидаемое поведение.

• Официальный раздел безопасности MCP

Поэтому запрос «покажи таблицы» не должен автоматически означать доступ к изменению базы. Если сервер одновременно предлагает list_tables, run_query, insert_row и drop_table, модель видит весь этот набор, если конфигурация его не ограничила.

Ещё одна ловушка - подключённый tool может остаться неиспользованным. Агент сам выбирает, вызвать его или применить другой путь. Например, вместо специализированного поиска модель может использовать grep или чтение файла. MCP не гарантирует, что агент выберет конкретный инструмент в каждой подходящей ситуации.

Если нужен обязательный порядок, одного подключения недостаточно. Для конкретного клиента могут существовать hooks или ручное подтверждение. Это уже настройка клиента, а не универсальное свойство MCP.

В карточке перед подключением я фиксирую:

• какие tools доступны;
• какие из них читают данные;
• какие создают, меняют или удаляют данные;
• какие цепочки вызовов допустимы;
• нужен ли ручной approval перед write-операциями;
• что считается доказательством успешного вызова.

Что такое MCP-инструмент?

Спецификация MCP перечисляет поля описания tool:

• name - уникальное имя;
• description - назначение инструмента;
• inputSchema - схема входных параметров в JSON Schema;
• outputSchema - схема результата, если она есть;
• annotations - дополнительные сведения о поведении.

Смотри не только на имя. read_file звучит безопасно, но нужно проверить, какие каталоги доступны и какие параметры принимает инструмент. run_query может выполнять не только SELECT, если сервер не ограничивает SQL.

Чтение ресурса выглядит иначе. Ресурс имеет URI и читается через resources/read. Список ресурсов получается через resources/list. Ресурс может указывать на файл, схему базы или другой контекст.

Вызов действия выполняется через tools/call. В результате могут быть:

• content;
• structuredContent;
• isError.

Ошибки делятся на протокольные и ошибки выполнения. Протокольная ошибка возникает, например, при неизвестном tool или неверных аргументах. Ошибка выполнения возвращается в результате инструмента с флагом isError: true.

Я читаю карточку инструмента в таком порядке:

1. что он делает;
2. какие параметры обязательны;
3. какие данные получает;
4. что меняет;
5. что возвращает;
6. как сообщает об ошибке;
7. может ли вызвать сетевой адрес, отправить форму или затронуть локальные данные.

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

Что проверить перед подключением MCP?

Я бы заполнял карточку до первого запуска.

Источник и запуск

Фактура не даёт универсальной процедуры проверки владельца, репозитория и цепочки поставки. Поэтому я не буду изображать, что одного README достаточно. Зафиксируй источник установки, владельца, репозиторий и команду запуска. Если сервер запускается локально, проверь путь к исполняемому файлу.

Локальный процесс может видеть окружение и файлы, доступные этому процессу. Не передавай весь диск, домашнюю папку или каталог с .env, если задача требует одной тестовой директории.

Транспорт

Для первой проверки выбирай локальный stdio, если сервер это поддерживает. HTTP добавляет URL, авторизацию и сетевой периметр. У удалённого сервера проверь endpoint и способ передачи Bearer-токена.

Для HTTP MCP использует OAuth. Токен передаётся в заголовке:

Authorization: Bearer TOKEN

При отсутствии или недействительности авторизации сервер возвращает 401. Значение 403 указывает на недостаточные права или scopes.

Tools и resources

Получи фактический список tools через Inspector или CLI. Не ограничивайся списком из README. Для каждого инструмента запиши:

• имя;
• назначение;
• обязательные параметры;
• схему результата;
• возможные изменения;
• ошибку выполнения.

Для resources отдельно запиши URI и доступные операции чтения. Сервер может открывать не только функции, но и файлы, схемы базы данных и другие данные.

Права

MCP не задаёт обязательную CRUD-модель для каждого инструмента. Scopes и авторизация есть, но универсальной разметки «только чтение», «изменение», «удаление» для всех серверов нет.

Где поддерживается настройка инструментов, используй allowlist. Можно включить все tools, разрешить только выбранные или запретить опасные. Для отдельных инструментов можно задать собственные настройки.

{
  "type": "mcp_toolset",
  "mcp_server_name": "example-mcp",
  "default_config": {
    "enabled": false
  },
  "configs": {
    "read_issues": {
      "enabled": true
    }
  }
}

Начинай с одного read-only инструмента. Write-действия подключай только после отдельной проверки.

Секреты и сеть

Запиши, какие ключи и OAuth scopes получает сервер. Не клади секреты в текст промпта или открытый конфиг. Для fetch-инструмента проверь разрешённые домены, запрет локальных и приватных IP, защиту от cloud metadata endpoints и redirect-ов.

Данные, которые сервер хранит у себя, не определяются универсальным полем MCP. Нужны отдельные сведения о журналировании, хранении результатов и передаче данных. Если таких сведений нет, отметь это в карточке как неизвестное.

Остановка и ошибка

До подключения найди способ отключить сервер. Уточни, есть ли dry run, отмена действия и журнал вызовов. Стандартного sandbox или dry run для всех MCP-серверов нет.

Проверяй не только успешный сценарий. Нужен безопасный неверный параметр и понятный ожидаемый ответ об ошибке. Если сервер не объясняет, что произошло, я бы не выдавал ему доступ к рабочим данным.

Как проверить MCP до подключения агента?

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

   Создай тестовую папку или копию базы. Для файлового сервера разреши одну директорию. Копию database.db для SQLite используй вместо рабочего файла.

   Не передавай весь диск, домашний каталог или папку с .env. Первый запуск должен иметь доступ только к данным, которые не жалко испортить.

   Для SQLite задай границу заранее:

   Правило безопасной проверки SQLiteСкопировать промпт

   Покажи таблицы и выполни только SELECT-запросы.
   Не используй INSERT, UPDATE, DELETE, DROP или ALTER.
   Не изменяй структуру базы и не создавай новые данные.

2. Определи транспорт и команду запуска.

   Выясни, работает ли сервер через локальный stdio или удалённый Streamable HTTP. Для первой проверки выбери stdio, если он доступен.

   Если сервер запускается через npx, node или uv, проверь путь из окружения, где работает MCP-клиент:

   bash

   Скопировать

   which node
   which npx
   which uv

   Интерактивный терминал может видеть команды через NVM, .zshrc или .bashrc, а клиент запускает процесс напрямую. В таком случае используй полный путь к исполняемому файлу.

   json

   Скопировать

   {
     "mcpServers": {
       "example": {
         "command": "/Users/name/.nvm/versions/node/v22.14.0/bin/npx",
         "args": ["-y", "package-name"]
       }
     }

3. Запусти сервер в MCP Inspector.

   Inspector предназначен для тестирования и отладки MCP-серверов. Для Python-сервера командой mcp dev можно открыть сервер через MCP Inspector.

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

4. Получи фактический список tools.

   Открой вкладку Tools в Inspector. Запиши каждое имя, описание и параметры. Не принимай список из README за результат tools/list.

   Для каждого инструмента ответь:

   • что он читает;
   • что создаёт;
   • что меняет;
   • что удаляет;
   • какие параметры обязательны;
   • какой результат возвращает;
   • как выглядит ошибка.

   Рядом со статусом Connected должен быть понятный список доступных tools, а не одна отметка о соединении. Соединение само по себе не доказывает, что сервер вернул инструменты.

5. Проверь ресурсы отдельно.

   Посмотри, какие resources сервер объявляет и какие URI доступны. Проверь чтение одного безопасного ресурса через Inspector.

   Для файлового сервера минимальный запрос выглядит так:

   Проверка тестовой папкиСкопировать промпт

   Покажи список файлов в ~/mcp-test.
   Не создавай, не изменяй и не удаляй ничего.

   Если сервер показывает файлы за пределами разрешённого каталога, остановись и не подключай агента.

6. Выполни безопасный вызов.

   Выбери read-only tool с минимальным радиусом действия. Для SQLite запроси список таблиц и выполни только SELECT.

   Проверка SQLite на копииСкопировать промпт

   Покажи список таблиц в копии базы.
   Выполняй только SELECT.
   Не используй INSERT, UPDATE, DELETE, DROP или ALTER.
   Верни название выполненного инструмента и полученный результат.

   Сравни результат с тем, что должно быть в тестовой папке или копии базы. Слово «готово» доказательством не считается.

7. Проверь ошибочный параметр.

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

   Не проверяй ошибку удалением настоящего файла, записью в рабочую базу или отправкой формы. Для опасного инструмента стандартного dry run может не быть.

8. Проверь поведение агента отдельно.

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

   Подключённый MCP-инструмент не становится обязательным. Агент может выбрать другой путь. Если он использует grep вместо специализированного tool, это не обязательно ошибка подключения.

9. Ограничи доступ.

   Оставь только нужные инструменты. Где возможно, включи allowlist, read-only режим и подтверждение перед write-операциями.

   Начни с настройки «всё выключено, один инструмент включён». Потом добавляй доступ по одному и после каждого изменения повторяй проверку списка tools и безопасный вызов.

10. Прими решение по карточке.

    Выбери один вариант: подключить постоянно, подключить только выбранные tools, оставить read-only, запускать отдельно или не подключать.

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

Сколько инструментов можно подключить без перегруза?

Проблема появляется ещё до первого запроса. Каждый сервер добавляет в контекст имена tools, descriptions, параметры и схемы результатов. Модели приходится выбирать среди большего числа похожих функций.

Один из постоянных проблемных сценариев MCP - раздувание контекста. MCP хорошо работает с одним-двумя серверами, но при добавлении GitHub, Notion, Slack, Gmail и Linear модель получает большой список инструментов, схем, описаний и параметров.

• Обсуждение практиков MCP на Reddit

В практическом примере сервер с 34 tools сократили на 33 инструмента. Накладные расходы контекста упали примерно с 20 тысяч до 1 тысячи токенов. Вызовов на запрос стало 1 вместо 3 и более. Размер результата уменьшился на 74%.

Другой пример показывает масштаб: четыре сервера - GitHub, Linear, Context7 и Playwright - могли добавить более 60 тысяч токенов и свыше 100 определений tools. При конкретной задаче агенту часто нужны только два-три инструмента.

Поэтому я ориентируюсь на четыре показателя:

• сколько tools он объявляет;
• сколько токенов занимают описания;
• сколько вызовов нужно для обычной операции;
• насколько велик типичный результат.

Если сервер предлагает tool search или lazy loading, это тоже записывай. Универсальной процедуры замера расхода токенов для всех клиентов нет. Если измерения нет, тестируй сервер отдельно и не добавляй его в постоянную конфигурацию вслепую.

Что делать, если MCP подключился, но инструментов нет?

Сначала разведи симптомы.

Connected и ноль tools означают, что клиент связался с сервером, но не получил ожидаемый список. Возможные причины:

• сервер не ответил на tools/list;
• сервер не объявляет capability tools;
• tools отфильтрованы;
• инструменты отложены до поиска;
• загружена другая версия конфигурации;
• команда запуска недоступна в окружении клиента.

Проверь область конфигурации. MCP может быть добавлен на уровне local, project или user. Поэтому сервер не всегда виден в другом проекте. Файл конфигурации в одном проекте не означает доступность сервера во всех остальных.

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

Открой /mcp и посмотри не только статус соединения, но и количество tools. Затем запусти MCP Inspector и проверь вкладку Tools. Если Inspector видит инструменты, сервер, скорее всего, отвечает, а проблема находится в клиенте, настройках фильтрации или загрузке.

Для диагностики Claude Code используй:

claude --debug mcp

Посмотри путь к команде и сообщение об ошибке. Относительный путь может разрешаться не из папки конфигурации. Клиент также может не видеть npx, node или uv, хотя эти команды работают в терминале. Проверь их через which и укажи полный путь.

Отдельный симптом - часть tools появляется случайно или исчезает после перезапуска. Для него нет универсального подтверждённого решения. Если конфигурация проверена, Inspector видит tools, а клиент показывает их непредсказуемо, это может быть проблема клиента или механизма deferred loading и tool search.

Не лечи эту поломку подключением ещё пяти серверов. Сначала зафиксируй фактический список в Inspector, затем сравни его со списком в клиенте.

Какие опасные действия может скрывать MCP-инструмент?

Файловый инструмент проверяй по реальным операциям, а не по названию. Вопросы должны быть прямыми:

• может ли он создавать файл;
• может ли менять существующий;
• может ли удалять;
• какие каталоги разрешены;
• видит ли .env;
• может ли запускать команды.

Браузерный tool имеет особенно большой радиус действия.

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

• Issue по server-puppeteer

Это просто «почитать страницу». Браузер может открыть URL, выполнить код страницы, отправить форму, сделать скриншот или обратиться к локальной сети. Перед подключением выясни, нужны ли все эти действия для задачи.

Fetch-инструмент тоже нельзя считать безопасным только потому, что он возвращает текст.

У mcp-server-fetch нет защиты от SSRF; на хостах агентов в облаке это может привести к утечке учётных данных IAM.

• Issue по mcp-server-fetch

Для сетевого tool проверь разрешённые домены, запрет локальных и приватных IP, защиту cloud metadata endpoints, redirect-ы и журналирование фактических URL.

Отдельный класс рисков связан с текстом. В описании tool, prompt, resource или результате может оказаться инструкция, которая меняет поведение агента. Google Cloud называет такие риски tool poisoning, prompt injection и dynamic tool manipulation.

Протокол не гарантирует, что текстовый результат безопасен для дальнейшего использования моделью. Без воспроизводимого теста результата нельзя доказать отсутствие prompt injection.

На этом месте я останавливаюсь перед выдачей доступа. Если инструмент может менять данные, обращаться к приватной сети, отправлять сообщения или работать с секретами, сначала нужен ограниченный тест и ручное подтверждение опасных действий.

Вопросы и ответы