Ты просил погоду, а получил историю метеорологии
Знакомо? Запускаешь MCP-сервер для получения данных, а в ответ приходит не просто температура за окном, а целый трактат о климатических изменениях с 1900 года. Сервера Model Context Protocol иногда забывают, что они не профессора на лекции. Особенно когда работаешь с локальными LLM с ограниченным контекстом.
Каждый лишний токен в ответе MCP - это минус один токен для твоей основной модели. А когда их набирается сотня-другая... В общем, контекстное окно плачет.
Попробуй запустить MCP для работы с базой данных. Запрос "сколько пользователей в системе" может вернуть не только число, но и структуру таблиц, типы полей и философское размышление о природе данных. Бесплатно, конечно.
Что за зверь mcp-context-proxy?
Простой прокси-сервер, который сидит между твоим LLM и MCP-серверами. Его задача - взять раздутый ответ, пропустить через маленькую модель (типа Phi-3 Mini или даже Llama 3.1 8B), и выдать сжатый вариант. Не просто обрезать, а именно пересказать кратко.
Автор (анонимный, как и положено в open-source) называет это "квентизацией ответов". По сути - lossy компрессия для текста. Как с JPEG для изображений, только для данных.
1 Установка за пять минут
Клонируем, ставим зависимости, запускаем:
git clone https://github.com/anon/mcp-context-proxy
cd mcp-context-proxy
pip install -r requirements.txt
# Запускаем прокси
python proxy.py --port 8000 \
--compression-model "microsoft/Phi-3-mini-4k-instruct" \
--target-mcp-server http://localhost:3000Порт 8000 - это теперь твой новый endpoint для LLM. Прокси будет перехватывать запросы, сжимать ответы от сервера на порту 3000, и отдавать уже оптимизированное.
2 Настройка компрессии
Самое интересное - как именно сжимать. Инструмент предлагает несколько стратегий:
# Пример конфигурации
config = {
"strategy": "summarize", # или "extract", "rewrite"
"target_length_ratio": 0.3, # оставить 30% от оригинала
"preserve_numbers": True, # числа не трогать!
"preserve_dates": True,
"model_max_length": 512, # не грузить модель длинными текстами
"cache_compressed": True # кэшировать сжатые ответы
}Стратегия "extract" просто выдергивает ключевые факты. "Summarize" - пересказывает. "Rewrite" - пытается сохранить стиль, но короче. Последний вариант самый ресурсоемкий, зато для некоторых MCP-серверов (особенно тех, что возвращают структурированные данные) может быть полезнее.
Что получаем на выходе?
| Без прокси | С прокси (сжатие 30%) | Экономия |
|---|---|---|
| 247 токенов | 74 токена | 70% |
| "Текущая температура в Москве: -5°C. Ветер северо-западный 3 м/с. Относительная влажность 78%. Атмосферное давление 748 мм рт.ст. Видимость хорошая. Осадков не ожидается. По данным Гидрометцентра России, такая погода характерна для..." | "Москва: -5°C, ветер 3 м/с, влажность 78%, без осадков." | Информация сохранена |
Для баз данных экономия еще заметнее. Особенно если использовать Basis Router или другие инструменты подключения к БД через MCP.
А что с производительностью?
Здесь начинается trade-off. Добавляем задержку на сжатие, но экономим время на обработке основной моделью.
На моем тесте (RTX 4070, Phi-3 Mini для сжатия):
- Добавляет 50-150 мс на сжатие одного ответа
- Экономит 200-500 мс на генерации основной моделью (зависит от сложности промпта)
- При последовательных запросах к нескольким MCP-серверам выигрыш накапливается
Для интерактивных диалогов с Claude или локальными моделями типа Solar 100B каждый сохраненный токен - это возможность задать дополнительный вопрос или получить более развернутый ответ.
Альтернативы? Есть, но...
Можно просто ограничивать длину ответа в MCP-сервере. Но это грубо и часто ломает структуру данных. Особенно JSON.
Можно писать кастомные промпты для каждого сервера с просьбой отвечать кратко. Работает в 60% случаев. Остальные 40% - это когда сервер "забывает" инструкцию или интерпретирует ее слишком творчески.
Еще вариант - использовать LLMRouter для маршрутизации запросов. Но он решает другую задачу - выбор модели, а не оптимизацию ответов.
mcp-context-proxy хорош тем, что работает прозрачно. Не нужно переписывать существующие MCP-серверы. Особенно полезно для тех, кто использует MCP Tool Registry или другие готовые решения.
Подводные камни (они есть всегда)
- Потеря контекста: слишком агрессивное сжатие может выкинуть важные детали. Особенно опасно с числовыми данными или специфичными терминами.
- Накладные расходы: маленькая модель для сжатия все равно требует памяти. На слабом железе может не стоить того.
- Кэширование: включил кэш - получил ускорение, но рискуешь устаревшими данными. Особенно для динамических источников вроде погоды или биржевых котировок.
Для отладки проблем советую Syrin - дебаггер для MCP. Он покажет, что именно теряется при сжатии.
Кому это нужно?
Не всем. Если работаешь с GPT-4 через API и платишь за токены - возможно, проще заплатить. Если используешь модели с огромным контекстом (128K+) - тоже не критично.
Но вот кому точно пригодится:
- Локальные LLM-энтузиасты: те, кто гоняет модели на домашних видеокартах с 8-16ГБ памяти. Каждый токен на вес золота.
- Разработчики MCP-агентов: когда нужно подключить несколько "болтливых" серверов и не словить переполнение контекста.
- Те, кто работает с MCP Chat Studio: для тестирования воркфлоу с большим количеством инструментов.
- Экономисты: когда каждый запрос к API стоит денег, а MCP-сервер возвращает неоптимизированные JSON'ы.
Что в итоге?
mcp-context-proxy - не панацея, а конкретный инструмент для конкретной проблемы. Как шуруповерт: бесполезен, если нужно забить гвоздь, но незаменим для сборки мебели.
Начинай с умеренных настроек сжатия (50-60% от оригинала). Следи за тем, что теряется. Используй для MCP-серверов, которые действительно страдают многословием.
И помни: иногда лучше потратить время на оптимизацию самого MCP-сервера, чем на сжатие его ответов. Особенно если пишешь его сам. Но для сторонних серверов, где код не трогаешь, этот прокси - спасение.
P.S. Если после внедрения заметишь, что модель начала "забывать" важные детали из предыдущих ответов - проверь, не слишком ли агрессивно сжимаешь. Иногда краткость не сестра таланта, а просто потеря информации.