Lab note: Docker MCP и загрязнение контекстного окна
Это очищенная версия ранней полевой заметки для LocalLLaMA про Docker MCP и загрязнение контекстного окна.
Проблема простая: агрегировать tools удобно, но каждый включенный tool может добавлять в контекст инструкции, schemas, названия, описания и поведенческое давление на модель.
Если система inject слишком много tool information до того, как задача вообще понятна, модель начинает разговор уже с загрязненным контекстом.
Что я наблюдал
В одном быстром тесте я сравнил три свежих чата:
- MCP tools выключены;
- включен небольшой memory MCP;
- включен Docker MCP с большим набором доступных tools.
Разница была видна сразу. Без tools context footprint был минимальным. С одним небольшим MCP он слегка вырос. С Docker MCP, который агрегировал много tools, footprint стал достаточно большим, чтобы иметь значение еще до начала реальной задачи.
Точные числа будут отличаться в зависимости от setup, модели, runtime и списка tools. Важнее сам принцип: tool metadata не бесплатна.
Почему это важно
Context-window contamination создает несколько production-рисков:
- модель видит tools, которые не нужны текущей задаче;
- описания tools конкурируют с business instructions;
- больше инструкций повышает ambiguity;
- скрытая tool metadata усложняет debugging;
- большой контекст повышает cost и latency;
- лишние tools расширяют attack surface для prompt injection и tool misuse.
Для локальных экспериментов это раздражает. Для enterprise agents это уже архитектурная проблема.
Лучший паттерн
Tool access должен быть scoped.
Для серьезных agent workflows я предпочитаю:
- Начинать без tools или с минимального tool set.
- Классифицировать user intent.
- Включать только tools, нужные для текущего workflow state.
- Держать tool descriptions короткими и операционными.
- Относиться к tool output как к data, а не instruction.
- Логировать, какие tools были exposed to the model на каждом шаге.
- Проверять context footprint как часть evals.
Это не только экономия tokens. Это способ сохранить operating environment модели inspectable.
Вывод
MCP силен тем, что стандартизирует tool access. Но эта же сила становится проблемой, если runtime по умолчанию открывает модели слишком большую tool surface.
Цель дизайна - narrow, state-aware tool exposure. Агенты становятся безопаснее и надежнее, когда видят минимальный полезный набор tools для текущей задачи.
Материал основан на LocalLLaMA-посте и обсуждении поведения Docker MCP в сообществе.
Есть похожая AI-задача?
Отправьте короткий бриф, и я предложу минимальный платный следующий шаг: консультацию, аудит, security review или разработку.