command_describe

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

Annotations already cover read-only, idempotent and non-destructive semantics, and the description adds real value on top: fields are 'inferred hints' rather than authoritative, and 'native commands may return no acknowledgement' warns that a call can succeed with no response. It omits how the snapshot source affects freshness, but the caveats are substantive.

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, front-loaded sentences, each doing distinct work: what is read and from where, the reliability caveat, and the no-acknowledgement warning. Nothing repeats the annotations or the schema.

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?

No output schema exists and the return shape ('fields') is not characterized beyond the caveat that values are inferred. Combined with 0% parameter coverage and no mention of the offset/max_characters truncation model, an agent lacks the paging contract needed to call it reliably on large commands.

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 0%, so the description carries the full burden, yet it explains none of the three parameters. The 'command' string is only obliquely implied, and 'offset' and 'max_characters' (pagination/truncation of the returned fields) are never mentioned, leaving an agent to guess how a large field set is retrieved.

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?

A specific verb ('Read') plus a precise resource ('exact native command fields, required capability and reference handler'), and the source is named ('bundled server source snapshot'), which separates it from commands_search. It never names a sibling, so an agent must infer that this is the describe counterpart to commands_search.

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 is only implied: it redirects to 'docs and the handler for types/defaults', which points loosely at docs_search/docs_read, but it never states when to call this instead of commands_search or table_command, nor any prerequisite such as needing a command identifier from a search first.

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