list_index_entries

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool is read-only, which is the most important behavioral trait. It also clarifies that it lists entries already marked in the document rather than creating or compiling them.

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 two sentences with no filler. It front-loads what the tool lists, then gives clear pointers to related operations, and closes with a concise read-only note.

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?

For a one-parameter listing tool with an output schema present, the description covers the resource scope, output details, related tools, and mutability. Nothing essential is missing for an agent to select and invoke it 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 schema description coverage at 0%, the description should compensate for parameter documentation, and it does not explicitly describe file_path. However, the single parameter's name is self-explanatory, and 'in the document' implies that file_path identifies the document. This is adequate but not thorough.

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 names a specific resource ('XE index entry') and details the kinds of entries included (main text, sub-entry, see/see-also references) plus the paragraph location. It also distinguishes itself from sibling tools mark_index_entry and insert_index by explicitly listing their purposes.

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 description tells the agent when this tool is appropriate versus the related tools: use mark_index_entry to add entries and insert_index to generate the compiled index. It does not explicitly state 'use this to enumerate entries,' but the contrast is clear enough.

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