Skip to content

CONCEPT Cited by 1 source

Context as importance signal

Definition

Context as importance signal is the observation that anything loaded into an LLM's context window is read by the model not just as capability available but also as importance-weighted input. A tool description in context is not neutral — its presence signals this tool matters right now. A document excerpt in context is not neutral — its presence signals this excerpt is relevant to the current task.

The consequence: what you load into context shapes the model's attention as much as what the model reads to solve the task. Loading irrelevant material is not free even when the model ignores it — the model does not reliably ignore it, and may waste tokens and wall-clock time exploring irrelevant directions.

Thomas Ptacek, Fly.io, 2026-03-10:

"Cramming your context full of MCP tool descriptions is a way of signaling to the model that those tools are important to you. But not every Sprite command is equally important in every setting. If you're not using network policies, you don't need gemini to waste a bunch of time setting them up for you."

(Source: sources/2026-03-10-flyio-unfortunately-sprites-now-speak-mcp.)

Distinct from context-as-token-budget

The wiki already has the token-cost framing of context bloat — concepts/context-window-as-token-budget. That framing says: tool descriptions for N tools consume O(N) tokens; large tool inventories exceed the budget; accuracy degrades with concepts/context-rot on long contexts.

Context-as-importance-signal is a separate, additive cost:

Axis Cost
Token budget (existing wiki page) N tools × description-size consumes K tokens; context-rot degrades later turns
Importance signal (this page) N tools in context signals N areas of relevance; agent explores irrelevant ones

The token-budget cost is linear in inventory size. The importance-signal cost is zero if the model perfectly ignores irrelevant tools — but it doesn't. In practice, tool listings draw model attention, and tool descriptions that mention plausible-seeming sub-tasks can derail the agent into unrelated work.

Ptacek's canonical example

"If you're not using network policies, you don't need gemini to waste a bunch of time setting them up for you."

If the Fly.io MCP server exposes sprite network policy create, sprite network policy list, and sprite network policy delete, and the user's actual task is "reproduce this bug", the model nevertheless sees "network policies are a concept this system has" and may decide — incorrectly — that the bug is network-policy-related. The tools' presence in context redirects the planner.

Two distinct mitigations

Because context-as-importance-signal is a separate cost axis from token-budget, two different families of mitigation compose:

  • Progressive capability disclosure. Don't load the tool unless the agent walks toward it. CLIs and API sub-paths naturally exhibit this; MCP flat tool listings don't. Directly addresses both cost axes simultaneously.
  • Context-segregated sub-agents. Spin up a sub-agent with a task-specific tool surface, isolating importance-weighting to that task. Directly addresses the importance-signal axis; addresses the token-budget axis through smaller per-agent contexts.
  • Tool-surface minimization. Expose fewer tools per MCP session. Reduces both costs. Core / opt-in toolset split (Datadog's approach) is a coarse version of this.

Why "not free to ignore" is load-bearing

The argument fails if LLMs perfectly ignore irrelevant tool descriptions. The argument succeeds if they attend to everything in context as weakly-relevant. Empirically, 2026-Q1 LLMs sit somewhere between — they don't always wander into irrelevant tools, but they sometimes do, and the cost of the wander is wall-clock + dollars + possible destructive action.

The deeper framing: context is prompting, implicitly. The tool list is "here are tools" but it is also "consider these tools". A sufficiently long context eventually weakens instruction-following enough that the boundary between "capabilities you have" and "capabilities you should exercise" blurs.

See concepts/context-rot for the general "context degrades later-turn instruction-following" observation; this concept is the mirror-image claim on the first-turn side.

Why MCP is the canonical failure shape

MCP's default shape loads all tools into context at session start. A Sprites MCP with 20 operations signals 20 areas of importance every turn — regardless of whether the user asked about any of them. This is the Fly.io 2026-03-10 post's central aesthetic objection.

The mitigations within MCP — MCP Server Cards for pre-connect description, layered toolsets, sub-agent dispatch — are partial. The full mitigation is progressive disclosure, which MCP does not natively afford (though MCP-aware agent harnesses increasingly implement it client-side).

Not a complete argument against tool-listing

Context-as-importance-signal is a cost axis, not a prohibition. Two cases where flat tool-listing is still correct:

  • Small tool inventories. A 2-tool MCP (like the original systems/flymcp: fly logs + fly status) loads 2 signals. The cost is bounded; the benefit (tools always available) is higher.
  • Shell-less agents. For agents that can't explore via subprocess, the pre-loaded tool list is the only capability-discovery channel. See patterns/mcp-as-fallback-for-shell-less-agents. The cost of importance-signaling is accepted because the alternative is "no tools at all."

Not resolved by Code Mode

Cloudflare's Code Mode compresses ~3,000 operations into <1,000 tokens via code-synthesis rather than tool-listing. Token-budget problem: solved. Importance-signal problem: partially solved — the agent sees one tool (a code-execution environment) instead of ~3,000, which collapses the importance signal to a single axis. The agent still has to discover which APIs exist within the code-execution environment, which is itself progressive disclosure at the library-API altitude.

Seen in

Last updated · 319 distilled / 1,201 read