Ludo AI Game Assets

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

With no annotations, the description carries the full burden, and it delivers: async 202/job-id behavior, polling via getApiJob, result extraction, return format (standalone animation-only GLB plus mp4 preview), quality variability, credit charging policy, auth requirement, concurrent-job limit, and 429 PENDING_JOBS_LIMIT. This is exceptionally transparent for a complex async 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?

The description is long but dense and front-loaded. The first sentence states the purpose, and every subsequent sentence adds operational value: prerequisites, output structure, asynchronous workflow, polling, limits, credits, and auth. There is no filler or repetition.

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 an async generation endpoint with no output schema and no annotations, the description covers the complete invocation path: required inputs, preconditions, output candidates, polling behavior, result field, error conditions, rate limits, auth, and cost. Nothing needed for correct use 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?

The top-level requestBody parameter lacks a description in the schema, but the nested properties are already well documented. The description adds operational meaning beyond the schema: why multiple variants are returned, what mode affects, how loop behaves, and the cost/limit consequences. It doesn't explicitly explain request_id or augment_prompt, but those are already clear in the nested schema.

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 opening sentence names a specific action ('Generate text-driven skeletal animations'), a specific resource ('already-rigged 3D model'), and the input style. It also clearly distinguishes itself from rigModel by requiring an existing skeleton and directing the agent to the rig endpoint when that precondition is not met.

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 explicitly states the prerequisite (model must already be rigged) and names the fallback path (rig endpoint). It also gives actionable guidance for choosing mode (rot_trans default vs rot_only for retargeting) and loop (best for one-way motions, odd for cyclic gaits), so the agent can make informed decisions.

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

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

With no annotations, the description carries the full burden and delivers: async 202 behavior, polling flow, result shape (glb_url and preview_url), credits charged only on success, API-key scope, queue limit of 50, and 429 pending-jobs error. This is far beyond a minimal disclosure.

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 dense but every sentence earns its place: purpose, prerequisites, output envelope, flag behavior, async contract, rate limiting, and credits. It is front-loaded with the primary action and adds detail in a logical order without filler.

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?

Given the complexity, absence of annotations, and absence of an output schema, the description is complete: it specifies inputs, rig prerequisites, preset constraints, result fields, polling instructions, error conditions, rate limits, and auth requirements. Nothing needed to call the tool correctly is omitted.

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?

The context reports 0% schema description coverage, so the description must compensate for `model`, `preset_id`, `crop_loop`, and `in_place`. It does so with concrete details: valid rig types, clip_url restriction, crop_loop/in_place omission semantics, and game-engine locomotion rationale. It also clarifies that request_id offers idempotent re-use via the existing job.

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 first sentence states a specific verb ('Apply'), a specific resource ('curated animation preset'), and target ('already-rigged 3D model'), with 'retargeting' clarifying the operation. This clearly distinguishes it from generic animate3DModel and names the preset source, so the agent can select it correctly.

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 concrete when-to-use guidance: supply an already-rigged GLB, use a preset_id from the presets list, and satisfy the humanoid-template rig requirement. It also explains polling via getApiJob. It does not explicitly name an alternative for non-preset animation, though 'same ... as the animate endpoint' gestures toward the related tool.

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

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

Without annotations, the description carries the full burden, and it does so in depth: API key scope, request_id idempotency, HTTP 400/429 error conditions, 50-job concurrency limit, credits charged only on success, pricing, and the 202→getApiJob polling flow. The only flaw is internal: it says 'no separate polling step' early, then says to poll getApiJob, which could confuse an agent; the later specific instruction is clearer but the inconsistency prevents a 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?

The description is lengthy but front-loaded with the core operation and every major section adds operational value: alternatives, result shape, auth, errors, rate limits, credits, and pricing. It could be improved by removing the contradictory polling sentence and breaking the block into paragraphs or bullets, but it remains information-dense rather than padded.

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 complex, asynchronous, pay-per-use tool with no output schema, the description covers inputs, expected result fields, error cases, authorization, rate limits, and the follow-up getApiJob step. The ambiguous polling statement leaves some uncertainty about the exact flow, but otherwise the description is sufficient for an agent to invoke it correctly.

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 100% and the schema already gives detailed per-parameter meanings, so the baseline is 3. The description adds useful conceptual glue on top: the relationship between initial_image and motion_prompt, the interpolation role of final_image, model/duration compatibility failure modes, and the meaning of request_id for locating results.

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 and resource: 'Animate a static sprite into a spritesheet driven by a motion text prompt (image-to-spritesheet).' It names required inputs and explicitly distinguishes itself from animateSpriteKeyframes and transferMotion, so an agent can tell it apart from sibling tools.

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 guidance is explicit and actionable: use animateSpriteKeyframes for up to three keyframes, prefer transferMotion when a reference video or preset exists, call generatePose first for best results, and listAnimationPresets for named presets. It also warns about the 429 PENDING_JOBS_LIMIT and tells the agent to wait for jobs to finish.

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

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

With no annotations, the description carries the full burden, and it delivers extensively: it discloses the async 202 + getApiJob polling workflow, direct result shape, credit charging only on success, 50-job queue limit with 429 behavior, API key requirement, and model-specific pricing. This goes well beyond minimal safety disclosure.

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 long but appropriately structured for a complex async tool: purpose first, then keyframe requirements, model constraints, workflow, rate limits, and pricing. Each sentence adds operational value, though the poll instructions and result explanation are slightly redundant with each other.

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 async job lifecycle, how to retrieve the result, what the result contains, cost behavior, concurrency limits, and auth requirements. It even points to the docs for the full pricing table, making it complete for an agent to invoke and interpret the tool correctly.

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 meaningful semantics beyond the schema by clarifying that at least one of initial_image or middle_image is required, that final_image alone has nothing to anchor the animation, and that motion_prompt is optional and defaults to keyframe-derived motion. This enriches the structured parameter documentation.

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 states a specific verb and resource: 'Animate a sprite through up to three fixed keyframes' producing a spritesheet. It also names the sibling alternative animateSprite and explains the difference, so an agent can disambiguate the tool without opening the 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?

The description explicitly says when to use this tool (keyframe-driven animation) and when to use animateSprite instead ('classic single-image + text-prompt animation with model choice'). It also constrains model choice to the Forge family and notes that only Forge supports middle keyframes.

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

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

With no annotations provided, the description carries the full disclosure burden and does so thoroughly. It states the side effect (credit refund), the cost (free), the authentication requirement (API key with user scope), the failure mode (409 for running jobs), and the return value (the canceled job). This is comprehensive for a one-parameter operation.

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 four sentences, each conveying necessary information: the action, the constraint, the return value, and the cost/auth requirements. There is no filler or repetition, and the main action is front-loaded.

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?

Given the low complexity (1 simple parameter, no output schema, no annotations), the description provides everything an agent needs to invoke the tool correctly: what it does, when it applies, what can go wrong, what it costs, and what it returns. No critical behavior is left unexplained.

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?

Although the schema only defines 'id' as a string with no description, the tool description implies that the id identifies the queued job to cancel. This adds meaningful context beyond the schema, even though it does not explicitly say 'id is the job identifier'. For a single obvious parameter, this is adequate, with minor room to state the source of the id.

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 states a specific verb ('Cancel'), a resource ('a queued job you started through the API or MCP'), and a clear effect ('refund its credits'). It also distinguishes itself from siblings like getApiJob and listApiJobs by targeting cancellation only, with no ambiguity.

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 clearly indicates when to use the tool: for queued jobs that the user started, not for running jobs. It explicitly warns that running jobs cannot be canceled and will return a 409, providing a key exclusion. It does not name alternative tools, but the context makes the intended use clear.

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

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 does so thoroughly. It discloses that this is an asynchronous operation (202 + job id), that credits are charged only on success, that there is a concurrency limit of 50 with a specific 429 error code, that request_id deduplicates requests, and that an API key with user scope is required. It also explains the polling pattern and how to extract the result. This is exemplary transparency.

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 dense but every sentence contributes new information: purpose, result format, optional parameters, cost, auth, async behavior, error conditions, and workflow. It is front-loaded with the core purpose and progressively details operational specifics. Nothing feels redundant or off-topic, making it an efficient and well-structured description for the complexity involved.

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?

The description is fully complete for an async generation tool with no output schema. It covers the full lifecycle: what to submit, what the result looks like (GLB URL and snapshots), how to retrieve it via getApiJob, error conditions (429), cost, and auth requirements. The only minor omission could be accepted input formats or aspect ratio guidance, but that is not critical given how much is already covered.

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?

Although schema description coverage is reported as 0%, the description compensates fully by explaining every meaningful parameter: image (URL or base64), request_id (tagging and deduplication), texture_size (valid values and default), texture_type (allowed enum values and default), and target_num_faces (range and default). It adds value beyond the raw schema by clarifying semantics like 'credits only on success' and the concurrency limit.

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 and resource: 'Convert a single source image into a textured 3D model (image-to-3D).' This clearly states the action, the input, and the output, and distinguishes it from animation, video, or image-editing siblings. It also names the concrete deliverable (GLB model URL plus snapshot image URLs), leaving no ambiguity 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 provides clear context for when to use the tool: converting a single source image into a 3D model. It does not explicitly name alternative tools or state when not to use it, but the purpose is specific enough that an agent can infer the appropriate scenario. It also gives operational guidance on the async workflow and polling, which further clarifies usage.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: credits charged on success, API key requirement, 202 immediate response, polling via getApiJob, 50-job queue limit, and 429 error. However, there is a significant internal contradiction: 'there is no separate polling step' is immediately followed by detailed polling instructions. This inconsistency prevents a perfect score and could confuse an agent about whether polling is required.

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 dense and front-loaded with the primary purpose and examples. It is longer than typical, but almost every sentence carries operational value (auth, polling, rate limits, credits). The main flaw is the contradictory 'no separate polling step' sentence, which is misleading and does not earn its place; removing or correcting it would make the structure cleaner.

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?

This is a complex tool with async behavior, rate limiting, auth, credits, and siblings. The description covers all of these, explicitly tells the agent how to retrieve the result (poll getApiJob, read its result field), and notes the result is a single audio URL. No output schema exists, so the description appropriately compensates by describing the output shape. The only minor blemish is the polling contradiction, but the explicit step-by-step polling instruction resolves it.

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?

Input schema coverage is 100%, so baseline is 3. The description restates some schema facts (description required, duration capped at 10, 0 means auto-pick) and adds marginal context for request_id (locate result via GET /assets/audio/results), but it adds no genuinely new parameter semantics beyond the schema. Thus the baseline 3 stands.

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 and resource: 'Produce a looping background ambiance soundscape from a text description' with concrete examples. It also explicitly names sibling tools and distinguishes them ('use createSoundEffect for short discrete sound effects, createMusic for musical pieces, and createAudioTransform to remix an existing audio sample'). This leaves no ambiguity about what the tool does or how it differs from alternatives.

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 when-to-use guidance: 'Use this for continuous, atmospheric background loops' and explicitly routes to createSoundEffect, createMusic, and createAudioTransform for other cases. It also covers prerequisites (API key user scope), async job flow (returns 202, poll getApiJob with wait 30), and rate-limit behavior (429 when >50 jobs). The guidance is actionable and leaves little to inference.

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

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

With no annotations, the description carries a heavy burden and discloses a lot: 15MB limit with HTTP 400, 202 async job, polling via getApiJob(wait:30), 50-generation concurrency limit with 429, credits on success, and API-key requirement. One confusing phrase, "there is no separate polling step," immediately followed by polling instructions, prevents a perfect score.

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 long but front-loads the purpose, then groups constraints and operational details logically. However, it repeats material already in the schema and includes the contradictory "no separate polling step" sentence, so not every sentence earns its place.

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 an async, credit-consuming generation tool with no output schema and no annotations, the description covers most operational essentials: auth scope, result format (single audio URL), polling path, rate limit, and credit cost. The main gaps are the polling contradiction and the lack of a clearer description of the final response shape beyond 'contains a URL.'

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 schema already documents every parameter; the description mostly restates that information. Worse, it contradicts the schema on modification_strength default ("default 0.5" in the description vs "Default: 0.6" in the input schema), which can mislead an agent.

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 action and object: "Remix an existing audio sample ... into a variation guided by a text prompt," with concrete examples (80s synthwave, metal). It also names the closest siblings it is not (createSoundEffect, createAmbiance, createMusic), making the distinction unambiguous.

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?

It explicitly says "Use this to transform existing audio you already have; use createSoundEffect, createAmbiance, or createMusic to generate audio from scratch." It also gives operational guidance on polling, request_id deduplication, and queue-limit behavior.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses async 202 behavior, the need to poll getApiJob, per-result credit costs, the 50-job queue limit with 429 behavior, API key scope, and the fact that no source image means no upload size limit.

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 long but every sentence carries operational value, and the primary purpose is front-loaded. It covers use cases, alternatives, async flow, limits, and credits without repeating schema details.

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?

This is a complex async image-generation tool with no output schema, yet the description explains the job lifecycle, result format, polling, queue limits, authentication, and alternatives. Nothing needed for correct invocation 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, but the description adds meaning beyond the schema: n controls the number of variations (1-8), image_type is exemplified with 'sprite', and request_id is explained as a tagging mechanism for later retrieval. This extra semantic context lifts it above baseline.

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 that createImage generates game-art images from a text prompt alone, naming the key selector image_type and optional style controls. It distinguishes itself from siblings by saying use createImage for new images from scratch, while generateWithStyle, editImage, and removeBackground serve different purposes.

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?

Explicit when-to-use guidance is provided: createImage is for creating new images from text, and the description names the exact alternative tools for style-matching, editing, and background removal. It also explains when polling is needed via getApiJob, giving clear operational context.

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

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

With no annotations, the description carries the full burden and does disclose a lot: 202/job-id async behavior, polling getApiJob with wait:30, credits charged on success, a 50-generation queue limit with 429, authentication, and request_id deduplication. However, it contains an internal contradiction: it first claims 'there is no separate polling step,' then instructs the agent to poll getApiJob until succeeded. This inconsistency undermines the transparency otherwise provided.

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 dense but logically arranged: purpose, examples, constraints, sibling routing, authentication, workflow, rate limits, and credits. Almost every sentence earns its place, but the inaccurate 'there is no separate polling step' sentence should not be there, so it is not a perfect 5.

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?

Given there are no annotations and no output schema, the description is unusually complete: it covers the full async workflow, how to poll, how to read the result field, rate-limit handling, credit cost, and request_id reuse. The only real completeness problem is the contradictory polling statement, which could cause an agent to skip the required getApiJob polling step.

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 100%, so the schema already fully documents description, lyrics, duration, request_id, and augment_prompt. The description mostly restates these constraints. The only genuine additions are that out-of-range duration returns HTTP 400 and an explicit reminder that description is required, but these do not substantially raise the score above the high-coverage baseline.

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 and object: 'Produce a piece of music from a text description,' including concrete examples like 'epic orchestral battle theme' or 'calm piano melody.' It clearly identifies the resource and separates this tool from createSoundEffect, createAmbiance, and createAudioTransform by naming what each sibling handles.

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 explicitly says when to use this tool versus alternatives: 'Use this for songs and musical scores; use createSoundEffect for short sound effects, createAmbiance for looping background soundscapes, and createAudioTransform to remix an existing audio sample.' It also states the API key requirement and that description is required, leaving little to inference.

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

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

With no annotations, the description carries full behavioral burden and delivers: async semantics (202 with job id, poll getApiJob with wait:30), credits charged on success, API key requirement (user scope), pending/daily job quotas, and request_id idempotency. Deducted one point for an internal contradiction: it claims 'there is no separate polling step' and then immediately instructs the agent to poll getApiJob until succeeded.

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 the core purpose and every sentence carries real operational info (auth, billing, quotas, polling), but the description runs to roughly 150 words and contains a redundant, misleading clause ('there is no separate polling step') that directly conflicts with the polling instructions and should have been cut or corrected.

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?

There is no output schema, but the description reconstructs the full invocation contract: required input, the single-audio-result-with-URL response shape, the polling procedure via getApiJob, where to read the result, auth scope, billing, and quotas. Nearly complete; only the self-contradictory polling statement undermines it.

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 100%, so the baseline is 3. The description mostly restates schema content (duration capped at 10 with 0 meaning auto-pick, loop for seamless looping) and adds only marginal extra meaning, such as request_id being usable to locate results later via GET /assets/audio/results. It does not meaningfully compensate beyond the schema.

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 ('Produce') and resource ('short sound effect (SFX) from a text description') with concrete examples like 'laser gun firing'. It also differentiates from audio siblings by scope ('short, discrete sounds'), so an agent can immediately tell it apart from createAmbiance, createMusic, and createAudioTransform.

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?

Explicitly says when to use it ('Use this for short, discrete sounds') and names three alternatives with their selection conditions: createAmbiance for continuous looping background soundscapes, createMusic for musical pieces, createAudioTransform for remixing an existing sample. It also flags prerequisites like required description field and required API key.

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

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

With no annotations, the description carries the full behavioral burden and does so extensively: it covers required inputs, size limits, 400 errors, auth scope, credit cost, 202 job responses, getApiJob polling, result shape, and 429 rate limiting. The only weakness is the internally confusing statement 'there is no separate polling step' followed later by instructions to poll getApiJob.

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 long but dense and front-loaded: it opens with purpose, then constraints, then usage routing, then async behavior. It earns most of its length, but the redundant credits sentence and the contradictory 'no separate polling step' line keep it from full marks.

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?

Given no output schema and no annotations, this description is remarkably complete: it explains the async 202/getApiJob flow, the result field, the single audio URL output, auth requirements, credit consumption, and the 50-job queue cap. Nothing essential for calling the tool correctly 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?

The input schema already covers text, sample, and request_id well, so the baseline is 3. The description adds meaningful constraints beyond the schema, especially the 15MB sample size cap, the HTTP 400 violation behavior, and how request_id can be used to locate results via GET /assets/audio/results.

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 and resource: 'Convert text to speech by cloning the voice from an audio sample you provide.' It further distinguishes itself from createSpeechPreset and createVoice, making the tool's unique role unmistakable.

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?

Explicit usage guidance is present: 'Use this when you have a reference voice sample to clone; use createSpeechPreset to speak with a built-in named preset voice instead, and createVoice to design a brand-new voice from a text description rather than cloning one.' This clearly tells an agent when to choose this tool versus alternatives.

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

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

The description provides rich behavioral context: required fields, 1000-character limit, HTTP ۴00 on invalid input, async 202 response, polling instructions, credit consumption, concurrency limit, and 429 error. However, it contains an internal contradiction: 'there is no separate polling step' is followed by detailed instructions to poll getApiJob. This could confuse an agent about whether polling is necessary, despite the later clarification.

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 front-loaded with a clear one-sentence summary, but the overall text is long and contains redundancy such as repeating required-field information and the contradictory polling statement. The credit line at the end is useful but could be integrated more succinctly.

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 the polling contradiction, the description covers nearly every important aspect for properly invoking the tool: auth, async behavior, polling method with wait parameter, result shape (single audio URL, result field), error codes, credits, concurrency limits, and idempotent request_id. For a complex async tool with no output schema and no annotations, this is quite complete.

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?

The schema covers 100% of parameters, so baseline is 3. The description adds some value by emphasizing that text and voice_predict_id are required, reinforcing the 100-character limit, and explaining request_id as a tracking/tagging mechanism. It does not significantly extend parameter meaning beyond the schema.

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 and resource: 'Convert text to speech using a named built-in preset voice', which clearly distinguishes it from the sibling createSpeech (voice cloning from sample) and createVoice (design from text). It also names accepted optional dimensions (emotion, language) without ambiguity.

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 explicitly states when to use this tool: 'Use this when you want a ready-made catalog voice and do not need to supply your own sample', and names the alternatives with their distinct purposes. It also mentions API key requirement, concurrency limits, and the 429 condition, which are essential usage constraints.

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

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

With no annotations, the description carries the full disclosure burden and covers a lot: 202 async behavior, polling via getApiJob, request_id idempotency, credits-on-success, auth, concurrency limits, and 429 errors. But it internally contradicts itself by first saying 'there is no separate polling step' and then instructing the agent to poll getApiJob, which obscures a critical behavior.

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 dense and well-organized, with purpose, constraints, polling flow, and limits addressed directly. It is longer than minimal, and some pricing/redundant schema details could be trimmed, but the structure is clear overall.

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 complex async tool with no output schema and no annotations, it covers the essential operational context: auth, input types, async job handling, polling instructions, error status, rate limits, and credit costs. The internal polling contradiction and reliance on 'API docs' for exact pricing/response details keep it from being fully complete.

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 100%, and the schema already richly documents model values, duration ranges, prompt, final_image, and request_id. The description adds useful compatibility and idempotency context, but mostly repeats or lightly extends structured information that is already present.

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 task — generate a short video clip from a source image and motion prompt — and names the output as a video URL and duration. It also differentiates from related tools such as createImage and animateSprite, making the purpose unmistakable.

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?

Explicitly says when to use this tool (image-to-video), explains the async poll flow, and names related alternatives for static images and sprite animation. However, it does not address sibling tools like createVideoFromReferences or editVideo, so the routing guidance is not exhaustive.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals the async 202 + job-id behavior, the need to poll getApiJob with wait:30, the exact result field to read, credit charging rules, 400/429 error behavior, the 50-job concurrency limit, and API-key requirement. This is exemplary transparency for a complex mutation-like operation.

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?

Although long, the description is compact for the complexity of the tool. It starts with the core purpose, then differentiates from siblings, then covers asynchronous behavior, limits, errors, and pricing in a logical progression. Every sentence contributes operational knowledge; none are filler.

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?

This tool has no output schema, so the description must explain return values and lifecycle. It does so completely: returns 202 with job id, poll getApiJob until succeeded, read the result field which is the documented response. It also covers failure modes, rate limits, auth scope, pricing, and the 1-5 image constraint. Nothing essential is missing for correct invocation and result retrieval.

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 value beyond the schema by explaining model/duration compatibility and the consequence of incompatibility (HTTP 400), clarifying that credits depend on produced duration but never exceed requested duration, and framing request_id as a tagging mechanism. These details enrich the parameter semantics without being redundant.

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 precise verb and resource: 'Generate a video from 1-5 reference images and a text prompt (references-to-video).' It explicitly distinguishes itself from createVideo, which animates a single source image, and names editVideo as a related but different tool. This makes the tool's identity and scope unmistakable.

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 clearly states when to use this tool vs. alternatives: createVideo is for image-to-video from a single image, editVideo is for modifying a generated video. It also supplies practical usage guidance: compatible model/duration combinations, async polling via getApiJob, request_id for deduplication and results lookup, and rate-limit behavior. An agent has enough context to invoke the tool appropriately.

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

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

With no annotations provided, the description fully carries the behavioral burden. It discloses that the call is asynchronous (returns 202 with a job id), requires polling getApiJob, charges credits on success, enforces a 200-character limit, and can return 429 when the queue is full. This is exemplary transparency for an API-driven 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?

The description is fairly long but every sentence serves a purpose: purpose, usage guidance, required parameters, limits, async behavior, polling instructions, and queue constraints. It is front-loaded with the main purpose and only then dives into operational details. It could be slightly tightened, but it remains highly informative without excessive redundancy.

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 no output schema and no annotations, the description provides a complete picture: what it does, how to call it, what parameters matter, error conditions, asynchronous behavior, result location, credit cost, and concurrency limits. An agent has everything needed to invoke the tool correctly and handle the response.

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 value beyond the schema by stating the 200-character limit as an error condition, clarifying that both voice_description and text are required, explaining how request_id ties to the GET /assets/audio/results endpoint, and noting the credit cost. It does not describe augment_prompt, but the schema already covers that.

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: design a new voice from a character description and have it speak a provided text line, returning an audio sample. It uses a specific verb and resource and explicitly distinguishes itself from sibling tools createSpeech and createSpeechPreset, which cover different text-to-speech use cases.

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 explicitly says when to use this tool ('invent and audition a voice from a description') and names alternatives for other scenarios: createSpeech for cloning from an audio sample and createSpeechPreset for named preset voices. It also provides practical usage details such as required parameters, character limits, and job polling instructions.

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

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

With no annotations present, the description fully carries the behavioral burden and does so thoroughly. It discloses upload validation, the 15MB rejection with HTTP 400, credit charging only on success, the 50-job concurrency limit with 429 errors, the 202-async response, idempotent request_id behavior, and authentication requirements. This level of detail is far beyond a minimal description and gives an agent realistic expectations for side effects and errors.

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 long but every sentence carries operational value, and the most important information is front-loaded: purpose first, then result format, then constraints. The only minor redundancy is the repeated credit information, but the final line adds the specific 0.5-credit cost, so it still earns its place.

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 no output schema and no annotations, this description is exceptionally complete. It covers input requirements, output shape, polling flow, error conditions, rate limits, auth scope, cost, idempotency, and sibling alternatives. An agent has everything needed to call this tool correctly and handle its asynchronous lifecycle.

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 meaning beyond the schema by explaining that results are arrays with a url field, that n controls the number of edited variations, and that credits scale with image count. It does not add detail for augment_prompt, but the schema already describes that parameter clearly.

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 and resource: "Modify an existing image according to text instructions." It clearly distinguishes this tool from sibling generation and editing tools by stating that it operates on an existing image, not on text-only generation or style borrowing.

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 provides explicit routing guidance: use editImage for transforming a specific existing image, createImage for text-only generation, generateWithStyle for borrowing art style, and removeBackground for background removal. It also explains the async job pattern and when to poll getApiJob, leaving no ambiguity about how to invoke and follow up on the operation.

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

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

With no annotations provided, the description carries full responsibility and delivers: it discloses auth requirements (API key, user scope), async behavior (202, poll getApiJob), rate limits (50 queued jobs, 429), credit charging rules, and the result shape. It also explains the conditional prompt requirements per edit_mode, going well beyond the schema.

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 long, but the complexity of the operation justifies most of the length. It is front-loaded with purpose, then covers sources, mode-specific parameters, async behavior, limits, and pricing. A small amount of redundancy exists with the schema's model credit information, but the overall structure is organized and every major operational concern is addressed.

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?

Given there is no output schema, the description compensates by explaining the result shape, async polling workflow, credit costs, and queue limits. It also covers mode-specific parameter acceptance and source constraints. An agent has enough information to call the tool correctly and handle the response lifecycle without additional lookups.

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%, but the description adds crucial semantic meaning: prompt is required/optional/not accepted depending on edit_mode, spritesheet_url must be a 7-day-old internally generated asset, request_id enables idempotency and result retrieval, and the result mirrors animateSprite's shape. This is meaningful guidance beyond the field descriptions.

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 and resource: 'Edit a previously generated spritesheet' and enumerates three concrete edit modes (prompt, outpaint, fix_loop). It clearly distinguishes itself from generation tools like animateSprite by requiring a previously generated spritesheet, so an agent can select it without confusion.

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 strong usage constraints: the input must come from animateSprite, transferMotion, or an earlier edit, must be within 7 days, and arbitrary external images are rejected. It does not explicitly name alternative tools for non-spritesheet edits (e.g., editImage) or say 'use X instead', but the scope and exclusions are clear enough for correct selection.

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

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

No annotations are present, so the description carries the full burden — and it delivers extensively: API key requirement (user scope), 202-with-job-id async behavior, credit charging only on success, 50-job concurrency limit with 429 PENDING_JOBS_LIMIT, request_id idempotency, and per-model credit pricing. It discloses cost, rate limiting, auth, and the polling contract, which are critical behavioral traits beyond anything the schema or annotations (none) provide.

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 long but densely informative for a tool with async, credit, and rate-limit complexity. It is front-loaded with the core purpose and the 7-day constraint before secondary details. Minor redundancy exists (credit/cost behavior appears in two places) and the single wall of text could be structured into paragraphs, but every sentence earns its place without fluff.

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 no output schema and no annotations, the description covers the full lifecycle: inputs and constraints, auth scope, immediate 202 response, polling instructions with wait:30, the result field mapping, return payload content (URL + duration), idempotency, rate limits, and error codes. The only minor hand-wave is 'exactly the response documented for this operation' since no output schema is attached, but the essential return values are explicitly stated.

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% with unusually rich per-parameter descriptions (model credit rates, duration value lists per model, request_id idempotency, image constraints), setting the baseline at 3. The description adds meaning by linking duration to the credit-charging policy and clarifying the job-result contract (new video URL + actual duration). It mostly supplements rather than repeats the schema, earning a modest upgrade.

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, and mechanism: 'Edit a previously generated video with a text prompt and optional reference images (video-to-video).' It names the sibling tools that generate the source clip (createVideo, createVideoFromReferences), making it immediately distinguishable from the video-generation and video-processing siblings. An agent can tell exactly what editVideo does and what it does not do.

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?

Gives explicit when-to-use guidance with alternatives: 'Related tools: createVideo to generate the source clip, createVideoFromReferences for reference-driven generation.' It also states hard preconditions (video must be generated by the account within the last 7 days, external URLs not accepted) and the exact post-invocation flow (poll getApiJob with wait:30). Routing decisions require no inference.

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

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 does so thoroughly. It discloses async behavior (202 with job id), how to poll via getApiJob with wait: 30, exact result location, credit charging only on success, the 50-job concurrency limit with 429 PENDING_JOBS_LIMIT, idempotency via request_id, and the structure of the result array. This is far beyond minimal and gives the agent a reliable execution model.

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?

Although the description is lengthy, every sentence provides necessary operational detail not available elsewhere. The first sentence is a clear front-loaded definition, and the rest follows a logical flow: behavior, result shape, async workflow, constraints, and costs. Given the absence of annotations and output schema, this length is justified and free of redundancy.

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?

This tool is a nontrivial async mutation endpoint with no output schema and no annotations, yet the description covers everything an agent needs: input format, constraints, result shape, polling instructions, idempotency, rate limits, errors, authentication, and cost. The description is effectively complete for correct invocation and result handling.

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 100%, so the structured schema already documents every parameter. The description repeats some parameter concepts like n variations and the 'Other' pose with free-text description, but it does not need to add much beyond the schema. It earns a baseline 3 because it complements the schema with workflow context without significantly extending the meaning of individual parameters.

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 and resource: 'Re-pose an existing sprite into a new target pose while preserving the character.' It clearly names inputs, output shape, and constraints such as sprite-only compatibility. It also distinguishes itself from sibling tools by positioning generatePose as the first step before animateSprite and contrasting it with rotateSprite.

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 explicitly tells the agent when to use this tool: 'This is typically the first step before animating.' It names a sibling alternative, animateSprite, and defines the chained workflow, and it tells the agent to use rotateSprite instead when changing camera angle. It also gives an exclusion criterion: only sprite image types, not icons or screenshots.

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

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

With no annotations, the description carries the full burden, and it excels: it discloses upload validation, 15MB rejection with HTTP 400, credit charging only on success, API key scope, 202 async response, polling via getApiJob, the 50-job queue limit, 429 PENDING_JOBS_LIMIT, and 0.5 credits per result. No behavioral trait that an agent would reasonably need is hidden.

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 dense but every sentence carries operational value: core action first, then result shape, then alternatives, then workflow, then limits and credits. It is long because the tool is genuinely complex, not because of redundancy or filler.

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?

The tool is async, has nested parameters, no output schema, and no annotations, yet the description covers the response shape, the polling workflow, the exact field to read, quota errors, authentication, and credits. An agent has everything needed to call it and interpret the result correctly.

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 value by explaining that style_image is uploaded and validated, that images over 15MB are rejected, and that credits scale with the number of results. These constraints go beyond the parameter descriptions in the schema while still relying on the schema for most parameter documentation.

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 and resource: 'Generate new images that match the visual style of a reference image.' It immediately distinguishes itself from siblings by naming createImage, editImage, and removeBackground and explaining which use case each serves.

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 guidance is explicit: 'Use this instead of createImage when style consistency with an existing asset matters; use editImage to alter the content of a specific image rather than borrow its style, and removeBackground to isolate a subject.' It also gives the async workflow (poll getApiJob) and rate-limit behavior, so an agent knows exactly when and how to invoke it.

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

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

The description discloses the return shape ('{id, status}') and explains how to interpret success ('succeeded' → read result) and failure ('failed' → read error). It also describes long-polling behavior, including the max wait of 60 seconds, making the tool's behavior fully transparent.

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 a single, well-structured paragraph. It leads with the main purpose, then explains the response format and polling behavior. There is no unnecessary repetition or verbosity; each sentence adds useful 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?

For a simple polling tool, the description covers all necessary aspects: what it does, how to use it (including polling and long-polling), what it returns, and how to handle results. It does not require additional context about authentication or error handling beyond reading the error field, which is sufficient.

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?

The schema describes 'wait' with a default and range, but the description adds context by explaining how wait relates to long-polling and the max value (60). It also clarifies that 'id' is the job id returned by any tool, which is not explicitly in the schema. However, the parameter meanings are fairly clear from the schema, so it only adds marginal value.

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 action ('Poll'), the resource ('the status of a generation job'), and the context ('started by any tool'). It also distinguishes itself by mentioning it works for jobs from any tool, which is helpful among siblings.

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?

It gives explicit guidance on polling frequency and long-polling: 'Poll every few seconds, or pass wait: 30 to long-poll'. It does not explicitly contrast with alternatives like listApiJobs, but the usage is implied by its purpose. Could be slightly more explicit about when to use this over listing jobs.

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

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

With no annotations present, the description carries the full burden and does so thoroughly. It states the method and shape ('Synchronous GET with no request body'), the exact return structure (animations array with fields, deduplicated perspectives, directions), the free/credits behavior, the retargetable clip_url condition, and the API key requirement with user scope. This far exceeds minimum behavioral disclosure.

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 lengthy but front-loaded with the core purpose, then the return schema, then usage directions, then auth requirements. Every sentence earns its place given the lack of an output schema and annotations. The explicit list of eight compass directions and the long field enumeration make it dense, but not wasteful.

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 zero-parameter, read-only discovery endpoint with no output schema, annotations, or nested objects, the description is unusually complete. It covers what the tool returns field-by-field, how to use those results, which sibling tools consume them, the synchronous GET nature, free credit behavior, and auth scope. No meaningful information an agent needs to invoke it correctly 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?

There are zero parameters, so parameter semantics are inherently simple. The 100% schema coverage of an empty properties object leaves nothing ambiguous. The description adds useful context about what values the tool returns for downstream consumers, which is the closest analog to parameter-related guidance in this case.

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 and resource: 'List the available animation presets along with their perspectives and the eight supported compass directions.' It clearly distinguishes itself from siblings by naming transferMotion, animateSprite, and animate3DModelPreset as related tools that consume this tool's output, and by emphasizing it is a discovery endpoint rather than an animation-applying tool.

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?

It explicitly tells an agent when to use this tool: to obtain preset_id, perspective, and direction values for transferMotion, and to find preset names for animation. It also names related sibling tools that the presets can be paired with. There is no explicit 'do not use when...' exclusion, but the discovery-vs-application contrast is clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states this is a 'free read-only lookup (no credits, no generation),' which is critical safety information, and adds ordering, default limit/cap, API key requirement, and source scope. It does not describe the response shape or what happens when more than 100 jobs exist, but the disclosed behavior is far stronger than typical.

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 front-loaded with the main purpose and then provides scope, safety, filtering, and auth context in four additional short sentences. Each sentence contributes meaningful information, though the filtering and limit default/cap sentences overlap with schema descriptions, creating slight redundancy.

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 simple two-parameter list tool with no output schema, the description covers everything an agent needs before invocation: source scope, ordering, cost/safety, authentication, filter format, default limit, and cap. The only minor omission is pagination beyond the cap, but the tool name, schema, and sibling context make the expected behavior clear enough.

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 100%, so the schema already documents both parameters fully. The description repeats the limit default/cap and mentions comma-separated status filtering, but adds no new semantic information beyond what the schema provides. Baseline 3 is appropriate.

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 ('List') and a clearly bounded resource: 'generation jobs you started through the API or MCP.' It also adds a scope constraint ('Web-app jobs are not included') and an ordering guarantee ('most recent first'), which differentiates it from broader listing tools like listGenerations without needing to name them.

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?

It provides clear context and an explicit exclusion: 'Web-app jobs are not included,' so an agent knows not to use this tool for web-app jobs. It also states a prerequisite ('Requires an API key (user scope)') and describes filtering and limit behavior. It stops short of naming alternative tools such as getApiJob or cancelApiJob, so it earns a 4 rather than a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the pagination contract (has_more-driven paging), output shape, and the 7-day expiration of API-originated results. It does not mention sorting or error behavior, but the disclosed behaviors are substantial.

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?

Each sentence earns its place: scope/filters, pagination protocol, retention warning, and alternative routing. It is front-loaded with the core purpose and contains no filler or repetition.

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 and no annotations, the description tells the agent what the response looks like, how to page through results, that results may expire, and which sibling tool to use for a different need. That is sufficient for correct invocation.

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 100%, so the baseline is 3. The description's first sentence summarizes filter capabilities but does not add meaning beyond the schema. The only meaningful extra information is the pagination/output shape, which is behavior rather than parameter semantics.

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 names a specific verb and resource: listing generation history across API and web app. It also gives the exact filtering dimensions (type, source, text, date), making the tool's scope immediately identifiable and distinct from job-status tools.

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 explicitly routes in-flight job status checks to getApiJob instead, and it warns that API-originated results expire after 7 days so the agent knows when to download. This gives clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden, and it delivers: it discloses authentication requirements, 15MB rejection with HTTP 400, credit charging only on success, asynchronous 202 behavior, polling instructions, per-account job limits, 429 errors, and result shape. This is exceptionally transparent for an async API 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?

The description is long but information-dense and mostly front-loaded with the core purpose. Some parameter-level details repeat schema descriptions, slightly reducing conciseness, but every sentence contributes operational context needed for correct invocation.

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?

The tool has no output schema and nontrivial async behavior, so the description must explain the full workflow. It covers the job lifecycle, polling, result extraction, authentication, error cases, credit cost, and request deduplication. Nothing essential is missing for an agent to call and interpret this tool correctly.

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, but the description adds meaningful context beyond the schema: request_id can tag results for later retrieval via a specific endpoint, creative_edit's pixel-for-pixel tradeoff is called out in prose, and the result is clarified as a single URL rather than an array. This adds value without duplicating all schema wording.

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 and resource: 'Remove the background from a single image, returning the subject isolated on a transparent background.' It then explicitly distinguishes removeBackground from sibling tools like editImage, createImage, and generateWithStyle, making the tool's unique purpose unmistakable.

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 clear when-to-use guidance: 'Use removeBackground for this dedicated cutout task; editImage can also remove backgrounds via a prompt but is better for broader edits, while createImage and generateWithStyle produce new images rather than process an existing one.' It also covers operational usage such as polling getApiJob with wait: 30 and handling the 429 limit.

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

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

With no annotations, the description carries the full burden and exceeds it: it discloses that rigging is non-destructive to geometry but replaces prior skeletons, that credits are charged only on success, that results are async via a job id requiring polling with getApiJob, that the API key needs user scope, and that a 50-job queue limit returns 429. This is exemplary behavioral disclosure.

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 dense but every sentence earns its place: purpose, input, output, parameter semantics, async behavior, limits, and credits are all covered in a logically ordered block with the most important action front-loaded. Despite its length, no information is redundant or filler.

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?

This is an async, mutating, rate-limited, credit-consuming operation with no annotations and no output schema, yet the description covers authentication, job submission, polling, result extraction, queue limits, idempotency, and cost. An agent has everything needed to invoke the tool correctly and handle edge cases like 429 responses.

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?

The description substantially enriches every parameter: it explains model accepts URL or base64 GLB, details each rig_type variant including joint counts and suitability constraints, clarifies joint_naming is purely relabeling without changing the skeleton, and describes request_id idempotency. This goes far beyond the schema's basic descriptions.

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 and resource: 'Rig a 3D model: generate a skeleton and skin weights for an existing GLB so it can be animated.' This clearly distinguishes it from sibling tools like create3DModel or animate3DModel, and the scope is explicit: existing GLB assets only.

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 provides clear context on when to use the tool: before animating a rigged model, and specifically calls out humanoid_template as required for using the animation preset library. It does not explicitly name sibling alternatives or state when not to use it, but the intended workflow is strongly implied and actionable.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses async behavior (202 with job id, poll getApiJob), authentication requirements, rate limits (50 queued jobs, 429), billing behavior (credits charged only on success, 0.5 per result), idempotency via request_id, and the shape of the job result.

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 dense but front-loaded with the core purpose and alternatives. Most sentences earn their place, covering async flow, rate limits, credits, and result handling. It loses a point because it repeats several parameter constraints already fully documented in the input schema, making it longer than strictly necessary.

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 complex async tool with no output schema and no annotations, the description is remarkably complete. It tells the agent how to invoke it, what to pass, what response to expect, how to poll for completion, what the result contains, how crediting works, and what limits apply. An agent has enough context to call and retrieve results correctly.

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 100%, so the baseline is 3. The description repeats most parameter details already in the schema, such as accepted camera_rotation values, camera_elevation values, and n range. It adds some contextual meaning about image type restrictions and result mapping, but does not add substantial new parameter-level semantics beyond the schema.

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 and resource: 'Re-render an existing sprite from a different camera viewpoint while keeping the same character and pose.' It clearly defines what the tool does and distinguishes itself by name from siblings like generatePose, animateSprite, and transferMotion, so an agent can select it correctly.

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 provides explicit usage guidance: 'Use this to produce alternate view angles of a character; use generatePose instead to change the character's pose rather than the camera, and animateSprite or transferMotion to bring a sprite to life.' It also gives a clear exclusion: 'Only works with sprite image types (not icons, screenshots, etc.).'

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

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

With no annotations, the description carries the full transparency burden and covers a lot: async 202 + job polling, 400 error conditions, credits charged only on success, rate limits, and 429 behavior. However, it internally contradicts itself by first stating the result comes 'with no polling step' and then instructing the agent to poll getApiJob. This inconsistency reduces trust in an otherwise detailed disclosure.

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 a dense wall of text with no bullet points or clear sectioning. It repeats pricing information that already exists in the model parameter description, and the contradictory polling statements create noise. While the content is mostly useful, the structure makes it harder for an agent to quickly extract key operational steps.

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?

Given there is no output schema and no annotations, the description is unusually complete: it explains the asynchronous flow, expected result location, error conditions, rate limiting, and credit costs. The main gap is the polling contradiction, and the exact response JSON structure is not spelled out, but the description points to the operation's documented response via the getApiJob result field.

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 value beyond the schema by clarifying the cross-parameter requirement that either a video or the preset_id/perspective/direction triple must be supplied, and by linking invalid combinations to HTTP 400. It also adds cost semantics tied to model and actual produced duration, which is not fully expressed in the schema.

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 opening sentence precisely states the verb ('Transfer'), the source ('reference video or named animation preset'), the target ('static sprite image'), and the output ('animated spritesheet'). It also distinguishes itself from animateSprite, noting that animateSprite generates from a text prompt, which removes ambiguity among sibling tools.

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 explicitly says to use this tool when an existing motion clip or preset is available, and to prefer animateSprite for purely text-driven animation. It also instructs the agent to call listAnimationPresets first to obtain valid preset_id, perspective, and direction values, giving clear, actionable routing guidance.

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

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

No annotations are provided, so the description carries the full burden and handles it thoroughly. It discloses asynchronous behavior (returns 202 with a job id, poll getApiJob until success), billing details (per-second, charged only on success, 0.2 credits per second), rate limits (50 concurrent jobs, 429 PENDING_JOBS_LIMIT), and auth requirements (API key, user scope). It also clarifies what the result contains and how to read it.

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 long but every sentence earns its place: constraints, billing, async flow, rate limits, credits, and related tools. It front-loads the core action and then layers essential operational details in a logical order without redundancy.

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 and no annotations, the description covers all necessary operational aspects: request constraints, async response handling, polling instructions (getApiJob with wait: 30), result extraction, billing, rate limits, and prerequisites. An agent has enough information to invoke the tool correctly and handle the outcome.

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 100%, so both video and request_id are already documented in the schema. The tool description adds operational context—like the source endpoints and how to locate results—but does not add significant new meaning beyond what the schema already states. Baseline 3 is appropriate.

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 and resource: 'Upscale a previously generated video to twice its resolution (2x).' It distinguishes itself from siblings by naming createVideo and editVideo and their respective purposes, so an agent can immediately identify what this tool does and how it differs.

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?

It provides explicit when-to-use context: pass a video URL received from createVideo, createVideoFromReferences, or editVideo; only videos under 960x960 and generated within 7 days are accepted. It also states when-not-to-use conditions (external videos not accepted, larger sources rejected) and names related tools and their specific uses, giving the agent clear routing guidance.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does disclose the success/error status codes, which is useful, but it fails to explain how the API key is supplied (since the schema has zero params) or mention any potential side effects. The 200/403 detail is valuable but the input mechanism remains opaque.

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 one efficient sentence that conveys the core purpose and expected responses with zero waste. It is ideally concise and front-loaded.

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 simple tool with no schema, annotations, or output schema, the description covers the essential purpose and responses. The only gap is the lack of explanation on how the API key is provided, but given the zero-parameter design, this is likely handled externally, making the description largely complete.

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 are zero parameters, so the baseline is 4. The description identifies the subject (API key) but does not clarify how the key is transmitted, given the empty schema. However, since no parameters are expected, the description does not need to detail parameter values; still, a note about implicit authentication context would improve it.

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 uses a specific verb 'validates' and the resource 'API key', clearly stating what the tool does. It also provides distinct status codes (200/403) that set it apart from sibling tools, which are all media-related.

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 implicitly indicates this is for checking API key validity, but it does not explicitly state when to use it or mention any alternatives. Given that all sibling tools are unrelated, some contextual guidance on when to invoke validation would be helpful.

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