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

> MCP подключает ИИ-агента к внешним инструментам и данным. Показываю, как проверить сервер, права и опасные действия до выдачи доступа.

Источник: https://vibeceh.ru/guides/mcp-proverit-instrument-agenta-do-vydachi-dostupa
Автор: Сергей Мазур · опубликовано 2026-08-12

[MCP](/concepts/mcp) - это способ подключить ИИ-агента к внешним инструментам и данным. Например, к файлам, базе или API. Агент получает возможность выполнять действия в рамках выданных прав. Поэтому mcp стоит проверять до подключения: иначе модель сможет изменить ресурс, отправить форму или вызвать лишний инструмент.

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

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

MCP-сервер стоит между [ИИ-агентом](/concepts/agent) и внешней системой. Он сообщает агенту, какие инструменты и данные доступны, принимает вызовы и возвращает результат. Подключение MCP-сервера выдаёт доступ к действиям, базам данных и API, поэтому проверять нужно конкретные полномочия и возможные последствия вызова.

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

MCP - это открытый протокол, который стандартизирует передачу контекста приложениям с большими языковыми моделями. Думай о MCP как о USB-C для ИИ-приложений.

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

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

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

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

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

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

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

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

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

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

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

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

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

| Возможность | Назначение | Кто вызывает | Изменяет данные |
|---|---|---|---|
| Tools | Исполняемые функции | Модель | Может |
| Resources | Данные и контекст через URI | Модель через `resources/read` | Нет |
| Prompts | Шаблоны и инструкции | Пользователь | Нет |

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

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

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

при подключении MCP-клиент передаёт агенту список доступных инструментов и их схемы. Во время выполнения модель выбирает подходящий tool, передаёт параметры и получает результат. Она может вызвать несколько tools подряд. Подключённый инструмент не становится обязательным: агент способен выбрать другой путь в рамках выданных ему возможностей.

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

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

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

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

> Модель может вызывать инструменты способом, который пользователь явно не запрашивал. Вызовы инструментов зависят от того, как языковая модель интерпретирует намерение пользователя. Несколько инструментов могут вызываться последовательно. Это ожидаемое поведение.
> - [Официальный раздел безопасности MCP](https://github.com/modelcontextprotocol/modelcontextprotocol/security)

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

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

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

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

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

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

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. может ли вызвать сетевой адрес, отправить форму или затронуть локальные данные.

Переводи каждый tool в последствия: «прочитать файл», «изменить файл», «удалить файл», «отправить форму», «обратиться к приватному адресу». Если последствие неясно, доступ лучше не выдавать.

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

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

до запуска MCP проверь источник сервера, транспорт, фактический список tools и resources, требуемые секреты, OAuth scopes, разрешённые каталоги и сетевые адреса. Отдельно выясни, какие действия можно ограничить до read-only, как включить только нужные tools и как быстро отключить сервер при ошибке.

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

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

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

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

### Транспорт

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

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

```http
Authorization: Bearer TOKEN
```

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

### Tools и resources

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

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

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

### Права

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

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

```json
{
  "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 до подключения агента?

сначала изолируй тестовую папку или копию базы, затем выбери транспорт и получи реальный список tools через MCP Inspector или CLI. После этого проверь описания, выполни безопасный read-only вызов, отдельно проверь ошибку и только потом решай, какие права можно выдать агенту.

![Кот с лапой у морды смотрит на три шага проверки MCP в тестовой среде.](https://s3.regru.cloud/crossmark/statejnik/images/guides/mcp-proverit-instrument-agenta-do-vydachi-dostupa/kadr-1.webp)

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

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

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

   

Выясни, работает ли сервер через [локальный `stdio` или удалённый Streamable HTTP](/guides/mcp-stateless-transport). Для первой проверки выбери `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"]
       }
     }
   ```

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

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

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

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

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

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

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

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

   

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

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

   

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

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

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

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

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

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

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

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

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

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

универсального безопасного числа tools нет. Перегруз начинается не только от количества, но и от размера описаний, схем и результатов. В одном разборе 34 инструмента занимали около 20 тысяч токенов, а после сокращения осталось около 1 тысячи. Число вызовов снизилось с 3 и более до 1, размер результата - на 74%.

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

> Один из постоянных проблемных сценариев MCP - раздувание контекста. MCP хорошо работает с одним-двумя серверами, но при добавлении GitHub, Notion, Slack, Gmail и Linear модель получает большой список инструментов, схем, описаний и параметров.
> - [Обсуждение практиков MCP на Reddit](https://www.reddit.com/r/mcp/comments/1tle6gl/reducing_context_window_efficiently_in_mcp_heres/)

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

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

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

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

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

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

статус `Connected` подтверждает соединение, но не подтверждает наличие tools. Проверь область конфигурации, перезапусти клиента, открой `/mcp`, посмотри вкладку Tools в MCP Inspector и запусти `claude --debug mcp`. Если Inspector видит tools, а клиент показывает их непредсказуемо, причиной может быть проблема клиента или механизма загрузки.

![Собака рассматривает карточки диагностики подключения без доступных инструментов.](https://s3.regru.cloud/crossmark/statejnik/images/guides/mcp-proverit-instrument-agenta-do-vydachi-dostupa/kadr-3.webp)

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

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

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

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

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

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

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

```bash
claude --debug mcp
```

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

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

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

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

MCP-инструмент может выполнять действия от имени пользователя и менять ресурсы необратимым образом. Файловый сервер способен изменять и удалять данные, браузерный tool - отправлять формы и обращаться к приватной сети, fetch-инструмент - создавать риск SSRF. Описания, prompts, resources и результаты также могут содержать prompt injection.

![Мужчина прикрывает лицо рядом с карточками опасных действий MCP-инструмента.](https://s3.regru.cloud/crossmark/statejnik/images/guides/mcp-proverit-instrument-agenta-do-vydachi-dostupa/kadr-2.webp)

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

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

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

> Браузерная автоматизация через MCP имеет высокий уровень воздействия: она может переходить к произвольным адресам, выполнять JavaScript на страницах, делать скриншоты, отправлять формы и обращаться к локальным или приватным сетевым целям, если ограничения не заданы.
> - [Issue по server-puppeteer](https://github.com/modelcontextprotocol/servers/issues/4118)

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

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

> У mcp-server-fetch нет защиты от SSRF; на хостах агентов в облаке это может привести к утечке учётных данных IAM.
> - [Issue по mcp-server-fetch](https://github.com/modelcontextprotocol/servers/issues/4143)

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

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

MCP открывает новые возможности для ИИ-систем, но также создаёт риски: отравление инструментов, prompt injection и динамическая подмена инструментов. Это может привести к утечке данных, подмене личности и злоупотреблению ИИ-системами.

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

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

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

MCP - это протокол связи между AI-приложением, клиентом, сервером и внешней системой. Через него агент получает описания tools, resources и prompts, а затем может читать данные или вызывать действия. Безопасность зависит не только от протокола, но и от конкретного сервера, его прав, окружения и настроек клиента.

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

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

MCP использует JSON-RPC 2.0. Для транспорта спецификация определяет `stdio` и Streamable HTTP. При `stdio` клиент запускает сервер как дочерний процесс. SSE тоже встречается, но обозначен как устаревший транспорт.

Формат конфигурации зависит от клиента. Фактический список tools удобно смотреть через MCP Inspector во вкладке Tools. Для Claude Code дополнительно можно использовать `/mcp` и диагностику `claude --debug mcp`. Описание каждого инструмента приходит в его схеме, а не только в названии сервера.

Да. Для Claude Code используется `claude --debug mcp`, а для Python-сервера команда `mcp dev` позволяет тестировать сервер через MCP Inspector. CLI помогает проверить запуск, путь к команде и ошибки окружения до выдачи доступа агенту.

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

Модель сопоставляет задачу с именами, описаниями и схемами доступных tools. Она может выбрать один tool, несколько tools подряд или другой путь, например встроенный поиск. MCP не гарантирует обязательный вызов конкретного инструмента.

Клиент устанавливает соединение, проходит инициализацию и получает сведения о возможностях сервера. Затем сервер может передать список tools, resources и prompts. После этого агент получает доступ к разрешённым действиям и данным, а не просто отметку об установленной интеграции.

MCP системы связывают агента с файлами, базами данных, API, браузером, почтой и другими внешними источниками. Конкретный набор зависит от сервера. Проверяй URI ресурсов, список tools, сетевые адреса, секреты и права.

Проверь область конфигурации `local`, `project` или `user`, команду запуска, полный путь к `node`, `npx` или `uv`, транспорт, переменные окружения, разрешённые tools и каталоги. После изменения конфига сделай полный перезапуск клиента.

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

- [Model Context Protocol (MCP) - Anthropic](https://docs.anthropic.com/en/docs/mcp)
- [Connect Claude Code to tools via MCP](https://docs.anthropic.com/en/docs/claude-code/mcp)
- [MCP connector](https://docs.anthropic.com/en/docs/agents-and-tools/mcp-connector)
- [Server Features Overview - Model Context Protocol](https://modelcontextprotocol.io/specification/2025-06-18/server)
- [Tools - Model Context Protocol](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)
- [Resources - Model Context Protocol](https://modelcontextprotocol.io/specification/2025-06-18/server/resources)
- [Transports - Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports)
- [Authorization - Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)
- [MCP Inspector](https://modelcontextprotocol.io/docs/tools/inspector)
- [MCP servers not showing in Claude](https://www.reddit.com/r/ClaudeAI/comments/1n35e7p/mcp_servers_not_showing_in_claude_mcp_list_or_mcp/)
- [How we cut MCP context by 95%](https://dev.to/michael_rakutko/how-we-cut-mcp-context-by-95-and-stopped-wasting-the-teams-time-7hg)
- [Reducing context window efficiently in MCP](https://www.reddit.com/r/mcp/comments/1tle6gl/reducing_context_window_efficiently_in_mcp_heres/)
- [Browser automation exposed as an MCP tool](https://github.com/modelcontextprotocol/servers/issues/4118)
- [mcp-server-fetch lacks SSRF protection](https://github.com/modelcontextprotocol/servers/issues/4143)
- [How to secure your remote MCP server on Google Cloud](https://cloud.google.com/blog/products/identity-security/how-to-secure-your-remote-mcp-server-on-google-cloud)