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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Changes nothing' earns no credit. What does add value is the disclosure of what the read surfaces per part: shots and seconds, exact words, word count against shot capacity, voiceover recorded status, whether words drifted since recording, and whether narration is in the video — useful behavioral context for deciding if a re-record is needed. It is not exhaustive about format or size of a multi-part script, hence 4 rather than 5.

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?

It is a single dense sentence plus a short usage clause, front-loaded with the resource and then the per-part contents. Every clause carries information, though the long parenthetical '(and whether the words changed since)' makes it slightly harder to scan than a bulleted breakdown would.

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 read tool with full annotation coverage and an output schema, the description covers purpose, one usage moment and what the returned parts contain, which is sufficient to invoke it correctly. The only gap is the absence of a pointer to write-side siblings when the agent actually wants to change the script.

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?

There is a single parameter with 100% schema description coverage, and the schema already says 'Listing id from list_listings.' The description adds nothing about the parameter — no behavior for an unknown or unscoped listingId — so the baseline 3 for fully covered schemas is right.

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 title supplies the verb (read) and the description pins down the resource precisely: 'The narration script as it stands, part by part,' then enumerates exactly what each part contains. That is enough to separate it from draft_narration, edit_narration_section and rerecord_narration_section, though the description itself never names those siblings or states the read-vs-write distinction explicitly.

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?

'Read it before recording so the person sees the words' gives one concrete moment to use the tool, which is real guidance. It stops short of exclusions or alternatives — nothing tells the agent to prefer draft_narration when no script exists yet or edit_narration_section when the script needs changing instead of reading.

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