# MCP: как ужать контекст при 58 инструментах через локальный CLI

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

Источник: https://vibeceh.ru/guides/mcp-ekonomichnyj-klient-dlya-podklyucheniya-instrumentov-agenta
Автор: Сергей Мазур · опубликовано 2026-08-14

Если ты ищешь **mcp**, то здесь речь про AI-направление: **mcp client** подключает инструменты и внешние данные к агенту, а **mcp агент** использует их внутри задачи. Я покажу локальное подключение инструментов и разницу между MCP-клиентом и MCP-сервером. Для экономии контекста возьмём `mcptoon`, который работает через CLI и выступает отдельным слоем между агентом и MCP-сервером.

## Что такое MCP-клиент и зачем он нужен агенту?

MCP-клиент связывает приложение с MCP-серверами, а агент решает, когда нужен внешний инструмент или данные. Сервер предоставляет действие, клиент передаёт запрос и возвращает ответ. `mcptoon` выступает CLI-слоем: агент запускает его команды, схемы лежат локально, а в контекст попадает нужный результат.

![Мужчина закрывает лицо рядом со схемой ролей агента, клиента и сервера.](https://s3.regru.cloud/crossmark/statejnik/images/guides/mcp-ekonomichnyj-klient-dlya-podklyucheniya-instrumentov-agenta/kadr-1.webp)

[MCP](/concepts/mcp) - открытый протокол связи LLM-приложений с внешними данными и инструментами. Сам по себе он не делает агента умнее. Он даёт ему доступ к тому, чего нет внутри диалога: внешнему контексту, данным сервиса или действию в этом сервисе.

Роли проще разделить так:

- **Агент** принимает задачу и решает, нужен ли внешний вызов.
- **MCP-клиент** связывает приложение с сервером и передаёт запрос.
- **MCP-сервер** предоставляет инструмент, данные или действие.

Представь задачу: проверить страницу сайта и вернуть её содержимое. Агент формулирует запрос. MCP-сервер знает, как получить страницу. Клиент передаёт вызов серверу и возвращает ответ агенту.

В обычной схеме агент заранее видит описания подключённых инструментов. Это удобно, пока инструментов мало. Когда их становится много, описания начинают занимать место в контексте ещё до первого действия.

`mcptoon` меняет границу. Он хранит MCP-схемы на диске в `~/.mcptoon/config.json`. Агент видит CLI-команду, запускает её и получает результат конкретного вызова. Это отдельный CLI-слой, который сохраняет MCP-схемы локально и не подменяет MCP-сервер.

MCP - открытый протокол, который обеспечивает бесшовную интеграцию LLM-приложений с внешними источниками данных и инструментами.

## Как агент использует MCP-инструменты?

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

В этой цепочке не надо держать в голове термины документации. Достаточно трёх объектов:

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

Агент не запускает MCP-сервер напрямую. Он запускает CLI-команду. Команда читает локальную конфигурацию, понимает, где лежит сервер, и передаёт ему параметры.

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

```bash
mcptoon call fetch fetch '{"url":"https://example.com"}' --toon
```

В ней два раза встречается `fetch`. Первый раз - имя сервера в конфигурации. Второй - имя инструмента на этом сервере. После JSON идёт формат компактного результата.

Сервер работает во время вызова. Это значит, что он не обязан постоянно висеть в фоне только ради того, чтобы агент знал о его существовании. Агент обращается к нему через команду, клиент поднимает нужную связку и возвращает ответ.

Так MCP даёт агенту не только действия, но и внешний [контекст](/concepts/kontekst). Агент может получить данные из сервиса, использовать результат в следующем шаге или выполнить действие там, где сам по себе доступа не имеет.

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

## Сколько контекста съедают MCP-инструменты?

Контекст расходуется не только на ответ модели. Сначала туда попадают схемы инструментов, затем результаты вызовов и промежуточные данные. В примере Anthropic переход от 150 000 к 2 000 токенам получен за счёт загрузки только нужных API и обработки данных вне контекста. В другом примере 58 инструментов из пяти серверов занимают примерно 55 000 токенов.

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

Anthropic отдельно описывает две статьи расхода:

1. Схема каждого инструмента загружается заранее.
2. Результат каждого вызова проходит через контекст модели.

В примере с 58 инструментами из пяти серверов описания занимают примерно 55 тысяч токенов до начала разговора. Это место уже нельзя использовать под задачу, файлы и ответы.

Другой пример показывает разницу между полной загрузкой и выборочным доступом: 150 000 токенов против 2 000. Такой результат связан с выборочной загрузкой нужных API и обработкой промежуточных данных вне контекста модели.

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

`mcptoon` использует похожую идею на локальном уровне. Полные схемы остаются в файле. В контекст отправляется компактный список или результат вызова.

Я бы не воспринимал это как гарантированную экономию для любого сценария. Если инструментов мало, схемы короткие и почти все действия нужны в каждом сеансе, выигрыш может быть небольшим. Сначала стоит сравнить обычный и компактный `manifest`, а потом проверить реальный вызов.

## Как подключить MCP к ИИ-агенту?

Для локального теста установи `mcptoon`, создай конфигурацию, добавь сервер `fetch` через `stdio`, проверь окружение командой `doctor`, посмотри компактный список инструментов и выполни вызов. Все настройки сохраняются в `~/.mcptoon/config.json`, поэтому агенту не приходится получать полные схемы MCP заранее.

![Сиба-ину поднимает лапу рядом с тремя командами локальной проверки MCP.](https://s3.regru.cloud/crossmark/statejnik/images/guides/mcp-ekonomichnyj-klient-dlya-podklyucheniya-instrumentov-agenta/kadr-2.webp)

Запрос **как подключить mcp** обычно упирается не в агента, а в [первую рабочую связку](/guides/mcp-podklyuchit-pervyj-instrument). Здесь я беру тестовый сервер `fetch`, потому что команды для него приведены в README `mcptoon`.

Добавь `mcptoon` в окружение, из которого агент сможет запускать команды.

   ```bash
   pip install mcptoon
   ```

После установки проверь, что команда доступна:

   ```bash
   mcptoon --help
   ```

`mcptoon` нужен как CLI-слой. Это не библиотека MCP-клиента, которую агент подключает вместо сервера.

Выполни инициализацию:

   ```bash
   mcptoon init
   ```

Команда создаёт локальную конфигурацию в `~/.mcptoon/config.json`. В ней хранятся сведения о подключённых MCP-серверах и их схемах.

Подключи `fetch` через `stdio`:

   ```bash
   mcptoon add fetch --stdio npx -y @modelcontextprotocol/server-fetch
   ```

Здесь `fetch` становится именем сервера в локальном конфиге. `npx` запускает пакет MCP-сервера. Для этого вызова в окружении нужен доступный runtime `npx`.

Запусти диагностику:

   ```bash
   mcptoon doctor
   ```

Команда помогает проверить зависимости и локальную настройку. Если `stdio`-сервер не запускается, сначала смотри на наличие `npx` или другого runtime, который указан в конфигурации.

Выведи описание подключённых инструментов:

   ```bash
   mcptoon manifest --compact
   ```

Этот режим нужен для короткого discovery. Полные схемы не отправляются агенту заранее в обычном виде. Сравнить результат можно с обычным `manifest`:

   ```bash
   mcptoon manifest
   ```

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

Передай URL тестовой странице:

   ```bash
   mcptoon call fetch fetch '{"url":"https://example.com"}' --toon
   ```

Первый `fetch` - имя сервера. Второй `fetch` - имя инструмента. JSON содержит аргумент вызова. Флаг `--toon` включает компактный формат результата.

Если агент не знает команды, отправь ему короткое правило работы:

   

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

`manifest --compact` уменьшает объём описания, но не гарантирует, что агент выберет нужный инструмент. После настройки проверь вызов руками и сравни его с обычным `manifest`.

Локальная схема готова, когда проходят три проверки: `doctor` не показывает проблему, `manifest` находит сервер и инструмент, а `call` возвращает ответ. На этом месте я останавливаюсь. Не подключай сразу десятки серверов, пока не проверена одна связка.

Этот маршрут полезен и для работы с агентом, и для самостоятельных экспериментов. На практике ты видишь, где заканчивается MCP, где начинается CLI и какой ответ реально попадает в контекст.

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

## Где находится конфигурация MCP в JSON?

Локальная конфигурация `mcptoon` хранится в файле `~/.mcptoon/config.json`. Команда `init` создаёт его, `add` добавляет сервер, `manifest` читает список схем, а `call` использует настройки для запуска нужного сервера и инструмента. Редактировать MCP-сервер в этой статье не нужно: достаточно понимать связь файла с командами CLI.

Путь начинается с домашней директории пользователя:

```text
~/.mcptoon/config.json
```

Тильда означает домашнюю папку текущего пользователя. Имя файла фиксировано для локальной конфигурации `mcptoon`.

Связь команд с файлом выглядит так:

- `mcptoon init` создаёт начальную конфигурацию.
- `mcptoon add` записывает в неё новый MCP-сервер.
- `mcptoon manifest` читает схемы и показывает доступные инструменты.
- `mcptoon call` берёт настройки сервера и выполняет конкретный вызов.

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

> Схемы MCP находятся на диске в `~/.mcptoon/config.json`, а не в окне контекста.  
> - README проекта [mcptoon](https://github.com/activeing123/mcptoon)

Я бы не начинал с ручной правки JSON. Сначала используй `init` и `add`, потом открой файл, чтобы увидеть результат. Так меньше шанс сломать структуру и перепутать имя сервера с именем инструмента.

Разработка собственного MCP-сервера здесь не нужна. Для локального подключения достаточно готового сервера, команды запуска и корректного runtime.

## Как настроить MCP локально и не переплачивать за облако?

Локальный MCP через CLI подходит, когда готовый сервер уже доступен, нужен тестовый сценарий или хочется держать схемы на своём диске. Удалённое подключение удобнее для внешних сервисов, обновлений, масштабирования и доступности. `mcptoon` экономит контекст в локальном сценарии, но не заменяет удалённую инфраструктуру во всех задачах.

Запрос **локальный mcp** обычно означает желание подключить один инструмент без отдельной облачной связки. В таком случае локальный CLI-слой выглядит прямолинейно: конфиг лежит на диске, сервер запускается во время вызова, результат возвращается через команду.

Подход подходит для таких задач:

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

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

| Локальный CLI-слой | Удалённый MCP-сервер |
|---|---|
| Готовый сервер уже доступен локально | Инструмент работает как внешний сервис |
| Удобен для теста и узкого сценария | Удобен для внешних сервисов и постоянной доступности |
| Схемы хранятся в локальном JSON | Подключение идёт к удалённой точке |
| Нужен runtime вроде `npx` для `stdio` | Локальный runtime может быть не нужен |
| Агент получает компактный результат команды | Поставщик обслуживает серверную часть |

Фраза **mcp подключения** может означать оба варианта. Здесь не нужно объявлять один из них универсально лучшим. Локальный вариант снижает объём ручной настройки и держит конфиг рядом с рабочей средой. Удалённый вариант может снизить затраты на обслуживание локальной инфраструктуры.

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

## Что делать, если инструмент не вызывается?

Сначала проверь runtime, который запускает сервер через `stdio`, затем выполни `mcptoon doctor`. После этого сверяй имя сервера и имя инструмента, выведи обычный `manifest` и сравни его с компактным. Если схема стала слишком короткой, агент может выбрать не то действие, даже когда сам CLI настроен правильно.

Диагностика идёт от окружения к имени вызова:

1. Проверь наличие `npx` или другого runtime из команды `add`.
2. Запусти `mcptoon doctor`.
3. Сверь имя сервера в команде `call`.
4. Сверь имя инструмента на этом сервере.
5. Сравни обычный и компактный `manifest`.

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

```bash
mcptoon call fetch fetch '{"url":"https://example.com"}' --toon
```

Если не работает сам запуск, проблема может быть во внешней runtime-зависимости. Для `stdio` недостаточно одной записи в JSON: окружение должно уметь запустить указанную команду.

Если команда проходит, но агент вызывает не тот инструмент, смотри на описание. Компактность не гарантирует правильный выбор. Сокращённая схема может оставить слишком мало подсказок для похожих действий.

Ошибка вызова MCP не означает, что агенту надо менять код приложения. Сначала проверь runtime, конфиг, имя сервера, имя инструмента и два варианта `manifest`.

## Что делать, если ответ инструмента слишком большой?

Компактный discovery уменьшает описание инструмента, но не делает большой payload маленьким автоматически. Если сервер возвращает крупную структуру, она всё равно может переполнить контекст. Сначала ограничь данные на стороне запроса, используй фильтрацию или небольшой диапазон и проверь сценарий на простом инструменте вроде `fetch`.

![Пёс тревожно смотрит на переполненный ответ и карточки способов уменьшить данные.](https://s3.regru.cloud/crossmark/statejnik/images/guides/mcp-ekonomichnyj-klient-dlya-podklyucheniya-instrumentov-agenta/kadr-3.webp)

У проблемы есть две разные части:

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

`manifest --compact` работает с первой частью. Он не может сам решить, сколько записей или полей вернёт сервер.

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

Практический порядок такой:

1. Начни с небольшой страницы через `fetch`.
2. Ограничь диапазон данных, если сервер это поддерживает.
3. Отфильтруй ненужные поля до передачи результата агенту.
4. Проверь, что агенту нужен полный ответ, а не короткий итог.
5. Повтори тест на реальном сценарии после уменьшения результата.

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

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

В этой статье настройка MCP - это локальная связка `mcptoon`, MCP-сервера, имени инструмента и файла `~/.mcptoon/config.json`. Сначала выполняется `init`, затем сервер добавляется через `add`, после чего конфигурация проверяется командами `doctor`, `manifest` и `call`.

Локальный JSON-файл `mcptoon` находится по пути `~/.mcptoon/config.json`. Его создаёт `mcptoon init`, а сведения о сервере в него добавляет `mcptoon add`.

MCP-инструмент - отдельное действие, которое сервер делает доступным агенту. В тестовом сценарии из статьи используется `fetch`, который вызывается через сервер `fetch`. Полный список доступных действий показывает команда `manifest`.

`mcp desktop` относится к использованию MCP в настольном приложении. В фактуре нет подробной настройки конкретного приложения, поэтому здесь разобран не desktop-сценарий, а локальный CLI-подход через `mcptoon`.

`mcp cli` - работа с MCP через команды терминала. В этой схеме агент запускает `mcptoon`, CLI читает локальный конфиг, находит сервер и возвращает результат инструмента.

MCP используется так: агент выбирает внешнее действие, клиент передаёт вызов серверу, сервер выполняет его и возвращает результат. При работе через `mcptoon` агент запускает CLI-команду вместо прямой передачи всех MCP-схем в контекст.

В рамках этой инструкции коннектором можно считать связку агента, CLI, MCP-сервера и инструмента. Отдельного определения или сравнения MCP-коннектора с обычной интеграцией в фактуре нет.

Для локальной конфигурации `mcptoon` используется `~/.mcptoon/config.json`. Сначала создай его через `mcptoon init` и добавь сервер командой `mcptoon add`, а ручную правку оставь для случая, когда уже понятно, что именно меняется.

В конфигурации нужны сведения, по которым `mcptoon` найдёт сервер и запустит его. Для `stdio` это также команда внешнего runtime, например `npx`. Точный формат лучше получить через команды README проекта, а не собирать JSON с нуля.

MCP связывает LLM-приложение с внешними данными и инструментами. Агент формирует вызов, клиент передаёт его серверу, а сервер возвращает результат. В экономичном CLI-сценарии схемы остаются локально, а агент получает компактное описание и ответ конкретного вызова.

В фактуре приведён тестовый пример с сервером и инструментом `fetch`: сервер добавляется через `mcptoon add fetch`, список смотрится через `manifest`, а вызов выполняется командой `mcptoon call fetch fetch`.

Первый шаг настройки: установка mcp через `pip install mcptoon` и проверка `mcptoon --help`. Затем выполни `mcptoon init`, добавь готовый сервер через `mcptoon add`, запусти `doctor`, `manifest` и тестовый `call`. Локальные настройки сохраняются в `~/.mcptoon/config.json`.

Для локального `stdio`-сценария добавь сервер командой вида `mcptoon add fetch --stdio npx -y @modelcontextprotocol/server-fetch`. После этого проверь runtime, имя сервера и имя инструмента, а затем выполни тестовый вызов.

`mcp config` в этой статье - локальный конфигурационный файл `~/.mcptoon/config.json`. Он связывает имя сервера с командой запуска и позволяет `manifest` и `call` находить нужный MCP-инструмент.

Определи задачу, найди подходящий инструмент в `manifest`, проверь его имя и выполни `call`. Если подключено много инструментов, сначала используй компактный список, но обязательно проверь, что агент правильно выбрал действие.

- [mcptoon](https://github.com/activeing123/mcptoon)
- [Specification - Model Context Protocol](https://modelcontextprotocol.io/specification/2024-11-05/index)
- [Code execution with MCP](https://www.anthropic.com/engineering/code-execution-with-mcp)
- [Advanced tool use](https://www.anthropic.com/engineering/advanced-tool-use)
- [Remote MCP support in Claude Code](https://www.anthropic.com/news/claude-code-remote-mcp)
- [Best practices for Claude Code](https://code.claude.com/docs/en/best-practices)
- [The MCP Context Tax](https://unabyss.com/blog/mcp-context-tax)
- [Your MCP Has Too Many Tools. Here’s How to Fix It](https://apagiaro.it/optimizing-your-mcp-server/)
- [Code execution with MCP: Building more efficient agents](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1780)