Lab note: Docker MCP and context-window contamination

This is a cleaned-up version of an earlier LocalLLaMA field note about Docker MCP and context-window contamination.

The problem is simple: tool aggregation is convenient, but every enabled tool can add instructions, schemas, names, descriptions, and behavioral pressure to the model context.

If the system injects too much tool information before the task is even clear, the model starts the conversation with polluted context.

What I observed

In one quick test, I compared three fresh chats:

1. no MCP tools enabled;
2. a small memory MCP enabled;
3. Docker MCP enabled with many available tools.

The difference was visible immediately. With no tools, the context footprint was tiny. With one small MCP, it grew slightly. With Docker MCP aggregating many tools, the context footprint became large enough to matter before any real task started.

The exact numbers will vary by setup, model, runtime, and tool list. The core issue is more important than the number: tool metadata is not free.

Why this matters

Context-window contamination creates several production risks:

• the model sees tools that are irrelevant to the current task;
• tool descriptions compete with business instructions;
• more instructions increase ambiguity;
• hidden tool metadata makes debugging harder;
• larger context raises cost and latency;
• irrelevant tools expand the attack surface for prompt injection and tool misuse.

For local experiments this is annoying. For enterprise agents it becomes an architecture problem.

The better pattern

Tool access should be scoped.

For serious agent workflows, I prefer:

1. Start with no tools or a very small tool set.
2. Classify the user intent.
3. Enable only the tools needed for the current workflow state.
4. Keep tool descriptions short and operational.
5. Treat tool output as data, not instruction.
6. Log which tools were exposed to the model for each step.
7. Test context footprint as part of evals.

This is not only about saving tokens. It is about keeping the model's operating environment inspectable.

The lesson

MCP is powerful because it standardizes tool access. That same power can become a problem if a runtime exposes too much tool surface by default.

The design goal should be narrow, state-aware tool exposure. Agents become safer and more reliable when they see the smallest useful tool set for the current task.

Originally inspired by a LocalLLaMA post and community discussion around Docker MCP behavior.