spriteship

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

The description discloses critical behavioral traits beyond annotations: it defaults to a cost preview (dryRun=true), returns only estimatedCredits and billing info, requires explicit user confirmation before spending, and mentions server rejection with 400 for missing pairs. It also explains the self-loop behavior for seamless tiles. Annotations only say openWorldHint=true and readOnlyHint=false, but the description adds substantial context about billing, dry-run flow, and error handling.

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: it starts with PAID (image-to-video) to set expectations immediately. It packs a lot of actionable guidance into a few sentences, and every sentence serves a purpose (cost, animation behavior, grid-specific instructions, user confirmation requirement, error handling, dry-run default, return type). It's slightly long but justifiably so.

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 tool has 9 parameters, no output schema, and only basic annotations, the description is remarkably complete: it explains the cost model, dry-run flow, grid vs single-image behavior, user confirmation necessity, error handling for missing pairs, and what the response contains ({ jobId }). It even provides specific examples of ambiguous requests like 'Animate the treasure box' to illustrate the need for clarification. This covers all key operational aspects.

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 by explaining the dryRun argument's purpose (cost preview, show user estimatedCredits, then re-call with false), and the pairs argument's meaning for grid assets. It also clarifies the idempotencyKey usage for retries. However, some parameter details like videoModel and motionHint are not elaborated in the description 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 clearly states what the tool does: 'Animate ANY asset type' with image-to-video, landing on the source asset, and preserving the still image. It distinguishes this from siblings like frame_animation, create_animation_from_pose, and revise_asset by emphasizing that it works on any asset type and is paid.

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 when-to-use guidance: it tells the agent to ask the user which stages first, call get_asset to see tiles, and get explicit start/end before spending. It also gives exclusion guidance: 'do not satisfy it by defaulting to 0→last' and explains the 400 error for grid animate with no pairs. This is strong usage guidance with clear alternatives and prerequisites.

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 adds useful behavior beyond annotations: it states the operation is 'FREE' and that 'Outstanding credit charges for the aborted work are refunded automatically.' This is valuable context not present in the annotations, which only indicate mutability.

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 extremely concise: two sentences, zero filler. It front-loads the key action and includes the most important caveat (refund behavior) without wasting words.

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 one-parameter tool with no output schema, the description covers the core purpose, usage timing, and a key behavioral detail (refund). It could mention what happens if the job is already finished, but the simplicity and annotations make it adequately 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 already covers the single parameter jobId with a clear description ('Job id to cancel.'), so the tool description adds no additional parameter information. Baseline 3 is appropriate given high schema coverage.

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 and resource: 'Abort a running job.' It clearly identifies the tool's function and distinguishes it from siblings like retry_job or get_job by focusing on cancellation of an in-progress process.

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 usage context: 'Use this when a generation is clearly going wrong rather than letting it run to completion.' It implies the alternative is letting the job finish, but doesn't explicitly mention other tools like retry_job for post-failure scenarios.

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?

Annotations already indicate non-read-only and non-destructive behavior. The description adds valuable context: it returns a jobId (asynchronous, requiring polling get_job), handles the __idle__ special case, scales the animation to match other animations, and exports to every engine. These details go beyond the annotations and set accurate expectations for the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each serving a distinct purpose: the first states the core functionality and differentiators, the second covers the __idle__ edge case, and the third explains the async return and polling. Information is front-loaded and 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?

There is no output schema, so the description properly explains the return value (jobId) and directs the agent to poll get_job. It also covers the __idle__ fallback and the scaling/export behavior, making the tool's workflow clear. For a moderate 5-parameter tool, this 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?

Schema coverage is 100%, with all 5 parameters described in the schema. The description reinforces the special '__idle__' value for poseId but does not add new information about fps, newId, displayName, or characterId beyond what the schema already 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 uses a specific verb ('Promote a pose') and clearly identifies the output as a 'real 1-frame animation (a still/idle)'. It distinguishes from siblings by emphasizing the pose-to-animation conversion and the scaling to match other animations, making the tool's 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 states this is 'FREE, no AI', implying it is a lightweight alternative to AI-driven animation generation. It clearly explains the use case: converting a pose into a 1-frame animation that scales and exports. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of fully explicit 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?

Beyond the annotations (readOnly=false, destructive=false), the description discloses that the call is PAID, defaults to a cost preview via dryRun, returns {jobId, assetId}, can fan out into four assets appearing as gridAssetIds in get_job, and that grid sheets may be cut wrong even when the job reports done. This is rich behavioral context that significantly aids an agent.

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 (~180 words) and front-loads an exception ('tileset and staged REQUIRE gridRows+gridCols') before stating the core purpose. While every sentence carries value, the structure could be better ordered by leading with the tool's main function. Still, for a complex 21-parameter tool, the density is justified.

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?

Without an output schema, the description explains return values (jobId, assetId), job polling via get_job, fan-out behavior, and the grid.complete verification step. It also covers the dryRun flow and projectId requirement. For a tool this complex, it leaves few gaps beyond what the schema already documents.

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 already covers all 21 parameters with 100% coverage, so the baseline is 3. The description adds cross-parameter behavior not in the schema: setting gridRows:2+gridCols:2 on a static asset yields four variations for one call, texture always produces four, and terrain is a 3×3 auto-tiling sheet. It reinforces the gridRows/gridCols requirement and dryRun default, adding real 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 'Creates a NEW asset from a prompt' and enumerates all six asset types with brief definitions. It distinguishes this from sibling tools like revise_asset and animate_asset by emphasizing 'NEW' and by noting that staged assets are the input to animate_asset.

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: ask the user how many tiles/stages for tileset/staged, requires projectId, and explains the dryRun cost-preview flow before spending credits. It also directs users to poll get_job and check grid.complete for tileset/staged, and notes that terrain has no per-tile edit path. It does not explicitly name alternative tools, but the create-vs-revise distinction is implied.

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 far more than annotations (readOnlyHint:false, openWorldHint:true, idempotentHint:false, destructiveHint:false). It reveals the ~150 credit cost, that dryRun defaults to true and returns a cost quote, that the call returns { jobId, expectedCharacterCount }, and that gameType is inherited rather than parameterized. This gives the agent a complete behavioral model without contradictions.

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 useful information, covering cost, entry point, image-only output, grid variations, return/poll behavior, gameType inheritance, and the dryRun flow. It is appropriately sized for an 11-parameter tool, but it is a single wall-of-text paragraph with many parenthetical asides; breaking it into scannable bullets would improve readability. Still, it is front-loaded with the most critical facts ('PAID', 'Generate a NEW character').

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 tool's complexity (11 parameters, no output schema, cost implications), the description is remarkably complete. It explains the return value and how to poll get_job for results, describes the dryRun cost preview response, and clarifies the relationship between project gameType and character orientation. The agent has everything needed to select and invoke this tool safely.

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 already documents all 11 parameters (100% coverage), the description adds critical context beyond the schema: gridRows and gridCols together produce four variations for the same price; dryRun defaults to true and requires a two-call approval flow; idempotencyKey should be reused on specific retries to prevent double-dispatch. These semantic enrichments materially improve the agent's ability to invoke the tool correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Generate a NEW character from a text prompt' and clearly positions it as the entry point for creating art from nothing. It also explicitly distinguishes itself from sibling tools by noting that animation is a separate step (generate_character_animation, generate_character_turn), which eliminates 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 provides explicit when-to-use guidance: call create_project first if no project exists, use gridRows:2 and gridCols:2 to get four variations, and follow the dryRun flow for user approval before spending. It also tells the user when NOT to use this tool (i.e., for animation, which has separate tools), making the decision boundary very 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?

Discloses FREE and SYNCHRONOUS execution (no jobId), the permanent nature of gameType, and the side effect of seeding a starter level map. These additions go well beyond the annotations (readOnlyHint=false, openWorldHint=true, etc.), which don't mention cost, sync/async, permanence, or map seeding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, front-loaded with critical FREE/SYNCHRONOUS information. Every sentence carries unique content: creation container, gameType impact, starter map seeding, and reuse guidance. No wasted words.

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 4-parameter create tool with no output schema, the description is thorough about prerequisites, side effects, and the key gameType constraint. It doesn't describe the return value, which is a minor omission, but the overall context is complete enough for an agent to invoke 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 why gameType matters—'is what decides how they are drawn and animated'—reinforcing its importance beyond the schema's enum listing. It does not add detail for name/style/description, but those are already well-documented 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 description clearly states it 'creates the container everything else needs', specifying that characters and assets are created inside a project. It distinguishes from siblings by explaining that the project is the root resource and that gameType determines how resources are drawn and animated. Mentions the starter level map side effect as part of its purpose.

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 instructs to call list_projects first and reuse an existing project rather than making a near-duplicate. Also frames this tool as the prerequisite for creating characters and assets, clarifying when to use it. Notes SYNCHRONOUS behavior so the agent knows not to poll.

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?

Beyond annotations, the description discloses that the original is untouched (non-destructive), that the operation is FREE with no AI, and that it returns a jobId requiring polling via get_job. These are valuable behavioral details not present in the annotations or 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 two sentences that efficiently convey cost, operation, use case, example, safety guarantee, and return behavior. Every sentence serves a purpose, and the most critical info (FREE, no AI) 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 tool's simple 3-parameter schema and no output schema, the description sufficiently covers its purpose, usage context, async return, and non-destructive nature. It is complete for an agent to invoke 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?

The schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaning by explaining the purpose of the new slug (e.g., creating a directional idle) and referring to the source animation, which enriches the context 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 explicitly states 'Clone an animation under a new slug' and elaborates on the purpose of curating a different frame subset. This distinguishes it from siblings like mirror_animation or animate_asset, making the tool's specific function 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 provides clear context for when to use the tool ('so you can curate a DIFFERENT frame subset on the copy') and includes a concrete example workflow with select_frames. It does not explicitly name alternative tools or exclusions, but the guidance is practical and sufficient for an agent.

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?

Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds useful behavioral context by stating output is 'engine-ready map JSON' from 'SAVED level data' with custom fields baked in, clarifying the source and transformation. No contradictions found.

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 two sentences, with the primary purpose stated first and the alternative tool mentioned second. Every word adds value, and there is no redundancy or 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 simple export tool with only two parameters and full schema coverage, the description adequately conveys the output type (JSON), source data (SAVED level), included transformations (custom-field values baked in), and alternative use case (zip bundle). No output schema is needed, and the explanation covers the essential context.

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 clear parameter names and descriptions for mapId and engine. The description does not add parameter-level details, but since the schema already fully documents both parameters, the baseline score of 3 applies.

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 produces 'Engine-ready map JSON' from saved level data with custom-field values baked in. It distinguishes itself from the sibling get_export_command, which handles the zip bundle, making the tool's specific purpose and resource 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?

The description explicitly directs users to get_export_command for the zip bundle alternative, providing clear when-to-use guidance. It also implies the tool is for JSON-only exports, which aligns with its title and avoids confusion with sibling export-related tools.

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 adds substantial behavioral context beyond the annotations: it discloses the credit cost (~100 credits), the fact that it makes one image-to-image call, that it produces a new current revision, that it defaults to a cost preview (dryRun), and that it returns a jobId requiring polling via get_job. These details are not in the annotations (readOnlyHint false, destructiveHint false, etc.) and are crucial for correct invocation and user communication.

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 concise yet information-dense. Each sentence serves a purpose: flagging the cost, stating the core action, pointing to the free pre-check, warning against unnecessary spending, describing the revision outcome, and explaining the dryRun default and return value. There is no fluff, and critical information is front-loaded with the cost warning.

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 paid, async tool with complexity around dryRun and idempotency, the description is remarkably complete. It covers prerequisites (get_asset check), cost, default behavior, return shape ({ jobId }), and next steps (poll get_job). The lack of an output schema is compensated by this explicit return description, and the tool's side effects are clearly 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?

The schema description coverage is 100%, so the baseline is 3. The description does not add significant parameter-level meaning beyond what the schema already provides for assetId, iterationId, dryRun, and idempotencyKey. It does reinforce the dryRun default and cost preview behavior, but that is already in the schema, so no additional value is added.

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: 'Make a texture tile seamlessly.' This is a specific verb+resource combination that immediately distinguishes it from sibling tools like revise_asset or reprocess_asset. It also provides critical context about being a paid image-to-image call, which further differentiates it from free inspection 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 gives explicit usage guidance: check get_asset first, use the free seamMetric.pass verdict to avoid spending credits on cells that already tile, and do not spend on passing cells. It also instructs to use the dryRun argument to preview cost and get explicit user approval before the real call. This clearly tells the agent when to use 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 transparently discloses key behavioral aspects: it is free, uses no AI, no credits, no approval required. It explains how the animation is composited into a spritesheet and mentions the return behavior ('Returns a jobId — poll get_job'). This goes beyond annotations, which are sparse.

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 well-structured: opens with the key differentiator (FREE, no AI), explains the mechanism, lists examples, gives usage guidance, and closes with the return value. Every sentence earns its place without being overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description covers return value (jobId) and specifies how to poll. It also provides sufficient context for a 5-parameter tool, including prerequisites (tiles exist, grid asset) and destination (every engine). The alternative tool is named, making the context 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 coverage is 100%, so parameters are already described. The description adds semantic value, particularly for frameIndices, explaining that repeats allow holding or ping-ponging a frame. It also reinforces assetId must be a grid asset, though this is in the schema as well.

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: animate a grid asset by using its tiles as frames. It uses specific verbs and resources, and explicitly differentiates from sibling animate_asset by mentioning 'Try this before animate_asset whenever the motion already exists across the tiles.'

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?

Provides explicit usage guidance including when to prefer this tool over animate_asset, with concrete examples (coin flip, flickering torch, chest opening). Also states the condition 'whenever the motion already exists across the tiles', effectively telling when not to use 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 critical behavioral traits (paid, cost multiplication, regeneration, PROMPT_TOO_LONG, dryRun default, return shape). However, it states that an existing animation name is REGENERATED, implying it overwrites existing animations, which contradicts the annotation destructiveHint: false. This is an annotation contradiction, so the score is 1.

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 high-value information: cost warning, sibling differentiation, usage steps, edge cases, return payload, error behavior, and dryRun default. It is logically structured and front-loaded with the most critical warning about cost multiplication, so it is concise in effect.

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 paid tool with 8 parameters, nested objects, and no output schema, the description covers cost, return shape ({ jobId, animations }), error handling (PROMPT_TOO_LONG), default behavior (dryRun), sibling edge cases, and prerequisites. It provides enough detail for an agent to invoke the tool correctly, despite the annotation contradiction, because the description itself is transparent about regeneration.

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 has 100% parameter description coverage, providing a baseline of 3. The description adds meaningful context beyond the schema by explaining cost per animation, dryRun as a cost preview, regeneration behavior for existing names, and the need for user confirmation before spending. This elevates it to 4, but not 5 since it does not elaborate on every parameter.

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 generates character animations (walk, attack, idle), and explicitly differentiates from create_animation_from_pose which produces a 1-frame still. It names the resource (character) and the action (generate animation), making its purpose 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?

The description provides detailed usage steps: read the character's gameType, use standard animation names, check existing animations via get_character, ask the user which animations to spend credits on, show previews for multi-sibling characters, and default to dryRun for cost approval. It also contrasts with create_animation_from_pose, making it clear when to use this tool instead.

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 far more than annotations: credit cost (~400), error codes (400 TURN_NOT_SUPPORTED, 409 ANIMATION_EXISTS, 409 ENTITY_BUSY), side effects (rebuilds spritesheet, clears cached frames on regenerate), concurrency constraints, default dryRun behavior, and the return shape. No contradiction with annotations exists.

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; every sentence carries critical detail about cost, supported types, errors, side effects, and default behavior. It is reasonably front-loaded with the cost warning and main function. It could be improved with more structured formatting (e.g., bullets) but is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully carries the burden of explaining return values ({ jobId, animation }), error conditions, side effects, and the dryRun preview state. It covers all essential behavioral and contextual aspects needed to safely invoke the tool, including cost, concurrency, and regenerating behavior.

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 does not add per-parameter meaning beyond the schema; it reinforces the dryRun flow and idempotency usage but these are already covered in the schema's parameter descriptions. No gap to compensate for.

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?

Clearly states the tool generates a 360-degree turn animation, with specific verb ('spins'), resource (character sprite), and scope (full 360 rotation). It distinguishes from siblings by noting that it feeds the directional-pose extractor and is only for topdown/isometric characters, whereas platformer/point_and_click use mirroring instead.

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 specifies when to use this tool (topdown/isometric games) and when not to (platformer/point_and_click, where mirroring is the alternative). It also explains the dryRun cost-preview flow, the need to poll existing jobs first, and the regenerate:true option to handle existing animations.

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 enriches annotations substantially: it reveals paid usage, the dryRun default returning a cost quote, the actual execution flow, absence of jobId, and the need to poll. This goes far beyond the annotations (readOnlyHint=false, openWorldHint=true, etc.) and clearly discloses important behaviors.

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 two sentences with high information density: paid status, generation purpose, dryRun default, return value, polling instruction. It is front-loaded and every phrase earns its place, with no redundant wording.

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 7 parameters, no output schema, and cost implications, the description thoroughly covers the essential workflow: cost preview, actual execution, return shape ({ poseId }), polling behavior, and idempotency retry guidance. Combined with the rich schema, it leaves no obvious gaps.

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 explains all parameters in detail, including dryRun, idempotencyKey, and referencePoseId. The tool description reiterates the dryRun behavior but doesn't add new parameter meaning beyond what the schema provides, so 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 clearly states the tool 'Generate a new pose for a character from a text description' with a specific verb and resource. It distinguishes from sibling tools by emphasizing text-based pose generation and mentions the output format ({ poseId }).

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?

Provides strong usage context: explains the cost-preview default, the two-step dryRun flow, and instructs to poll list_character_poses for completion. However, it doesn't explicitly mention when not to use this tool or name specific alternatives, so it misses the full 'when-not' criterion.

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 numerous behavioral traits beyond the annotations: it is 'PAID but very cheap (one Gemini call)', 'SYNCHRONOUS', 'Stores NOTHING', and defaults to a cost preview. These are safety and cost implications not captured by readOnlyHint (false), openWorldHint (true), idempotentHint (false), or destructiveHint (false). The description significantly reduces the risk of an agent invoking it without understanding the paid, non-idempotent nature. No contradictions with annotations.

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 providing essential information: cost and synchronous behavior, output structure, storage side-effect, and dryRun default. It is front-loaded with the most critical differentiator (PAID) and avoids redundancy. Every sentence earns its place, and the structure makes the tool's unique aspects immediately visible.

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 tool's complexity (7 parameters, no output schema, paid execution), the description is remarkably complete. It covers the cost model, synchronous response, lack of jobId, output fields, side effects (stores nothing), default dryRun behavior, and how to chain the output into create_project. The schema covers parameters thoroughly, and the description covers behavioral context, making it sufficient for an agent to select and invoke 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 description coverage is 100%, so the baseline is 3. The tool description adds minimal parameter-specific meaning beyond the schema; it only briefly references the dryRun argument ('DEFAULTS TO A COST PREVIEW'), but the schema already provides a thorough explanation. The description clarifies how the output (not parameters) should be reused, which is useful but not directly about 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 clearly states what the tool does: 'Turns a rough game idea into { aiVision, aiPromptGuidance, aiNegativeGuidance }' — a specific verb and resource. It differentiates from siblings like create_project by emphasizing it produces reusable prompt guidance, and from async tools by noting it is synchronous with no jobId. The title 'Generate a project creative brief' aligns with the description.

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: it tells the agent to 'feed the wording into create_project (description/style) and into your own prompts', directing when to use this tool as a precursor to project creation. It also instructs on the dryRun workflow: 'DEFAULTS TO A COST PREVIEW — see the dryRun argument', and clarifies that results come back synchronously, distinguishing it from sibling tools that require job polling.

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 goes far beyond the readOnlyHint annotation by exposing the unreliability of `grid.complete` and the meaning of `dimsAssumed`. It warns that the sheet can cut wrong while the job still reports done, and explains seamMetric as a gate for a paid call. This enriches the agent's understanding of the tool's 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 detailed, but every sentence provides operational insight for interpreting the asset object. It is front-loaded with purpose and then branches into variant-specific guidance. While long, it earns its place given the complexity of the output without a schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description compensates by enumerating the key output blocks (`grid`, `background`, `seamMetric`) and their interpretation. It covers texture, tileset, and background variants, giving the agent enough context to act on the result. This makes the description semantically complete for a tool of this complexity.

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 single parameter `assetId` is fully documented in the schema with 'Asset id or slug.' The description repeats this exactly but adds no new semantics. Since schema coverage is 100%, a score of 3 is appropriate as the 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 'One asset with its revision iterations and typed animation projection,' clearly identifying the tool as a fetch operation for a single asset with specific details. It distinguishes itself from siblings like get_project/get_character by focusing on asset-specific fields. The title 'Get asset' reinforces the verb+resource clarity.

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 concrete decision guidance, e.g., 'read seamMetric.pass to decide whether a cell needs the paid fix_asset_seams call at all.' It also tells the user to compare requested grid dims against returned grid dims, which clarifies when to rely on the output. No explicit exclusions are given, but the use case 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?

The description adds significant operational behavioral details beyond the annotations: presigned URLs expire in about 1 hour, requiring immediate download, and the payload is guaranteed to be a correct export. This is especially valuable because the annotations only declare read-only/idempotent/non-destructive, and the description enriches that with practical warning.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the exact output content. Every word earns its place: the first lists the payload structure, the second warns about URL expiry and guarantees correctness. No verbosity or 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?

The tool is simple (one parameter, no output schema). The description covers what the return value contains, the time-sensitive nature of the URLs, and why the payload can be trusted. This is sufficient for an agent to invoke it correctly without additional context.

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 already fully describes the single parameter characterId as 'Character id.' with 100% coverage, so the baseline is 3. The description does not add additional parameter-level semantics, but none are necessary for such a simple, well-schemaed parameter.

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 explicitly states what the tool returns: 'The full PhaserCharacter JSON: animations, frameSize, gameType, per-group atlas + spritesheet URLs, poses and mount points.' It also distinguishes it from siblings like get_character_manifest by noting it provides the full payload the game preview consumes, making its purpose and scope clear.

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 implies usage for retrieving a complete export ('the same payload the in-app game preview consumes'), but it does not explicitly mention alternatives such as get_character_manifest or list_characters, nor does it state when not to use this tool. The context is clear but lacks direct comparison with sibling tools.

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?

Annotations already convey readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context by explaining what the tool returns (manifest + schema) and what it does not do (download the zip), going beyond the annotation baseline.

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 two concise sentences. The first sentence immediately states the core purpose, and the second provides usage context. No unnecessary words 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 a tool with one parameter and strong annotations, the description is nearly complete. It explains the return value concept and use case. It lacks a bit of detail about the structure of the manifest, but that is not essential given the tool's simplicity.

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 fully describes the single parameter ('Character id.') with 100% coverage. The description does not add additional meaning to the parameter, so the baseline score of 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 clearly states the tool's function: retrieving the self-describing export contract (tizo-export.json manifest + JSON Schema) without downloading the zip. This specific verb-resource pairing distinguishes it from siblings like get_export_command and get_character.

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 it: 'before wiring an export into a game project' to learn file inventory and field meanings. It also implies when not to use it (when you need the zip), but doesn't name an alternative tool, which would make it 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?

Annotations already declare readOnly and idempotent, but the description adds substantial context: it explains 402/403 error URLs (topUpUrl, capSettingsUrl), forbids quoting prices, discourages retries, and explains why the cap cannot be raised via API. This enriches the agent's understanding of constraints without contradicting the annotations.

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-loaded with the essential purpose. While it includes a verbose example and a philosophical explanation, each sentence serves to prevent misuse (e.g., don't quote prices, don't retry, don't ask for credentials). It could be trimmed, but it remains structured around critical usage rules.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates with detailed error-handling advice and explains what data is available (balance, ledger entries, apiKeyId/apiKeyName, resetsAt context). It doesn't exhaustively enumerate response fields, but for a read-only balance tool with strong annotations, it provides enough context to call and interpret results.

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 covers 100% of parameters with detailed descriptions, so the baseline is 3. The description adds a small amount of context by noting ledger entries carry apiKeyId/apiKeyName, but it does not enrich the meaning of limit or includeLedger 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 'Current credit balance, and optionally the recent ledger,' clearly identifying the resource and operation. It distinguishes itself from sibling tools by being the only credit-related endpoint, with an implied 'get' verb that matches the title.

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 instructs to 'Check the balance before proposing any paid generation,' providing a concrete trigger for usage. It also differentiates between balance shortages (402) and daily spend cap trips (403), giving opposite remedies and advising to never suggest purchases for cap issues—clear when/when-not 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that definitions are read-only and that values are on get_map, which is useful behavioral context. However, beyond this definitions-vs-values distinction, it does not disclose much additional behavior not already covered by annotations.

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 three sentences, all informative: what it returns, where values live, and how definitions are edited. No filler or redundancy, perfectly 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?

The tool is simple with two parameters, so the description covers the essential context (definitions vs. values, builtins, dashboard editing). Since there is no output schema, it could be more explicit about the response structure, but the high-level description is sufficient for this low-complexity tool.

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 both parameters have descriptions. The description adds that kind selects 'character or asset' which aligns with the schema enum, but does not significantly deepen understanding beyond the schema. 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 clearly states it returns typed custom-field definitions for characters or assets, which is a specific verb+resource. It also distinguishes itself from siblings like get_map (which carries per-placement values) and get_character/get_asset (which likely return the full entity).

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 contrasts with get_map and mentions that definitions are edited in the dashboard. This gives clear when-to-use guidance and exclusions, though it does not explicitly say 'use this when you need definitions', but it's strongly implied.

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?

Despite annotations already indicating a read-only, idempotent, non-destructive operation, the description adds valuable behavioral context: requires SPRITESHIP_API_KEY in the shell, zips are large binaries that must not pass through the model, and the URL is authenticated. This goes beyond the annotations and helps the agent understand security and execution constraints.

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 three sentences, front-loaded with the core action, then usage and requirements. No wasted words; each 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 a tool that generates a command, the description fully explains what it returns (URL + curl line) and the necessary runtime context. Combined with rich schema and annotations, this is complete enough for an agent to select and invoke 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?

The schema already covers 100% of parameters with clear descriptions and enums. The description adds minimal extra meaning beyond the schema, only reinforcing that size is for characters and engine includes 'tiled' maps-only. Baseline 3 is appropriate given high schema coverage.

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: to build an authenticated download URL and a ready-to-run curl line for zip exports. It specifies the resource types (character engine bundle, asset bundle, map bundle) and the verb 'Build', making it distinct from sibling tools like export_map.

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 usage instructions: run the curl in your own shell, avoid passing multi-MB binaries through the model, and set SPRITESHIP_API_KEY. However, it does not explicitly contrast this tool with alternatives or state when not to use it, so it stops short of 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?

Annotations already declare readOnly/openWorld/idempotent, so the description doesn't need to rehash safety. It adds valuable behavioral detail: output is presigned (URLs) and never inline base64, and the sheet is index-labeled. This goes beyond the structured annotations and helps set expectations about the response format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core output type, and each clause earns its place. The contrast between inline base64 and presigned URLs is a critical constraint stated in a single phrase, and the sheet usage guidance is concise but complete.

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 7 parameters and no output schema, the description covers the key behavioral aspects: output format, presigned URLs, sheet semantics, and integration with select_frames. The schema handles parameter details, so the description doesn't need to enumerate every field. It lacks some detail on how indices and size interact, but this is adequately covered by the schema. Overall, sufficiently complete for the tool's complexity.

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 all parameters thoroughly. The description adds meaningful context around the format parameter (explaining the sheet's purpose) and the output nature (presigned), but doesn't materially enhance the understanding of other parameters 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 clearly states the tool's function: returning presigned per-frame thumbnails for character animations or asset motion pairs. It distinguishes itself from sibling tools by explicitly referencing select_frames as the intended downstream action, making its role in the workflow 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?

Provides explicit usage guidance: warns against inline base64, recommends format:"sheet" for judging whole captures, and names select_frames as the next step. This clarifies when to use this tool and how to choose between thumbnails and contact sheet, effectively covering both when and how.

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?

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds substantial behavioral context beyond these: it specifies that error responses include creditsRefunded and retryCost, that queued:true means not started and spent nothing, and that terminal statuses include a credits block with detailed fields. It also explains the difference between a 2x2 grid being one charge and failed steps being refunded, which is critical operational knowledge. No contradiction with annotations.

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 and dense, but every section serves a purpose: polling cadence, response enrichment, entity lists, credits block, and user communication. It starts with the core action and then layers critical details. While it could be better organized with headings, it front-loads the essential purpose and prioritizes operational details. Slightly verbose but justified.

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, the description bears full responsibility for explaining return values. It covers job statuses (queued, done, error), the enriched error response, produced entities (characterIds/assetIds, characterPreviews), and the credits block structure. It also instructs the agent on what to report to the user (credits.net and balance) and when not to suggest purchases. This is comprehensive for a polling tool with complex response semantics.

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 has one required parameter, jobId, with 100% description coverage ('Job id.'). The parameter is self-explanatory. The description adds context that the jobId comes from write tools returning a jobId, and that this tool polls that job. This goes slightly beyond the schema, so a score of 4 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: 'Poll a background job.' It clearly distinguishes this tool from siblings by stating that every write tool returning a jobId is polled here, and it explains that this is how you learn what a create call made (characterIds/assetIds). This unambiguously identifies the tool's purpose and scope.

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 guidance on when and how to use the tool: 'Poll every few seconds — generations routinely take minutes.' It also explains when not to attach purchase suggestions and how to handle terminal statuses. It effectively tells the agent when this tool is appropriate versus alternatives like retry_job or cancel_job.

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?

Annotations already mark the tool as readOnly and idempotent; the description adds meaningful behavioral context beyond that, including the exact saved data components and the mapData:null return for unsaved maps. This goes beyond the safety profile provided by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two crisp sentences: the first states the return payload, the second covers the unsaved edge case. No filler or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter get operation, the description adequately covers the return structure and the null case. It could have mentioned how to list available maps or error conditions, but those are minor given the simple schema and strong annotations.

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% and the mapId parameter is self-explanatory as 'Map id.' The description adds no additional parameter semantics, so the baseline score of 3 applies.

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?

Description clearly identifies the tool as retrieving a map row with its saved level data, listing specific components (layers, placements, per-placement custom-field values). It distinguishes itself from sibling lookup tools like get_character or get_asset by specifying the map-specific payload and the mapData:null edge case.

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?

No guidance is given on when to use get_map versus list_maps or other get_* tools. The description explains what the tool returns but not in which workflow it should be invoked.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds context about the response content (description and mount slots) but does not disclose error behavior, permissions, or pagination. This adds some value but is not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly states the output. No redundant or filler words; it 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 simple one-parameter getter with persistent annotations and no output schema, the description adequately communicates the return value (one project with description and mount slots). It is complete enough, though a brief note on error behavior could make it fully comprehensive.

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 the parameter with a description 'Project id.' The tool description does not add extra meaning about the parameter, such as how to obtain the ID or any format constraints. Baseline is 3 due to high schema coverage.

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 identifies the resource (project) and the scope (one project, specifically its description and registered mount slots). This distinguishes it from sibling getters like get_asset and list_projects, which serve different resources or plural collections.

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 usage is implied: use this to fetch a single project's details. However, there is no explicit guidance on when to choose this over list_projects or other getters, nor any exclusions or prerequisites mentioned.

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?

Annotations already declare read-only, idempotent, and non-destructive behavior, so the description's main contribution is the non-obvious trait that hasAnimation is data-derived and can appear on any asset type. This warns against a common faulty assumption, adding valuable context beyond the annotations.

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 two short sentences with no filler or repetition. It front-loads the resource and scope in the first sentence, then delivers a critical caveat in the second. Every word 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 simple listing tool with no output schema and well-documented parameters, the description covers the expected fields and a key behavioral warning. It does not mention pagination or default limits, but those are already in the schema, so the description is sufficiently complete for this complexity level.

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 provides 100% coverage for all five parameters, so the baseline is 3. The description does not add parameter-level details or relationships, but it is not required to since the schema already explains each 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 names the resource (assets) and enumerates the asset types it covers, along with the fields returned. However, the verb 'list' only appears in the tool name/title, not in the description itself, making it a noun phrase without an explicit action. It is still clear that this returns multiple assets and distinguishes from get_asset.

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 includes a useful data-interpretation warning (never infer hasAnimation from type), which gives indirect guidance on how to treat results. It does not explicitly state when to use this tool versus alternatives like get_asset or other list tools, and it lacks any exclusions or prerequisites.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety traits are covered. The description adds valuable operational context beyond the annotations: the status enum (pending|done|error), the fact that it is the polling mechanism (no job id), and the behavioral heuristic that a long-pending pose means stalled rather than in-progress. This enriches the agent's understanding of how to interpret results, though it stops short of documenting error codes or pagination 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?

Three sentences, each earning its place: the first front-loads the purpose and return shape, the second explains the polling use case, and the third provides an interpretation heuristic. There is zero redundancy or filler — the description is appropriately sized and well-structured.

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 1-parameter, read-only, idempotent list tool with no output schema, the description is complete: it provides the return-field list (compensating for the missing output schema), states when to use it (poll after generate_pose), and explains how to interpret pending states. Rich annotations cover the safety profile, so no further behavioral detail is needed.

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% — the single required parameter characterId is already described as 'Character id.' The description's phrase 'All poses on a character' reinforces that characterId selects the character, but adds no format, source, or syntax details beyond the schema. With full schema coverage, 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 'All poses on a character' — a specific verb+resource statement that clearly identifies the tool as listing the poses belonging to a single character, with an explicit field list ({ id, name, prompt, status, url, pendingSince, errorCode, creditsRefunded }). It distinguishes itself from siblings like generate_pose and get_job by positioning itself as the dedicated poll target for pose generation.

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 states exactly when to use it: 'This is the poll target after generate_pose — pose generation has no job id.' This explicitly tells the agent to poll this tool instead of job-based alternatives after generating a pose, and explains why get_job is not applicable. It also provides a stall-detection heuristic (pending long after pendingSince means stalled, not working), guiding follow-up 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context about contentVersion being an opaque change token that must not be parsed or ordered, plus a caching strategy. This goes beyond the annotations and enriches the agent's understanding of the tool's contract.

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 two tight sentences: the first lists the returned re-sync signals, the second states the persistence strategy. No filler or repetition. Every phrase carries meaning, and the most important info (contentVersion handling) is front-loaded. This is an example of efficient, high-signal writing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description bears responsibility for explaining return values, and it does: contentVersion, hasActiveJob, apiReady, pose/animation counts, tags, favourite. It also provides the important re-fetch strategy. It doesn't explicitly state that the result is a list or cover pagination, but the limit parameter handles that. Overall, it is complete for a read-only list tool with good annotations.

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 covers 100% of parameters with descriptions (name substring filter, limit with default/max, projectId restrict). The description adds no parameter-specific detail beyond what the schema provides, so the baseline of 3 applies. It does not mention parameters at all, but the schema is fully sufficient.

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 focuses on the re-sync signals returned for characters, which clearly implies this lists characters. The tool name and title explicitly say 'List characters', and the description distinguishes it from singular get_character by emphasizing the list with change tokens. However, the description lacks an explicit verb like 'lists' or 'returns', relying on context.

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 a clear usage pattern: 'Persist contentVersion per character and re-fetch only when it changes.' This tells the agent when to call the tool and how to use it efficiently. It does not explicitly mention alternatives like get_character for single-character retrieval, but the polling guidance is strong. There's no 'when not to use' exclusion, but the context 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations by explaining the meaning of hasMapData:false (never saved, cannot be exported) and that maps include updatedAt, which helps an agent interpret the returned data. No contradictions.

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 very short: two sentences with no unnecessary words. However, it starts awkwardly as a noun phrase rather than a verb phrase, which slightly reduces clarity. Still, it avoids fluff and front-loads the key fact that this is about maps.

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 tool's simplicity (2 optional params, no output schema), the description is reasonably complete but lacks an explicit statement that this tool returns a list/collection of maps. It does mention relevant response fields (updatedAt, hasMapData), but doesn't describe pagination or default behavior beyond what the parameter schema covers. The warning about hasMapData:false adds value but doesn't fully compensate for the missing 'list' framing.

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% and both parameters (limit, projectId) have descriptions in the schema. The tool description adds no parameter-specific information, so it doesn't improve on the schema. Thus, 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 is a noun phrase describing map properties ('Level-editor maps with updatedAt and hasMapData') rather than stating the action of listing maps. It doesn't use a verb like 'list' or 'retrieve', and while the title provides that, the description itself is vague about purpose. It also doesn't explicitly distinguish from siblings like get_map or export_map.

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?

No guidance is provided on when to use this tool vs alternatives. There's no mention of scrolling through maps, filtering, or that get_map might be more appropriate for a single map. The hasMapData note is about data semantics, not tool 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?

Annotations already declare readOnly, idempotent, and non-destructive hints, so the safety profile is covered. The description adds the important semantics of gameType affecting asset rendering, but it says 'All' projects while the limit parameter implies possible truncation, and it does not disclose pagination 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 two concise sentences: the first lists the returned resource and fields, the second explains gameType's significance. No waste, front-loaded, and well structured.

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 rich annotations, a simple one-parameter schema, and an explicit field list, the description is largely complete. The gameType instruction adds crucial context for generation. It lacks pagination detail, but the schema documents the limit behavior, so a 4 is appropriate.

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 only parameter, 'limit', is fully described in the schema with min, max, and default, so schema coverage is 100%. The description explains gameType but that is a return field, not a parameter. Baseline 3 applies.

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 lists the user's projects and enumerates the returned fields, making the resource and scope explicit. However, it does not explicitly distinguish this from the closely related get_project tool, so it falls short of a 5.

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 instructs to read the project's gameType before generating anything, providing a clear workflow context. It does not explicitly state when not to use this tool or name alternatives, but the guidance is specific 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?

Beyond the annotations (which already indicate non-idempotent and non-read-only), the description adds critical behavioral details: the flip is applied in-place, calling twice reverts the animation, frame count/order are preserved, and the return shape is { jobId, mirrored }. It also mentions cost ('FREE, no AI'), which is useful context not in annotations.

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 critical info ('FREE, no AI'), then explains the action, the idempotency gotcha, the frame preservation, the alternative, and the return value. Every sentence earns its place; nothing is wasted or redundant.

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 absence of an output schema, the description explicitly states the return object and polling mechanism. It also covers the non-idempotency hazard and the workflow for keeping both directions. This makes the tool fully understood without needing extra documentation.

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 already documents both parameters with clear descriptions (animation slug, character id) at 100% coverage. The description adds context about the effect on the animation (in-place, frame preservation) but does not introduce new parameter-level semantics beyond the schema, so the baseline of 3 applies.

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 ('flip every cached frame') and names the resource ('ONE animation'), clearly distinguishing it from siblings like duplicate_animation. It also gives a concrete use case ('get walk_left from walk_right'), making the tool's purpose immediately obvious.

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 warns about non-idempotency ('call it once and check the result before calling again') and provides an alternative for preserving both directions ('call duplicate_animation first and mirror the copy'). This is direct 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?

Beyond annotations (readOnlyHint=false, openWorldHint=true, etc.), the description discloses key behaviors: it is free and no-AI, cannot change what the character looks like, always rebuilds ALL animations, normalizes heights across animations, and returns a jobId. This adds substantial context about side effects and operational characteristics.

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?

Every sentence earns its place: the opening flags 'FREE, no AI,' then the core action, use cases, boundary conditions, and the return value. It is front-loaded and structured logically without fluff, maximizing information density.

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 tool's complexity (rebuild affects all animations, returns a jobId), the description covers what it does, when to use it, what it doesn't do, why rebuilding a subset is harmful, and the async nature. No output schema is present, but the description explicitly mentions the jobId return, making it 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 already covers the only parameter (characterId) with a description ('Character id.'), so schema coverage is 100%. The tool description adds no new detail about the parameter itself, but notes 'Takes no options' which reinforces the schema's additionalProperties: false. 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 clearly states a specific verb+resource+scope: 'Re-render every spritesheet, atlas and export of a character from its durable cached frames.' It also labels itself as 'the repair/refresh tool,' which distinguishes it from sibling tools like reprocess_asset or regen_asset_pair. The purpose is 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?

Explicitly states when to use: 'use it when a sheet looks stale or wrong after a series of edits, or when a previous rebuild failed.' It also clarifies what it does not do ('never re-generates art') and warns against rebuilding a subset due to cross-animation normalization. This provides clear guidance vs 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 discloses important behavioral traits beyond annotations: the cost (~400 credits), the default to a cost preview via dryRun, that earlier takes are preserved (non-destructive), and that it returns a jobId to poll. This adds significant context beyond the readOnlyHint/idempotentHint/destructiveHint annotations and aligns with them (no contradiction).

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 three sentences, starts with the critical cost warning, and packs in scope, preservation, default behavior, and return type without redundancy. 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?

Given the tool has no output schema and seven parameters, the description covers the essential context: what it does, its non-destructive nature, cost, dryRun flow, and return value. Param details are in the schema, so the description is complete enough for an agent to select and 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?

Input schema coverage is 100%, so each parameter is described. The description reinforces the dryRun default and idempotencyKey behavior but does not add substantial meaning beyond the schema's own parameter descriptions. Baseline 3 is appropriate because the schema already carries the burden.

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 re-runs video generation for a single motion pair of an animated asset, explicitly distinguishing it from regenerating all pairs. The verb 'Re-run' plus the resource 'motion pair' and the scope 'leaving its other pairs alone' make the purpose unambiguous and differentiate it from sibling tools like revise_asset or reprocess_asset.

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 conveys when to use this tool by focusing on a single pair and preserving other pairs, but it does not explicitly name alternative tools or provide exclusion criteria. It does give clear context, including the cost preview default and that earlier takes are preserved, which implies when this is appropriate.

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?

Beyond annotations, the description discloses that the operation is synchronous, free, and does not involve AI. It explains the effect of omitted fields (keeps current values), how to clear them (send [] or 0), and that it returns a grid summary and recommends calling get_asset for fresh URLs. This complements the annotations without contradiction.

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: it front-loads critical constraints (FREE, SYNCHRONOUS), explains the core function, details parameter behaviors, and ends with return value and next steps. No filler or redundant content.

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 mentions it returns a grid summary and instructs to call get_asset for fresh URLs. It covers the full workflow, constraints on asset types, and parameter behavior, making it complete for an agent to invoke correctly without additional context.

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 all parameters with descriptions (100% coverage), including clearing behaviors for cellOffsets and cellInset. The description adds the cross-cutting rule that omitted fields retain their current values, which is not present in the schema. This enhances parameter understanding beyond the structured fields.

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: re-run the grid split on a tileset or staged asset revision. It specifies the resource (grid asset) and purpose (change cut without regenerating), and explicitly distinguishes from siblings like revise_asset for terrain. The verb 'Re-run the grid split' is specific and actionable.

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?

Provides explicit when-to-use and when-not-to-use: 'tileset and staged ONLY — other types have no grid, and terrain has no re-cut path at all (it is alpha-split from one sheet; iterate it with revise_asset instead).' Also notes synchronous behavior and that no jobId is returned, so polling is unnecessary. This is clear usage 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?

The description goes far beyond the annotations by disclosing the paid nature (only for sub-steps that still need to run), reuse of already-paid successful work, dryRun default cost preview, non-retryable phase errors, and return shape ({ jobId }). These are critical execution semantics that the readOnlyHint=false and idempotentHint=false annotations only hint at.

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 paragraph but every sentence carries important information about cost, retryability, and the dryRun default. It is front-loaded with the 'PAID' warning and avoids fluff, though it could be slightly tighter without losing value.

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 tool's complexity (paid, dryRun, idempotency, retryable phases) and the absence of an output schema, the description thoroughly covers the return value ({ jobId }), error cases (400), the cost preview flow, and the prerequisite of an errored job. It gives the agent everything needed to invoke the tool correctly and safely.

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 fully documents all 3 parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaningful cross-references: the dryRun quote is the same as get_job's retryCost, and reusing the same idempotencyKey on transient failures prevents double dispatch. These insights go beyond the schema's parameter 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 clearly states it re-runs the failed step of an errored job, positioning it as the cheaper alternative to recreating the job from scratch. This specific verb+resource+condition distinguishes it from sibling tools like create_* and get_job.

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 frames when to use this tool: as the cheap way out of a failure instead of recreating everything, and notes that non-retryable phases return 400 JOB_NOT_RETRYABLE. The dryRun workflow (get cost quote, get explicit approval, then re-call with dryRun:false) provides clear step-by-step usage guidance. It doesn't explicitly name alternatives like cancel_job, but the context is sufficient.

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 several behavioral traits beyond the annotations: it is a paid operation, defaults to a cost preview via dryRun, is additive and never destructive, and returns a jobId for polling. This significantly enriches the annotation hints (readOnly=false, destructive=false) without contradiction.

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 concise (four sentences) and front-loads the critical 'PAID' warning and primary purpose. Every sentence adds value, such as the additive nature, terrain templateId, dryRun default, and return type, with no wasted words.

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 tool with 8 parameters and no output schema, the description covers the key context: payment, default dryRun behavior, terrain category packs, and return value. It does not mention idempotency or other parameters, but these are fully described in the schema. Overall, it is sufficiently complete for an agent to understand the tool's main workflow.

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 parameters are fully documented there. The main description adds minimal new semantic value by highlighting dryRun's default and terrain templateId usage, but these are already present in the schema. Thus, the description does not substantially compensate beyond the schema's 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 the tool's purpose: 'Generate a new revision of an asset from feedback text.' It specifies the resource (asset) and verb (revise), and distinguishes itself from siblings by emphasizing that revisions are additive and non-destructive, while also noting terrain-specific templateId usage.

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 (when revising an asset from feedback) and mentions terrain-specific usage for templateId. However, it does not explicitly name alternatives or state when not to use this tool in favor of siblings like create_asset or reprocess_asset, so it misses the full 'when-not' 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?

Beyond annotations (which only indicate non-read-only, non-destructive, open-world), the description adds valuable behavioral detail: the full capture is retained (non-destructive), re-selection is possible, empty array resets, and it returns a jobId requiring polling via get_job. This gives the agent a clear mental model of the tool's 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 five concise sentences, each providing distinct value: cost/aspect, core purpose, reset behavior, non-destructive guarantee, prerequisite workflow, and async pattern. It is front-loaded with the most critical information and contains no 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?

Despite having 6 parameters and no output schema, the description covers the essential workflow (get_frames first), the async job pattern, reset behavior, and non-destructive nature. The target variations are handled by the schema, so the description is complete enough for an agent to invoke 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 description coverage is 100%, and the schema already documents the key param semantics (ordered frames, empty array reset, target types, etc.). The tool description repeats some of this but adds no new meaning beyond the schema, so the baseline of 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 uses a specific verb ('Curate') with a clear resource ('which frames an animation keeps'), and specifies the mechanism ('by index into the full capture, in order'). This clearly distinguishes it from sibling tools like frame_animation, which likely deals with creating/editing animation frames rather than selecting subsets.

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 context: 'Use get_frames with format:"sheet" first to choose indices' and explains the reset behavior via empty array. It also notes the non-destructive nature enabling re-selection. However, it does not explicitly name alternative tools or state when NOT to use this tool, so it falls just short of 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?

Description adds significant behavioral detail beyond annotations: 'FREE and SYNCHRONOUS (no jobId — do not poll)' and 'flow into every engine export made AFTER this edit.' This enriches the annotation-provided readOnly/destructive hints, giving the agent practical knowledge about execution cost, timing, and side effects.

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 three sentences, front-loaded with the most critical operational facts (FREE, SYNCHRONOUS), then lists intent values, explains effect timing, and ends with tile-specific targeting. Every sentence adds distinct value with no 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?

The tool has 5 parameters and no output schema, but the description covers purpose, sync behavior, effect on exports, and tile targeting. It does not mention return values or verify prerequisites, but for a synchronous setter this is acceptable. Slightly more detail on expected response could be added.

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 adds marginal value by mentioning tileIndex targeting and that plain_image clears previous intent, but these are already covered in the schema property descriptions. No new parameter meaning is introduced.

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 function: 'Declare how an asset revision should be rendered at runtime' with a specific verb and resource. It also enumerates all valid runtime intent values, making it distinct from sibling tools like animate_asset or reprocess_asset.

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 use: it is free, synchronous, and applies to future engine exports. It does not explicitly exclude alternatives, but the purpose is specific enough to guide selection. No when-not-to-use guidance is given, but the context 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?

The description goes beyond annotations by disclosing cost ('PAID but very cheap'), synchronous behavior, return shape ('{ hint, cost } inline, no jobId'), dryRun semantics (returns a cost quote and executes nothing until dryRun:false), and idempotency key guidance. It also warns about 400 errors for non-staged assets. No contradiction with annotations.

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, front-loaded with key facts (paid, synchronous, returns inline), then function, usage, and limitation. Every sentence adds value without redundancy or 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?

The tool has moderate complexity (4 params, no output schema), but the description covers return values for both dryRun and real calls, execution model (synchronous, no jobId), cost protection rationale, idempotency handling, and asset type restriction. This is fully adequate for an agent to select and invoke the tool safely.

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?

Despite 100% schema coverage, the description enriches every parameter: explains 'pairs' as context only ('nothing is generated from them'), details dryRun's default true behavior and the required two-step consent flow, clarifies assetId is a staged asset id or slug, and gives idempotencyKey reuse instructions for retries. This goes well 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 clearly identifies the tool as 'Suggest a motion hint for a staged asset' and explains its function: it reads a staged asset's prompt and stage pairs, then writes a one-sentence motion description to be passed as animate_asset's motionHint. This distinguishes it from siblings by focusing on hint generation rather than animation or asset creation.

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: 'Use it when you are about to spend ~400 credits on video and are unsure what to write.' It also gives a clear when-not: 'Staged assets only — any other type answers 400.' The relationship to animate_asset is stated, making the intended workflow 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?

Annotations already declare the tool as read-only, idempotent, open-world, and non-destructive. The description adds valuable context beyond that by explaining that it verifies the API key and that the scopes array indicates permissions. This complements the annotations without contradicting them.

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 two sentences, front-loaded with the main action, and every word adds value. It efficiently communicates purpose, return value, and usage guidance 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?

Given the simplicity of the tool, the description fully covers what it does, what it returns, and when to use it. The explicit return object listing removes the need for an output schema, making the description complete within its context.

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 tool has zero parameters, and the schema description coverage is 100%, so the description does not need to explain any parameters. The baseline of 4 is appropriate since there is nothing to add.

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 verifies the API key and reports its powers, using a specific verb and resource. It also lists the exact return fields (userId, username, keyId, keyName, scopes), making its purpose unmistakable and distinct from any sibling 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?

The description explicitly tells the agent when to call this tool first, specifically after a scope error, and explains how to use the returned scopes array to understand permissions. This is clear, actionable guidance with no ambiguity.

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