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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the agent knows it is a non-destructive write. The description adds real value beyond that: warnings are advisory and immediate, and it is free. But it never says what is persisted or whether a session must exist, so behavioral coverage is partial.

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?

Front-loaded and mostly tight, but the parenthetical counter list is dumped in and the trailing 'context_window. context_window' is a duplicated, garbled fragment that hurts readability. The core message lands in the first sentence.

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?

An output schema exists, so return values need not be described, and the description correctly focuses on inputs, timing, and advisory semantics. The only real gap is silence on session_id and session lifecycle (session_start prerequisite), which an agent must infer from the schema's required field.

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 coverage is 75%, and the description goes further by enumerating the counter keys (step, max_steps, tokens_used, token_budget, cost_used_usd, cost_budget_usd, context_used, context_window, task, recent_actions) that the schema only summarizes as 'tokens/cost/context/max_steps'. session_id and loop_threshold are left to the schema, which documents them adequately.

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?

States a specific verb and resource: 'Report ONE step of a live run and get back any warnings immediately (loop detected / budget breach).' An agent can tell it reports step telemetry, distinct from pure analysis tools. It does not explicitly differentiate itself from siblings like detect_loop or budget_guard, which overlap in function.

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?

Implies usage during a live run and says warnings 'are advisory - act on them to self-correct mid-run,' which is useful timing guidance. However, it never states when to prefer this over detect_loop/budget_guard, nor any prerequisites (e.g., must call session_start first). Usage is implied rather than laid out.

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