MCP-протокол перегружает контекст модели: toolhub заменяет JSON-схемы деревом навигации

Инженер под ником автора оригинала, устав от «натягивания совы на глобус», собрал открытый инструмент toolhub, self-hosted движок, который превращает любой консольный скрипт в навык для языковой модели без написания MCP-обёрток. Ниже разберём, как это устроено, зачем нужно и как попробовать.

Зачем вообще нужен MCP протокол и в чём его боль?

MCP протокол придуман компанией Anthropic как единый способ подключать внешние инструменты к языковым моделям. Идея красивая: модель получает список доступных функций, понимает их схемы и вызывает нужную по ситуации. Это называется Function Calling (вызов функций).

На практике для подключения одного инструмента разработчику сегодня приходится:

• Описать килобайты JSON-схем прямо в системном промпте (системный промпт, это стартовая инструкция, которую модель получает до любого вопроса пользователя), сжигая от 15 до 30 тысяч токенов контекста ещё до начала работы
• Написать полноценный сетевой MCP-сервер со своим шаблонным кодом, SDK и зависимостями
• Завернуть всё в Docker-контейнер, выделив 200 мегабайт оперативной памяти ради скрипта на три строки

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

Вот как выглядит типичная сессия, когда нужно проверить статус сервиса и перезагрузить его. Вместо одного вызова вроде call_tool("check_and_restart", {...}) агент вынужден последовательно выполнять:

bash("systemctl is-active my-app.service")
bash("journalctl -u my-app.service -n 50 --no-pager")
bash("ss -tunlp | grep 3000")
bash("kill -9 $(lsof -t -i:3000)")
bash("systemctl restart my-app.service")

И это повторяется по нескольку раз за сессию. Принцип DRY (Don't Repeat Yourself, «не повторяй себя», базовое правило хорошего кода) нарушается грубо. Инженер хочет абстрагировать всё это в один вызов, но как только таких абстракций становится больше 30, модель ловит эффект Lost in the Middle (потеря информации в середине длинного контекста) и начинает галлюцинировать.

Что предлагает toolhub вместо плоского списка?

Автор инструмента применил древовидную навигацию вместо плоского массива из сотен инструментов. Структура выглядит как файловая система:

/
├── system/
│   ├── fetch_logs
│   └── restart_service
├── database/
│   └── query_pg
└── sublime/
    └── replace-literal

Модель на старте получает только корневую карту дерева с короткими аннотациями по категориям, одну-две строки на папку. Дальше работают два ключевых вызова:

• listTools("/system") — заглянуть в конкретную ветку и подтянуть описания только нужных инструментов
• callTool("/system/fetch_logs", { "service": "nginx" }) — вызвать конкретный инструмент с параметрами

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

Как toolhub выполняет скрипты без Docker?

Механика исполнения описана автором как «простая как топор»:

1. На лету создаётся временная папка /tmp/hub_run_<timestamp>_<hash>
2. В папку кладётся код скрипта и файл input.json, параметры вызова автоматически пробрасываются в переменные окружения вида $INPUT_<KEY_NAME>
3. Если прописана команда установки зависимостей, она отрабатывает в контексте папки, Bun (быстрая среда выполнения JavaScript) подтягивает модули за миллисекунды из глобального кэша
4. Запускается команда с жёстким ограничением по времени, результат считывается из output.json или стандартного вывода
5. Временная папка немедленно удаляется

Единственная глобальная зависимость — Bun. Скрипт можно писать на Bash, Python, Go, PHP и других языках.

Почему toolhub не использует стандартный Function Calling?

Toolhub сознательно не привязывается к интерфейсам вызова функций конкретных провайдеров. Весь цикл ReAct (когда модель рассуждает, действует и наблюдает результат) построен на XML-подобных командах:

<hub>listTools("/")</hub>
<hub>callTool("/sublime/list-project-files", {})</hub>

Такой подход позволяет работать с любыми моделями, даже если у них нет встроенной поддержки вызова инструментов или она реализована нестабильно. Порог входа для модели: понимание XML, JSON, JavaScript и древовидной навигации.

При этом toolhub поддерживает и сам MCP протокол, по данным автора, реализована нативная поддержка в Stateless-режиме через стандартный ввод-вывод (Stdio).

Что делать с этим прямо сейчас, по ролям?

Разработчику и DevOps-инженеру. Если вы уже работаете с ИИ-агентами и устали дублировать bash-вызовы, toolhub решает конкретную проблему: один скрипт автоматически становится навыком агента. Проект открытый, развёртывается на собственном сервере.

Автору Дзена и контент-маркетологу. MCP протокол стоит знать как термин: всё больше инструментов для работы с текстом будут подключаться к языковым моделям именно через него или его альтернативы. Понимание принципа «модель вызывает внешний инструмент» поможет ориентироваться в новых функциях редакторов и автоматизаций.

Предпринимателю в РФ. Toolhub разворачивается на собственном сервере, данные не уходят во внешние облака. Для тех, кто строит внутреннюю автоматизацию на базе языковых моделей (через API YandexGPT, GigaChat или открытые модели), это способ дать агенту доступ к внутренним скриптам компании без тяжёлой инфраструктуры.

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