Generations Estimate Cost

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

The description adds behavioral context by stating the tool estimates cost and returns estimated credits, and the 'before creating' phrasing implies it does not perform the creation itself. Annotations provide readOnlyHint=false and destructiveHint=false, which are neutral but not contradicting. The description does not disclose side effects, auth requirements, or edge cases, so it is adequate but not rich.

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 exceptionally concise, using only two sentences and no filler. Every word adds value: it states the action, the target resource, the temporal context, and the return type. There is no redundancy or unnecessary detail.

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 tool with four parameters, no output schema, and sparse annotations, the description is too minimal. It explains the high-level purpose but leaves out critical details such as what parameters influence the estimate, how the estimate is returned (e.g., numeric credits, object), and any prerequisites or side effects. The description is not complete enough for an agent to use the tool correctly in varied contexts.

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 the description provides no information about any of the four parameters (model, duration, fps, reasoningEnabled). The description does not compensate for the lack of schema descriptions, leaving the agent to infer meaning from parameter names alone. This is insufficient for reliable parameter usage.

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 states the tool's purpose: estimating credit cost before creating a generation. It uses a specific verb ('estimate') and resource ('generation') and adds the scoping detail 'before creating it'. However, it does not explicitly differentiate from the similarly named sibling 'generate_estimate-cost', so it lacks full sibling discrimination.

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 phrase 'before creating it' provides clear contextual guidance on when to use this tool: as a preliminary step to creation. It implies a usage order relative to generation creation, but it does not mention exclusions or alternative tools explicitly. This meets the 'clear context, no exclusions' level.

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