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

Annotations already cover readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is free. The description adds real context beyond that: results are 'bounded' (paginated), the words are 'editable' (i.e. subsequently mutable via the correct sibling), and IDs are 'stable' so they can be referenced later.

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?

A single well-packed sentence with the read action and scope front-loaded and no filler. Density is high but each clause (bounded, editable, stable IDs, optional match) carries information.

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 values need not be explained. For a 5-parameter read tool the description covers scope, filtering and pagination at a high level but omits ordering behavior, what 'bounded' limits actually are, and how stable IDs map to downstream correction calls.

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 only 20% (only projectId is annotated), so the description must compensate. It does so partially: 'one project' scopes projectId/workspaceId, 'optionally matching text' explains matchText, and 'bounded' signals limit/offset pagination. It still gives no bounds or ordering semantics for limit/offset.

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?

Specific verb (read) plus resource (caption words + stable word IDs) and scope (one project), with an optional text filter. It reads clearly as a listing tool against siblings like captions_words_correct, though it never names the alternative that mutates words.

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 implied rather than stated: reading is clearly the safe/fetch direction, and 'for one project' plus 'optionally matching text' hints at when it applies. There is no explicit when-not guidance or pointer to sibling tools such as captions_words_correct or captions_themes_list.

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