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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral value beyond them: newest-first ordering, the DRAFT vs READY status semantics and their consequence, and the distinction between main and reference asset ids (with the empty-reference fallback rule). Pagination behavior is the notable omission.

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?

Front-loaded with '[read] The caller's characters, newest first' and only two sentences total. The long field enumeration is dense but justified because there is no output schema; minor cost is that the parenthetical field list reads as one run-on sentence.

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?

With no output schema, the description carries the return-shape burden and does so thoroughly, including nested character_assets fields and the READY constraint on downstream use. What is missing is pagination/total-count behavior and any routing to the create/edit/asset-management siblings.

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% and both parameters (page, per_page with defaults 1 and 20) are undocumented in the schema. The description never mentions pagination, page size, or whether the nested character_assets payload scales with per_page, so it does not compensate for the coverage gap.

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?

States a specific verb+resource ('The caller's characters') plus scope and ordering ('newest first'), then enumerates the returned fields. An agent can distinguish this from get_character (single record) and list_character_prompts (prompts, not characters) without opening any schema.

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: read the caller's characters, and note that 'Only a READY character can be used in a picture or a video' — useful downstream context but not a when-to-use rule. No alternatives (get_character, create_character, edit_character) are named and no exclusions or prerequisites are stated.

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