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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запрос как подключить mcp обычно упирается не в агента, а в первую рабочую связку. Здесь я беру тестовый сервер fetch, потому что команды для него приведены в README mcptoon.

1. Установи CLI-инструмент.

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

   bash

   Скопировать

   pip install mcptoon

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

   bash

   Скопировать

   mcptoon --help

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

2. Создай локальный конфиг.

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

   bash

   Скопировать

   mcptoon init

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

3. Добавь тестовый сервер.

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

   bash

   Скопировать

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

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

4. Проверь окружение.

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

   bash

   Скопировать

   mcptoon doctor

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

5. Посмотри компактный список.

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

   bash

   Скопировать

   mcptoon manifest --compact

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

   bash

   Скопировать

   mcptoon manifest

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

6. Сделай тестовый вызов.

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

   bash

   Скопировать

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

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

7. Дай агенту понятный маршрут.

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

   Как использовать локальные MCP-инструментыСкопировать промпт

   Для внешних MCP-инструментов используй mcptoon через CLI.
   
   Сначала посмотри компактный список команд:
   mcptoon manifest --compact
   
   Перед вызовом проверь имя сервера и имя инструмента.
   Для тестового получения страницы используй:
   mcptoon call fetch fetch '{"url":"https://example.com"}' --toon
   
   Не считай инструмент доступным только по названию. Если вызов завершился ошибкой, сначала проверь mcptoon doctor, runtime и локальную конфигурацию.

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

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

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

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

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

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

~/.mcptoon/config.json

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

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

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

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

Схемы MCP находятся на диске в ~/.mcptoon/config.json, а не в окне контекста.

• README проекта mcptoon

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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