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

Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description is consistent with that. The description adds the bulk-execution behavior as useful context, but it does not mention auth requirements, response specifics, or error behavior beyond what the annotations cover.

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 short, front-loaded with the primary purpose, and the only extra detail is the useful bulk-support note. There is no filler or repetitive parameter explanation.

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 simple get-by-ID tool, the description is mostly complete: it states the resource, the read-only nature, and the batch capability. It could be slightly stronger if it described the response shape or clarified when to prefer plural sibling endpoints, but the core invocation context is present.

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 description adds meaningful context by saying project_ids and chapter_ids can be used for batched execution, which goes beyond the schema's raw array types. It does not fully compensate for the 0% schema description coverage, though: the relationship between the required single fields project_id/chapter_id and the optional arrays is left mostly to inference.

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 a read operation for a specific chapter: 'Returns information about a specific chapter.' It also explicitly mentions bulk support, which adds useful scope. However, it does not explicitly differentiate itself from sibling endpoints like elevenlabs_get_chapters or elevenlabs_get_chapter_snapshot_endpoint.

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 phrasing 'specific chapter' implies this is for retrieving one or more chapters by ID, and 'Bulk support' is a clear hint for batch use. But it does not explicitly recommend alternatives, such as using elevenlabs_get_chapters when a list is needed, or mention when not to use this tool.

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