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

Beyond the readOnly/idempotent annotations, the description discloses real behavioral constraints: refresh_status verifies original IDs without resubmitting (confirming no side effects), refresh is capped at 5 per request, unrefreshed status is observed-only and possibly stale, and history/cursors can expire on runtime eviction. It also defines the data boundary (no raw parameters, outputs, or other-account selector), which prevents an agent from expecting fields that will never appear.

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?

Four dense sentences, front-loaded with what is returned, then the optional refresh behavior, then the expiry caveat and exclusions. No filler, but the phrase 'at most 5 per request' is compressed to the point of ambiguity about what is being counted.

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 shapes need no explanation, and the description covers filtering, view selection, refresh semantics, staleness, cursor expiry, and data exclusions. The one gap is the page-size parameter and whether cursors are opaque, which an agent may need to know to paginate correctly.

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?

With 0% schema description coverage, the description has to carry parameter meaning, and it largely does: time filtering (from_ms/to_ms), status filtering, the IN_FLIGHT view, cursor pagination with its expiry caveat, and refresh_status semantics. Only 'limit' is left completely unaddressed, and 'at most 5 per request' is somewhat ambiguous about whether it constrains refreshed IDs or page size.

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 states a specific verb and resource: paging retained remote command metadata with time/status filtering and an IN_FLIGHT view. It is clearly distinguishable from generic session tools like agent_history or get_recent_tool_calls because it scopes to 'this account's' remote command records and explicitly excludes raw parameters and outputs. It stops short of naming a sibling it is not, so it falls just below a 5.

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?

Usage context is implied rather than stated: the reader infers that IN_FLIGHT view is for live monitoring and refresh_status is for verifying still-running command IDs, with 'otherwise status is observed-only' acting as the when-not clause. There is no explicit routing advice against nearby tools such as get_recent_tool_calls or agent_status, so an agent must still infer the boundary.

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