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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully lists the output fields the agent will receive, but it does not explicitly state that the operation is read-only or side-effect-free, nor does it mention edge cases or failure behavior. For a 'describe' tool, the field list plus the name implies a safe inspection, but richer disclosure would be better.

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?

The description is extremely compact: a field list followed by a short routing instruction. Every token earns its place, and the concrete payload is front-loaded before the 'call first' guidance. There is no filler, repetition, or unnecessary caveat.

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?

Given zero parameters and no output schema, the description does the necessary work of listing the key return fields and specifying workflow order ('call first'). It is complete enough for an agent to invoke the tool and understand what it will get back, though it could be slightly more explicit about the shape or format of the response.

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?

The tool takes zero parameters, so the schema is trivially complete at 100% coverage and the baseline of 4 applies. The description correctly avoids inventing parameter details and instead focuses on the returned metadata, which is the only relevant semantic content.

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 clearly identifies the resource ('document') and enumerates the metadata returned: name, pages, paragraphs, words, comments, tracked changes, and track-changes state. The title 'What the document is' reinforces the purpose, and this distinguishes it from sibling tools like document_read or document_comments, though no sibling is explicitly named.

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 phrase 'For documents; call first' provides clear contextual guidance: this tool is the initial inspection step before document operations. It doesn't name alternatives or state when not to use it, but it does restrict scope to documents and establishes ordering, which is sufficient for basic workflow selection.

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