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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds context the annotations cannot: records are redacted, they are not full terminal output, and access requires account-bound computer:write OAuth plus possible local owner approval. It still says nothing about pagination behavior or how far back "recent" extends.

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 short sentences, each earning its place: scope, alternative, and access requirements, in that order. The final sentence is slightly dense (two distinct auth requirements stacked in one clause) but nothing is wasted or repeated from the name.

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?

With no output schema, the description still tells the agent the payload is redacted records rather than raw terminal output, which is the key expectation to set. For a one-optional-parameter read tool this is close to sufficient; the only real gap is what a record contains and how to retrieve more than one page.

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 100% and the single limit parameter is already documented as "Page length, subject to server-side maximum." The description adds no detail about the limit's range, default, or how to page beyond it, so it neither compensates nor detracts; 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?

States a specific verb and resource ("Read redacted recent EXZA commander tool-call records") and immediately bounds the scope with "(not full device terminal output)", which prevents a common misreading. It is clearly distinguishable from exza_get_commander_usage, which it names as the counting alternative.

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?

Explicitly routes the count-only case to exza_get_commander_usage, giving the agent a real either/or decision rule. It does not cover other plausible alternatives such as exza_get_commander_search_results or when the history would be empty/unavailable, but the primary fork is resolved.

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