Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full disclosure burden and does substantial work: it reveals a persistence side effect (originals stored in CCR/Redis), a recovery mechanism (ref= markers consumed by context_retrieve), and an operational default ('always runs'), plus configuration knobs (TEAMSHARED_COMPRESS_*). It stops short of explaining what happens to the input in-place or the exact shape of the returned refs, but the output schema covers the return side.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with zero filler: purpose first, then mechanism and storage behavior, then operational tuning. Every sentence earns its place, and the most decision-relevant facts (what it compresses, where originals go, how to retrieve them) are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity tool (one well-documented parameter, output schema present), the description covers purpose, mechanism, side effects, recovery path, and configuration. The only real gap is the unresolved 'always runs' instruction, which leaves some ambiguity about whether this tool is agent-invoked or automatically applied, and there is no mention of cost/latency tradeoffs an agent might weigh before compressing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — the messages parameter already documents that user messages are preserved while long tool/assistant/system blocks shrink. The main description's mention of 'JSON tool outputs, logs, and long text' is consistent with and mildly reinforces the schema but adds little meaning beyond it, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource pair ('Compress a prompt payload before it reaches an LLM') and details the content types shrunk (JSON tool outputs, logs, long text) and the method (SmartCrusher-lite sampling). It also names context_retrieve as the companion for stored originals, which distinguishes it from the five other context_* siblings without needing to open any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description positions the tool in a pipeline ('before it reaches an LLM'), states that it 'always runs', and routes recovery to context_retrieve via ref= markers, giving an agent a clear sense of when and alongside what it operates. It does not explicitly contrast itself with similar-looking siblings like context_normalize, context_prepare, or context_commit, and the phrase 'always runs' is slightly ambiguous about whether the agent should invoke it directly or whether the system does it automatically.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.