MCP-клиент: как проверить сокращение контекста до 99,9% через mcptoon

Что такое MCP-клиент и зачем делать его компактнее?

Представь связку из трёх частей:

• AI-приложение, например Claude или ChatGPT;
• MCP-клиент, который соединяет приложение с сервером;
• MCP-сервер, который предоставляет данные и команды.

MCP задаёт способ соединения с внешними системами, а клиент решает, какие возможности показать модели. Дальше клиент может передать только нужные возможности.

mcptoon работает именно на этом слое. Это CLI-клиент. Он не добавляется в обычный MCP-конфиг и не передаёт модели все схемы заранее.

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

Компактность здесь не означает «убрать всё». Она означает «не показывать всё сразу». Модель получает каталог имён для поиска, короткую схему для выбора параметров или данные в отдельном формате после вызова.

Anthropic описывает MCP как открытый стандарт, через который AI-приложения подключаются к внешним данным, инструментам и рабочим процессам. Подробнее: MCP.

Как MCP-клиент и MCP-сервер обмениваются инструментами?

Сервер и клиент делают разные вещи.

MCP-сервер предоставляет:

• команды;
• данные;
• промпты;
• ресурсы.

Клиент устанавливает соединение, получает эти объекты и преобразует их в формат, который понимает AI-приложение. Модель не разговаривает с сервером напрямую.

Путь одного вызова выглядит так:

1. Клиент подключается к серверу.
2. Клиент получает описание доступных инструментов.
3. Модель выбирает инструмент и формирует tool_use.
4. Приложение передаёт вызов серверу.
5. Сервер возвращает результат.
6. Приложение добавляет результат в контекст модели.

Для локального сценария сервер может работать как процесс на компьютере через stdio. Устройство локального сервера разобрано в гайде о MCP-сервере. Anthropic рекомендует HTTP для удалённых серверов. SSE в документации назван устаревающим транспортом.

Собственный клиент особенно нужен для локальных stdio-серверов, MCP-промптов и MCP-ресурсов. Для удалённых серверов, доступных по URL и использующих только tools, может использоваться прямое подключение через MCP Connector, но это отдельный режим.

Главная граница проходит между сервером и моделью. Сервер знает все свои команды. Модель получает только то описание, которое передал клиент.

Почему MCP-контекст увеличивает расход токенов?

Схема инструмента может содержать имя, описание, свойства параметров и служебную структуру JSON Schema. Модели это нужно для выбора команды и заполнения аргументов. Но если клиент заранее передал схемы 20 или 30 инструментов, большая часть текста может не пригодиться в текущей задаче.

В обсуждении MCP на GitHub участники приводят оценку: в типичной сессии Claude Code схемы 20-30 зарегистрированных MCP-инструментов могут занимать 15-30 КБ контекста:

Это ориентир из обсуждения, а не универсальное измерение для всех хостов и моделей.

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

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

В документации Claude Code указано предупреждение, когда вывод MCP-инструмента превышает 10 000 токенов. В документации Claude Code значение по умолчанию для максимального результата составляет 25 000 токенов. Предел 10 000 токенов задаёт конкретный хост; MCP сам по себе такого безопасного предела не устанавливает.

Поэтому я разделяю две задачи:

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

Компактный клиент решает первую задачу и частично помогает со второй через форматы результата. Он не делает любой MCP-вызов дешёвым автоматически.

Какие MCP-подключения лучше оставить?

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

В обсуждении MCP на GitHub разбирается ситуация, когда инструменты со всех подключённых серверов могут попасть в один и тот же API-вызов.

Пагинация работает похожим образом. Сервер может отдавать tools/list порциями, что потенциально уменьшает объём протокольного обмена. Но если клиент собирает все страницы, а потом отправляет модели все схемы, контекстная проблема остаётся.

Я бы оставлял:

• инструменты для текущего рабочего процесса;
• серверы, к которым обращаешься регулярно;
• остальные подключения в выключенном или отложенном состоянии.

В MCP Connector, или mcp коннекторе, можно включать, отключать и откладывать загрузку отдельных инструментов. В mcptoon похожая идея достигается иначе: каталог хранится отдельно, а модели показывается компактное представление.

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

Сколько токенов можно убрать компактным MCP-клиентом?

Сравнение выглядит так:

Для расчёта использовался tiktoken cl100k_base. Поэтому цифры нельзя переносить на любую модель и любой токенизатор без новой проверки.

Репозиторий отдельно приводит заявленную экономию:

• --slim сокращает объём на 93%;
• README проекта заявляет для --compact сокращение до 99,9%.

Я бы читал эти числа как benchmark конкретного проекта. Они показывают разницу между полной схемой и компактным представлением на одном наборе из 255 инструментов. Они не отвечают на другие вопросы:

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

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

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

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

1. Установи компактный клиент.

   Открой терминал и выполни команду.

   bash

   Скопировать

   pip install mcptoon

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

   bash

   Скопировать

   mcptoon --help

2. Добавь локальный MCP-сервер.

   В примере используется сервер fetch, который запускается через npx.

   bash

   Скопировать

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

   mcptoon сохранит сервер в собственном конфиге. Для этого шага нужны Node.js и доступная команда npx.

3. Проверь список серверов.

   Убедись, что добавленный сервер виден клиенту.

   bash

   Скопировать

   mcptoon list

   Если список пустой или команда завершается ошибкой, не переходи к вызову. Сначала проверь путь к Node.js, расположение конфига и вывод doctor.

4. Покажи только имена инструментов.

   Режим --compact подходит для первичного поиска.

   bash

   Скопировать

   mcptoon manifest --compact

   Модель получает короткий каталог имён без полных схем параметров. Это самый маленький из трёх режимов.

5. Покажи сокращённые схемы.

   Переключись на --slim, когда нужно понять параметры инструмента.

   bash

   Скопировать

   mcptoon manifest --slim

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

6. Проверь подробное описание.

   Перед вызовом посмотри конкретный инструмент через inspect.

   bash

   Скопировать

   mcptoon inspect fetch fetch

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

7. Вызови инструмент.

   Передай URL и попроси компактный формат результата.

   bash

   Скопировать

   mcptoon call fetch fetch '{"url":"https://modelcontextprotocol.io"}' --toon

   --toon применяется и к manifest, и к результатам вызова, а --compact и --slim предназначены для discovery и сокращения описаний схем.

8. Дай агенту короткую инструкцию.

   Агент должен уметь выполнять shell-команды и знать порядок действий.

   Инструкция для агентаСкопировать промпт

   Для работы с MCP используй mcptoon через shell.
   
   Сначала выполни:
   mcptoon manifest --compact
   
   Если найден подходящий инструмент, проверь его параметры:
   mcptoon manifest --slim
   mcptoon inspect <server> <tool>
   
   Затем вызови инструмент через:
   mcptoon call <server> <tool> '<json-аргументы>' --toon
   
   Не подключай тот же MCP-сервер повторно через обычный mcpServers-конфиг.
   Если команда завершилась ошибкой, покажи её вывод и не сообщай, что задача выполнена.

   Для Claude Code такие инструкции можно положить в SKILL.md или AGENTS.md. Смысл инструкции простой: используй CLI через shell вместо ожидания нативного MCP-инструмента.

9. Проверь тот же маршрут без агента.

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

   bash

   Скопировать

   mcptoon manifest --compact
   mcptoon manifest --slim
   mcptoon call fetch fetch '{"url":"https://modelcontextprotocol.io"}' --toon

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

Почему компактный клиент не вставляется в MCP JSON?

Обычная конфигурация Claude Code может лежать на разных уровнях:

• пользовательский файл ~/.claude.json;
• локальная конфигурация проекта;
• общий проектный файл .mcp.json.

Это настройки самого хоста. В них описываются MCP-серверы, которые хост подключает напрямую.

У mcptoon другая схема:

1. сервер добавляется через mcptoon add;
2. запись сохраняется в ~/.mcptoon/config.json;
3. агент запускает mcptoon manifest, inspect или call через shell;
4. результат команды попадает в диалог.

mcptoon - это CLI-инструмент, а не MCP-сервер. Он не подключается к JSON-конфигурации mcpServers. Вместо этого агент вызывает mcptoon через shell-команды, а схемы остаются вне контекста.

• Репозиторий mcptoon

Не вставляй строку mcptoon в mcpServers в надежде получить компактный режим. Так смешиваются два разных способа подключения.

Сервер может существовать только в ~/.mcptoon/config.json, а агенту достаточно разрешения на запуск shell-команд и инструкции из SKILL.md или AGENTS.md.

Что делать, если MCP-клиент не запускается?

Начни с базовой проверки:

mcptoon list
mcptoon doctor
mcptoon manifest --toon

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

Частые причины такие:

• Windows не находит npx;
• NVM виден в терминале, но недоступен GUI-приложению;
• сервер добавлен не в тот конфиг;
• относительный путь работает в shell, но не работает из приложения;
• путь к Node.js или скрипту сервера указан неверно.

На Windows для запуска npx может понадобиться такая запись:

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

Если используется NVM, приложение может не получить тот же PATH, что и терминал. Проверь путь к Node.js:

where node
where npx

Если приложение всё равно не видит Node.js, укажи абсолютный путь. Такой же подход используй для скрипта сервера:

mcptoon add my-server --stdio node C:/projects/my-server/dist/index.js

GUI-приложение может запускать процесс с другим рабочим каталогом. Относительный путь к Node.js или скрипту в терминале при этом работает, а из приложения ломается.

Для Windows используй прямые слеши или экранированные обратные слеши:

C:/projects/my-server/dist/index.js

Не ищи конфиг только в папке проекта. Обычные MCP-конфиги хоста могут лежать на пользовательском или проектном уровне. mcptoon использует собственный путь:

~/.mcptoon/config.json

Если после ручной проверки команды работают, но расширение или агент говорит «инструмент недоступен», это отдельный этап. Соединение сервера и передача инструмента модели могут расходиться. В одном из описанных случаев обходом стал Claude Code CLI вместо расширения VS Code.

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

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

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

Поэтому модель может:

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

Используй режимы по назначению:

Моя рабочая последовательность такая:

1. manifest --compact для поиска.
2. manifest --slim для понимания параметров.
3. inspect для спорного или важного вызова.
4. call ... --toon для структурированного результата.
5. Повторная проверка, если модель неверно прочитала ответ.

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

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

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