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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description's main behavioral claim ("does not start generation") largely restates that no side effects occur, though it usefully disambiguates the misleading "generation" in the name. It says nothing about whether the quote reserves or expires credits, how long it is valid, or what happens if the underlying asset changes — all material for a pricing/quote tool.

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?

Two short sentences, zero filler, with the cost-checking purpose stated first and the negative boundary immediately after. Nothing can be removed without losing 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?

With no output schema, the description must convey what comes back; "credit cost and settings" is a useful but thin sketch — it does not say whether settings include resolution/duration/visibility constraints or whether the quote is keyed to the supplied prompt. For a three-parameter, ambiguity-prone quote tool this leaves the agent guessing at the return contract.

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 coverage is only 33%: only is_public is documented in the schema. The phrase "an uploaded photo" implicitly links asset_id to an image asset, which is real added meaning, but prompt is never explained (is it the motion/description prompt for the video?) and its 10,000-character limit and interaction with the quote are unaddressed.

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?

"Check the credit cost and settings for turning an uploaded photo into a video" names a specific verb (check) and a specific resource (cost + settings), and the second sentence rules out the generation behavior implied by the tool's name. It is clearly distinct from generate_video and list_image_assets, though it never names the sibling it precedes.

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?

"Does not start generation" functions as an explicit when-not clause and, combined with "check the credit cost," signals the correct pattern of previewing cost before generating. There is no explicit statement that the result should be used to decide whether to call generate_video, nor any prerequisite guidance, so it stops short of a full 5.

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