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

With no annotations provided, the description carries the full behavioral burden and delivers: async semantics (returns requestId, poll with check_job_status), output trait (Native audio), quality behavior (2K is upscaled from 768p), cost model (priced per second by resolution), auth model (Bitcoin Lightning, no API key/signup), and a hard prerequisite (create_payment). This is unusually thorough behavioral disclosure for an unannotated 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?

Three sentences with zero filler. The order is ideal: core purpose first, then async/audio behavior, then resolution/duration/pricing, then payment/auth and prerequisite. Every sentence earns its place and no information is repeated from the schema.

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?

Despite having no output schema, the description explains the return contract (requestId) and how to retrieve results (check_job_status), covering the async gap. It also addresses the payment dependency, the resolution billing quirk, and constraints that an agent must know to call this tool correctly. Nothing an agent needs to execute the full create_payment → animate_image → check_job_status flow is missing.

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 100%, so the baseline is 3. The description adds genuine value beyond the schema: naming 'MiniMax H3' clarifies what modelId's 'default model' actually is, and it reinforces the resolution and duration semantics (5-15 seconds, 768p/2K with upscaling note). The schema's resolution parameter is already extremely detailed, so the marginal gain is modest but real.

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 opens with a specific verb+resource+outcome: 'Animate a still image into cinematic video with MiniMax H3.' It clearly distinguishes this image-to-video tool from siblings like generate_video (no first frame needed), check_job_status (polling), and create_payment (payment) by framing the exact input ('first frame and a prompt') and the pipeline position. Nothing is left ambiguous about what the tool does.

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 description gives explicit workflow guidance: 'Requires create_payment with toolName="animate_image"' establishes the prerequisite, and 'Async — returns requestId, poll with check_job_status' tells the agent exactly how to use it after invocation. It does not explicitly state when-not-to-use or name an alternative (e.g., 'for text-only video use generate_video'), but the clear context makes the appropriate use evident.

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