spriteship

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

With only basic annotations (readOnlyHint=false, idempotentHint=false), the description carries the full burden and excels: it discloses cost scaling, the dryRun default, recovery and fallback behavior, retry limits, and the requirement for user approval. No contradiction with annotations; it adds substantial behavioral context beyond what annotations provide.

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

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

The description is long but dense, front-loading the most critical cost and usage information. Each sentence adds operational value (approval flow, error handling, retry policy). It could be slightly trimmed, but the length is justified by the tool's complexity (9 params, cost implications, user interaction).

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, the description covers all essential operational aspects: cost, approval flow, grid vs single-image handling, error recovery, retry limits, default behavior, and return format. It even anticipates potential mistakes (defaulting pairs) and explains server-side safeguards. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100% and the schema already includes detailed parameter descriptions, the tool description adds extra meaning: it explains cost per second, the self-loop pair pattern, idempotency key reuse for retries, and the dryRun quote structure. This goes beyond the schema's basic parameter definitions.

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 animates any asset type, with specific behavior for grid vs single-image assets, and distinguishes it from siblings by emphasizing its universal applicability. It also clarifies the output (returns {jobId}) and the cost model, leaving no ambiguity about the core 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?

Provides extensive usage context: when to use grid pairs vs closeLoop, the mandatory pre-approval flow (asking user which stages), the cost preview default, and error handling guidance. It does not explicitly name alternative tools but gives clear situational instructions, so it's a 4 rather than 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 only indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds critical behavioral context beyond these: both choices resume the original animation request at normal video cost, accepted generated poses are reused without another review, and imported generation preserves source rendering. 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 longer than typical but the length is justified by the branching logic. It front-loads some contextual background before the direct 'Use this tool only when...' instruction, which slightly delays the core routing guidance, but every sentence contributes useful decision-making information.

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

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

Given no output schema and three parameters with conditional semantics, the description is remarkably complete. It covers both possible states (poseReview present vs absent), the exact user interaction required, how to submit the choice, when to cancel instead, and the downstream consequences of approval.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description enriches parameter meaning substantially. It explains exactly when choice='generated' is acceptable ('only after they accept that exact pose'), that choice='original' is used for technical failure continuation, and that poseVersion must be the exact poseReview.version shown to and approved by the user.

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: approve an automatic pose fallback decision. It also specifies the exact trigger condition ('Use this tool only when get_job returns a pending automaticPoseFallback'), which distinguishes it from sibling tools like approve_directional_poses and cancel_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?

The description provides explicit usage guidance: when to call the tool, how to branch on the presence of poseReview, which choice to submit in each scenario, and when to use cancel_job instead. It also warns 'Never approve automatically,' making the human-in-the-loop requirement unambiguous.

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 key behavioral traits beyond annotations: it is free, calling it resumes paid dependent animations, and the server rechecks the live credit balance immediately before resuming. It also explains that declining leaves the job paused and no dependent animation credits are spent. This adds substantial context about side effects and safety, complementing the annotations (readOnlyHint=false, openWorldHint=true).

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

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

The description is dense and long, but every sentence carries a specific, actionable rule. It is front-loaded with the usage condition, followed by process, conditional rules, and negative consequences. Some sentences could be tightened or structured into bullet points, but there is no fluff; the length is justified by the complexity of the tool.

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

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

For a tool with no output schema and complex conditional behavior, the description covers all essential aspects: when to use, how to present previews, how to handle unreviewed candidates, special handling for directions present/absent, and consequences of not calling the tool. The server-side credit recheck is also disclosed, making the agent fully informed to call 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?

Although the schema has 100% coverage with descriptions for all parameters and nested object properties, the description enriches semantics with critical operational instructions: use unique indices 0–3, keep scale 100, preserve unused map entries, and let the user adjust or review the proposed frameIndices and poseScales. These are not apparent from the schema alone and are essential for correct parameter values.

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 a 'FREE approval checkpoint' for directional poses in a job workflow, with the explicit purpose of submitting approved frameIndices and poseScales. It distinguishes itself from siblings by stating precise conditions under which it applies (status 'waiting_approval', wizardPhase 'waiting-directional-pose-approval', directionalPoseReview). The action is specific: present previewUrls, let the user adjust/review, and submit the maps.

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 conditions: 'Use only when get_job returns status...' and states the negative case: 'Closing or declining means do not call this tool'. It also distinguishes between when directions is present (four poses) versus absent (eight poses), giving clear routing guidance. This leaves no ambiguity about when to invoke the 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 goes beyond the annotations by explaining important side effects: failed/incomplete provider work is refunded automatically, and for waiting-for-approval jobs, reusable 360 and pose charges are retained. This is genuinely useful behavioral context that annotations like destructiveHint:false do not capture. No contradiction between the description and annotations is present.

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 and front-loaded, beginning with the essence 'Abort a running job.' Every sentence adds information: cost, refund rules, approval-specific behavior, and usage guidance. There is no fluff 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 single-parameter tool with no output schema and existing annotations, the description provides all needed context: the core action, the specific cancellation timing, refund behavior, charge retention specific cases, and a usage recommendation. An agent can invoke this tool correctly without further information.

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 provides a clear description for jobId ('Job id to cancel.'), and coverage is 100%. The description adds no extra semantic meaning for the parameter beyond the basic one, 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?

The description states the verb 'Abort' and the resource 'a running job', making the tool's purpose explicit. The wording distinguishes it from siblings like get_job or retry_job, since those do not abort a running generation. The phrase 'FREE' also adds a useful top-level qualifier.

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 a clear when-to-use condition: 'Use this when a generation is clearly going wrong rather than letting it run to completion.' This is explicit context, but it does not name a specific alternative tool such as retry_job, nor does it state when cancellation would be the wrong choice. That prevents a full score of 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?

Discloses free/synchronous/no-AI execution, immutability, revision preservation, projection-dependent quality outcomes, and return behavior. Annotations only carry readOnlyHint, destructiveHint, and idempotentHint, so the description adds substantial behavioral context beyond what annotations already provide. No contradiction 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?

Dense but not bloated; every sentence adds a distinct fact: cost/performance, immutability, projection behavior, conversion constraints, and follow-up step. The core operation 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?

Covers prerequisites (seam check, strip-only prohibition), outcome states (ready/needs-review), mutation semantics (preserves original), and the follow-up call to get_asset. Since there is no output schema, the explicit mention of return values closes the main remaining gap.

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 all three parameters are already documented. The description adds value by tying the projection enum values to concrete outcomes (topdown/isometric vs platformer) and explaining texture-type eligibility limits, which goes 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?

States a specific action: copies a legacy repeat-xy texture into a new immutable Brushable Material revision while preserving the original. This clearly distinguishes the tool from sibling asset-processing tools by naming the exact transformation and output.

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 applicability rules: topdown/isometric conversions are ready immediately if seam check passed, platformer conversions are marked needs-review, and strip-only textures cannot be converted. It gives clear when-to-use and when-not-to-use conditions, though it does not explicitly name an alternative sibling tool.

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

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

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?

Annotations only say readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the description carries the behavioral burden and does so extensively: the dry-run default, planToken invalidation rules, credit cost tiers, automatic background removal and fallback, terrain's lack of per-tile edit path, and the fact that atlases are cut by logical foreground objects rather than row geometry. This goes well beyond annotation coverage. It loses a point for not addressing rate limits or idempotency retry nuances beyond the schema's idempotencyKey note.

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 extraordinarily long — several hundred words — and heavily redundant with the input schema. The assetType enum's schema description already explains each type, yet the prose re-explains each in detail. Multiple behaviors (no grid-filler, no automatic animation, camera conventions) are restated across different type sections. The critical dry-run/plan-token flow is front-loaded, which is good, but the sheer volume of repetition means many sentences fail to earn their 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 complex tool with 22 parameters, 6 asset types, and a two-phase dry-run/confirm flow, the description is remarkably complete. It specifies the return shape ({ jobId, assetId }), the polling handoff (poll get_job, then get_asset), the preview requirement, extraction warnings on get_asset, credit quoting, and per-type default behaviors. Despite no output schema, an agent has everything needed to drive the full lifecycle correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful interplay context beyond the schema: dryRun defaults to true and returns only a quote, planToken is required when dryRun=false and must be copied unchanged, bgType is REQUIRED for background and mismatches get rejected with 400, assetType 'static' defaults to four design alternatives, and idempotencyKey should be reused when retrying ENTITY_BUSY/402/429. This enriches the structured field definitions rather than repeating them.

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

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

States a specific verb and resource — 'Creates a NEW asset from a prompt in any of the six types.' The opening line is clear about the core action and the asset-type taxonomy (static, tileset, staged, background, terrain, texture) distinguishes it from siblings like create_character, create_project, and create_ui_composition. It loses a point because the purpose is buried under a very long preamble about paid calls and dry runs before the type breakdown, and sibling differentiation is implicit rather than explicit.

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 substantial usage flow guidance: defaults to dry run, show the preview to the user, re-call with dryRun:false after approval, poll get_job then get_asset. It also tells the user to ask which layer they want when bgType is ambiguous. However, it never explicitly contrasts with alternatives like revise_asset or import_asset_image, nor states when NOT to use this tool versus those siblings — the when-to-use is implied by the workflow narrative, not stated as a routing decision.

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 only cover readOnlyHint/openWorldHint/idempotentHint/destructiveHint; the description adds substantial behavioral context beyond them: exact credit costs, text-free generation policy, image-only output, four-variation default extraction rules, refund on zero/one silhouettes, return shape { jobId, expectedCharacterCount }, polling expectations, and the dryRun cost-preview default. Nothing contradicts annotations, and it discloses side effects like spending and character persistence.

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 critical operational detail (costs, extraction rules, dryRun flow, animation separation). It is front-loaded with cost and purpose. Slight room to tighten redundancy around the four-variation mode, but no filler; the density is justified by 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?

For a 13-parameter tool with no output schema, the description covers all essential call aspects: prerequisites, cost/approval flow, output contract, polling, error/refund conditions, variation mechanics, and gameType's long-term effects. An agent has everything needed to decide, invoke, and interpret the result without supplemental 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?

Schema coverage is 100%, but the description enriches many parameters: dryRun's confirmation flow and re-call pattern, gameType's topdown/isometric alias and stored-value consequences, gridRows/gridCols as legacy silhouette triggers rather than geometry, generateFourVariations default behavior, referenceAssetUrls rejecting base64, and idempotencyKey retry safety. This goes well beyond the baseline and materially improves correct invocation.

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 'Generate a NEW character from a text prompt' and positions it as the entry point for building art from nothing. It distinguishes create_character from create_project (must come first), generate_character_animation, and generate_character_turn, making sibling differentiation 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 gives direct when-to and when-not-to guidance: call create_project first if no project exists, use separate animation tools only when the user explicitly wants animation because of cost, set generateFourVariations:false only on explicit user request, use topdown for isometric projects, and default to dryRun and ask for confirmation. These instructions remove ambiguity about routes and 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?

Adds substantial context beyond the annotations: it is FREE, synchronous (no jobId, so don't poll), and as a side effect seeds a starter level map for immediate preview rendering. Annotations cover safety flags but say nothing about cost, sync-vs-async behavior, or side effects, so this disclosure is genuinely additive. Minor gap: no mention of permissions or the shape of the created object.

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

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

Front-loads the two highest-value facts (FREE, SYNCHRONOUS/don't poll) before explaining purpose and the list_projects prerequisite. Four sentences, all earning their place, though slightly dense.

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 create tool with no output schema, annotations present, and full schema coverage, the description covers purpose, cost, sync behavior, side effects and a prerequisite. The only omission is what the call returns (e.g. a project id to use downstream), which is a modest gap.

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 name, style, gameType, styleGuide and description in detail. The description adds only the downstream consequence of gameType ('decides how they are drawn and animated'), which the schema also conveys. Baseline 3 is appropriate when structured data carries the parameter 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?

States a specific verb and resource ('Creates') and immediately characterizes the project as 'the container everything else needs', explaining its role relative to sibling create_asset/create_character. An agent can distinguish this from get_project/list_projects without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit operating instructions: 'Call list_projects first — reuse an existing project rather than making a near-duplicate' and 'do not poll'. It names the alternative tool and the condition under which to prefer it, leaving nothing to inference.

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

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

Annotations already declare non-read-only, non-idempotent, non-destructive, open-world behavior. The description adds genuine scope context, that this is a static composition with no image generation and that indicators/functional widgets stay independent, plus the cost signal "free." It omits permission/ownership requirements and what happens on repeat calls.

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?

A single dense sentence front-loads the operation and its key constraint. Efficient, though the semicolon-joined clauses make it slightly harder to parse than two short sentences would.

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 five-required-parameter creation tool with 20% schema coverage and no output schema, the description leaves major gaps: how children are laid out or ordered, whether overlaps are valid, ownership/permission prerequisites, and the consequences of composition. It states what the tool is not (image generation) better than what it requires.

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 only 20% (packId and componentId only; name, width, height, children, and bounds are undocumented). The description's "existing icon/frame revisions" lightly hints at what children reference, but it adds no meaning for the 8-item child limit, bounding rules, or dimension constraints.

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

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

States a specific verb and resource ("Create a free static composition") and constrains the input to "existing icon/frame revisions" with "No new image generation." That implicitly separates it from generative siblings such as generate_ui_pack, though no sibling is named outright.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: compose from existing revisions, and don't use this when new imagery is required. There is no explicit when-to-use/when-not framing and no named alternative (e.g., generate_ui_pack) to route an agent toward.

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 cover the safety profile (write, non-destructive, non-idempotent, open-world). The description adds useful behavioral context beyond annotations: the pack is empty, includes a guide snapshot, and the action is free while generation incurs a separate quoted cost. It does not cover authentication or rate limits, but that is less critical given 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?

Two short sentences, front-loaded with the core action and followed by the cost/scope clarification. No wasted words and the most important distinction (free creation vs. quoted generation) is 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?

For a simple two-parameter creation tool with annotations and no output schema, the description covers purpose, scope, and cost. The only missing piece is parameter-level guidance, but the schema supplies required fields and types, so the definition is largely sufficient for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain either parameter. 'Project-owned' weakly hints at projectId, but the 'name' parameter and its constraints are entirely undocumented in the description, so it fails to compensate for the schema gap.

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

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

The description states a specific verb (Create) and resource (UI Pack) and clarifies it is an empty pack with its guide snapshot. It also distinguishes this from generation by noting generation is a separate quoted action, which helps separate it from the sibling generate_ui_pack.

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 context: this creates an empty pack for free, while generation is a separate quoted action. It implies use when you want a free empty pack rather than a paid generation, but it never names the alternative sibling tool or states an explicit exclusion.

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, it reveals that the operation is synchronous and AI-free, that the original is untouched, and that it returns { jobId: null, animation }, so the agent should not poll. This is substantial behavioral context not present in 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 brief, front-loaded with the most important constraints, and every clause adds value—cost/sync/AI status, exact-copy semantics, original untouched, and response contract.

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 3-parameter tool with complete schema coverage, the description supplies the return shape, job behavior, side effects, and key constraints. It gives the agent enough to select and invoke the tool correctly without an output schema.

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 characterId, animation, and newId. The description reinforces that the copy is made from the current saved animation and under a new slug, but adds little parameter-level meaning beyond that.

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

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

The description uses a specific verb and resource: 'Make an exact copy of the CURRENT saved animation under a new slug' and lists preserved properties. It clearly distinguishes duplication from generation or mirroring alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: FREE, synchronous, no AI, exact duplication of the current saved animation. It also explicitly says not to poll a job, but does not name alternative tools or state when-not-to-use conditions.

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 this as read-only and idempotent, and the description adds substantial behavioral context beyond that: it preserves placement IDs, bakes custom fields, retains materialRendering/materialAreas, bakes terrain into PNGs, and warns against double-shading or duplicate visual rendering. 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 dense and front-loaded with the core purpose, and every sentence carries technical caveats rather than padding. It loses a point for being somewhat sprawling and mixing high-level output semantics with detailed per-engine rendering warnings, which could be better organized.

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 carries the burden of explaining what the export contains, and it does so thoroughly: JSON fields, bundled files, per-engine behavior, and a clear alternative for zip outputs. It is quite complete, though the lack of a clean return-structure summary and a few audience-specific rules make it slightly harder to fully rely on.

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 behavioral differences tied to engine choices, such as GameMaker using tizo_draw_tile, Tiled consumers configuring filtering from metadata, and Phaser requiring mask/blend rendering for materialAreaSource. This goes beyond the enum names, though it doesn't add much about mapId.

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 (export) and resource (map), and specifies the output as engine-ready JSON from saved level data. It also distinguishes itself from the sibling get_export_command by explicitly pointing to that tool for the zip bundle.

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 direct usage routing: 'For the zip bundle ... use get_export_command instead.' It also gives engine-specific consumer guidance for GameMaker, Tiled, and Phaser, helping an agent know when this JSON-focused export is appropriate 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?

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds substantial behavioral context: the operation defaults to a cost preview, lands as a new current revision, has automatic fallback for background-removal provider failures, has retry limits (two per failed job per session), and has no daily removal retry lockout. It also discloses the paid nature (60 credits) and the dryRun behavior. 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 dense and front-loaded with the most important constraint (LEGACY ONLY) and the cost warning. It covers many operational details in a compact block. It is long, but every sentence carries operational information an agent needs; the structure is a single block of imperative guidance rather than a clean list, which slightly hurts scannability.

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, mutating, async operation with no output schema, the description is remarkably complete: it covers cost, dryRun, pre-checks, fallback behavior, retry limits, idempotency, and the return shape ({ jobId }). The only minor gap is that it doesn't describe the full output of the real (dryRun:false) call beyond jobId, but the description explicitly says 'Returns { jobId }', which is sufficient for polling.

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 four parameters. The description adds value by explaining the dryRun default and the confirmation flow, and by clarifying that assetId must be a legacy texture asset, not a Material. It doesn't add much beyond the schema for iterationId or idempotencyKey, but the schema already covers those 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 states a specific verb and resource ('Make an old texture tile seamless') and clearly distinguishes this from siblings by declaring 'LEGACY ONLY' and noting that new Brushable Materials reject the operation. It also names the related get_asset check, so an agent can tell this apart from convert_texture_to_material 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 gives explicit when-to-use guidance: check get_asset first, use the free seamMetric.pass verdict, and do not spend on a cell that already passes. It also explains the dryRun flow, when to re-call with dryRun:false, and when to avoid spending. This is far beyond a minimal usage note.

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 goes far beyond the annotations, revealing that this is a paid, credit-multiplying operation, that existing animation slugs are never replaced but the server allocates numeric suffixes, that dry-run defaults to a cost preview, that setup and Luna classification run only after confirmation, that directional approval may be required, that animations default to 2 seconds, and that PROMPT_TOO_LONG can occur before charging. No annotation is contradicted, and the description provides the full behavioral context an agent needs.

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 major section earns its place given the 14 parameters, the expensive and asynchronous nature of the operation, and the need to coordinate with sibling tools and user approvals. It front-loads the most critical information—cost multiplication, text-free output, and the difference from create_animation_from_pose—before diving into workflow details. It is not a model of brevity, and a tighter structure with headings would help, but for this complexity it is appropriately dense rather than padded.

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

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

The description covers the full lifecycle: cost preview, user confirmation, direction mode resolution, naming behavior, per-operation jobs, polling, directional approval, pipeline token handling, wallet limits, error handling, quality gates, and the exact output shape. With no output schema present, the description carries that burden and does so thoroughly. An agent has enough context to invoke, verify, and recover from failures 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?

Although schema coverage is 100%, the description adds substantial behavioral meaning to parameters: dryRun should be re-called only after explicit user approval, animDurations must be omitted unless the user requests otherwise, animationDirectionMode must be passed on both dry-run and confirmation and preselected from get_character, animationPipelineAssignmentToken must be copied verbatim, and poseFirstFrameIds/poseLastFrameIds must be resolved through list_character_poses. This goes beyond the schema's field-level descriptions and materially improves correct invocation.

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 exact operation—generating character animations—and pins it against siblings: it is real motion rather than the 1-frame still from create_animation_from_pose, and it is not the separate visible-turn action generate_character_turn. This gives an agent a precise, differentiable 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?

The description explicitly says when to use this tool, when not to use it, and which alternatives to call instead: use it for any real motion including walk cycles and attacks, do NOT use create_animation_from_pose for 1-frame stills, do NOT use generate_character_turn merely to prepare an animation, and use list_character_poses when the user wants stored poses as video endpoints. It also warns to ask the user before spending and to poll jobs, giving an agent a clear invocation policy.

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 behavior far beyond the annotations: paid 200-credit cost, free retry semantics, 409 ENTITY_BUSY, never overwriting existing turns (turn_2/turn_3), no directional-pose approval checkpoint for standalone calls, and the discardPendingResult escape hatch. There is no contradiction with 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 it is front-loaded with the most critical operational facts (cost, dry run, free retry) before moving through purpose, eligibility, naming, concurrency, output, and edge cases. Every sentence carries substantive guidance needed to invoke the tool correctly; the density is appropriate 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?

There is no output schema, but the description specifies the return shape ({ jobId, animation, resumed }) and tells the agent to poll get_job. It also covers errors, busy states, eligibility, retries, cost, naming collisions, and checkpoint behavior. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already documents all five parameters, the description adds crucial per-parameter behavioral context: dryRun defaults to true and returns a quote; seedPoseId controls the resulting animation name; idempotencyKey must be reused on specific retries to prevent double-dispatch; and discardPendingResult is a support-only escape that abandons a stale result and triggers a new paid generation.

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 verb and resource: it spins the character through a full 360 and lands an animation named 'turn' or 'turn_<seedPoseId>'. It differentiates this from generate_character_animation's internal mid-walk rotationasia and states eligibility explicitly (topdown and isometric only). An agent can tell exactly what this tool produces and how it differs from related siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives precise when-to-use guidance: only for topdown/isometric characters, not for platformer/point_and_click, and not as mandatory setup for every animation. It also names the sibling alternative (generate_character_animation) and clarifies the dryRun-first confirmation flow, plus when to poll get_job on ENTITY_BUSY.

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 significant behavior beyond the annotations: credit costs, the dryRun default that changes the call's behavior, the { poseId } return, and the absence of a jobId requiring polling. This is exactly the behavioral context an agent needs and none of it conflicts with 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?

Three sentences deliver cost, default behavior, return shape, and completion-polling instructions with no filler. The most decision-relevant facts (paid, dryRun default) are front-loaded.

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

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

For a paid, no-output-schema tool with a nonstandard dryRun flow, the description covers the essential workflow: pricing, preview behavior, execution, result shape, and polling. The parameters are fully covered by the schema, so nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already thoroughly documents dryRun, idempotencyKey, and the other parameters. The description does not add new parameter-level meaning; it merely references dryRun and the polling workflow, 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 states a specific verb, resource, and input: "Generate a new pose for a character from a text description." It is clearly distinguishable from sibling tools like generate_character_turn or generate_character_animation, and it adds the concrete result shape ({ 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?

The description gives clear operational context: this is a paid generation call, defaults to a dry-run cost preview, and must be polled via list_character_poses because it returns no jobId. It does not explicitly name alternatives or when-not-to-use conditions, but the intended use case is unambiguous.

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 behavioral context beyond the annotations: it is PAID, SYNCHRONOUS, stores nothing, creates no assets, and defaults to a cost preview via dryRun. It also explains the approval/re-call flow. No contradiction with the annotations is evident.

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 critical operational facts (cost, synchronous, default cost preview) and remains scannable. It is slightly redundant with the schema, but each sentence earns its place overall.

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

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

With no output schema, the description compensates by naming the returned artifacts (project name, game type, art style, world description, creative guidance, validated styleGuide) and explaining the dryRun cost-preview flow. It lacks explicit error/limit handling, but the essential invocation context is present.

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 high at 86%, and the schema already documents each parameter thoroughly. The description adds little parameter-level detail beyond calling out the dryRun default, which is also in the schema, so it does not substantially compensate beyond structured data.

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 job: turning a broad game vision into a reusable project foundation and returning a validated styleGuide. It positions itself as a pre-create_project intake step, but it does not explicitly differentiate itself from the similarly named sibling generate_project_vision.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance ('broad game vision, story, or mood before create_project'), explicit when-to-skip conditions ('already supplied a complete project/style guide or asked for one specific asset'), and a recommended next step. This is strong routing behavior.

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

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

Beyond annotations (readOnlyHint:false, idempotentHint:false, destructiveHint:false), the description adds critical behavioral details: it is PAID but cheap, SYNCHRONOUS with no jobId to poll, stores NOTHING, and defaults to a cost preview. These are not present in annotations and significantly help the agent understand side effects, cost, and execution model.

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

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

The description is dense but every sentence adds value: cost/sync, output purpose, storage, and dryRun default are all front-loaded. It is longer than typical but justified by the tool's complexity. No redundant phrases.

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

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

The description covers output shape, cost model, sync behavior, storage, and the dryRun flow. It does not discuss error handling or edge cases, but for a tool with no output schema and given the schema covers parameters, this is adequate. It could mention alternatives to fully round out context, but that's more usage guidance.

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. The description does not add extra parameter meaning beyond what's in the schema (e.g., it references dryRun but the schema already explains it fully). The baseline of 3 applies since the description does not enhance 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 the tool 'turns a rough game idea into { aiVision, aiPromptGuidance, aiNegativeGuidance }' — a specific verb, resource, and output. It distinguishes from siblings like create_project and suggest_project_style by explaining its role in maintaining visual consistency, which is a unique 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?

It provides clear context on when to use it (to generate a creative brief that feeds into create_project) and explains the dryRun flow for cost approval. However, it does not explicitly name alternatives or state when NOT to use it, so the differentiation from similar tools like suggest_project_style is left implicit.

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

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

With annotations already conveying readOnlyHint=false and destructiveHint=false, the description adds genuinely new behavioral context: the 100-credit cost per paid raster/SVG batch, fonts being free, the dry-run default, and the do-not-modify-quote contract. This goes well beyond what the annotations alone disclose.

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 flow, the second explains the pricing/batch model, the third adds two critical constraints. No filler 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?

This is a complex 5-parameter tool with nested objects, a two-phase quote flow, and no output schema, yet the description never describes what the dry-run returns (estimatedCredits, quote structure, batch breakdown shape) nor the explicit confirmation/consent step before generation (left to the dryRun parameter description). Purpose and pricing are well covered, but for this complexity the flow details are incomplete.

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?

With 80% schema coverage, the baseline is 3, but the description adds interaction-level semantics the schema lacks: how the quote relates to dryRun and request (dry-run produces a signed quote that must be passed back unmodified) and the batch-pricing model. It does not mention packId or idempotencyKey, but the schema already covers those 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 states the core flow with a specific resource: get a cost preview for a UI pack component list, then generate using a signed quote. The dry-run/quote mechanism clearly distinguishes it from siblings like create_ui_pack or get_ui_pack, though it never names an alternative explicitly.

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 first sentence gives an explicit invocation pattern: preview first, then generate with the returned signed quote. 'Defaults to dry-run' and 'never alter the quote' add clear constraints on how to call correctly. However, it does not name when-not-to-use cases or alternative siblings.

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 readOnly/openWorld/idempotent annotations, the description adds significant non-obvious behavior: extraction statuses ('exact', 'recovered', 'needs_review') explain whether objects were consolidated, applied, or preserved with a warning. It also warns that grid.tiles[].url is 'a rebuilt presentation layout, not the geometry used to cut the model output' and tells agents to read the background block back when aspectRatio was unset. This prevents misinterpreting output as original file structure.

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 core result ('One asset with its revision iterations') and then systematically covers variants, extraction statuses, grid semantics, and backgrounds. Every sentence adds meaningful detail, but the dense single-paragraph structure with many clauses makes it slightly harder to scan at a glance. Still, there is no filler or repetition.

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

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

There is no output schema, so the description must carry the return-shape burden and does ensure the agent knows what to expect: Material typed material block, legacy seamless metadata, Generation exact, generationPlan/extraction statuses, grid tiles as transparent PNGs, and the background block for confirming aspect ratio. It also notes legacy asset behavior when extraction is absent. That is enough to make the tool call correctly without an output schema.

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 provides a description for assetId as 'Asset id or slug', and schema coverage is 100%. The tool description only restates 'Accepts the asset id OR its slug' without adding constraints, formats, or examples. Since the schema carries the full parameter meaning, no additional parameter semantics are needed and 3 is 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 explicitly states 'One asset with its revision iterations and typed animation projection', naming a specific verb/resource combination and its main output. It also makes clear the lookup uses 'asset id OR its slug', which distinguishes this tool from sibling getters like get_map or get_character and from list_assets. This is specific and 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 never explicitly says 'use this for a single asset lookup; use list_assets to enumerate or other getters for other resources'. The intended use is only implied by the phrase 'One asset' and 'Accepts the asset id OR its slug'. Conditional clarifications (Material vs legacy vs Generation Contract) describe output semantics, not when to choose this over a sibling, so there is no explicit 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond that: presigned URLs expire in ~1h, the in-app preview may differ from the downloaded bundle, and the top-level animationQualityGate semantics (ready/needs_review/unscored) are explained. It also discloses the collision-body resolution order and the normalization to full untrimmed frameSize. 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 dense but every sentence earns its place: it front-loads the return payload, then covers usage guidance, quality gates, collision resolution, coordinate normalization, URL expiry, and validation caveats. It is longer than a typical description, but the tool is complex and the content is high-signal. A small amount of redundancy (e.g., 'download immediately, never store or commit one') could be tightened, but the structure is logical.

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 read-only getter with one parameter and no output schema, the description is remarkably complete. It covers the return payload, the meaning of quality gates, collision-body resolution, coordinate normalization, URL expiry, and the preview-vs-bundle caveat. An agent has everything it needs to call the tool and interpret the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the only parameter, characterId, is documented in the schema. The description doesn't add parameter-level detail beyond what the schema provides, but with a single required string parameter there is little more to say. Baseline 3 is appropriate because the schema carries the parameter documentation 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 opens with a precise inventory of what the tool returns ('full PhaserCharacter JSON: animations, frameSize, gameType, animationDirection, per-group atlas + spritesheet URLs, poses and mount points'), which clearly distinguishes it from sibling getters like get_character_manifest or get_asset. The verb 'get' plus the named resource and the explicit content list make the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: preselect animationDirection before asking for directional animation generation, follow needs_review actions before claiming readiness, and check collision bodies in a specified order. It also tells the agent what not to do (never subtract atlas offsets, never store/commit presigned URLs). This is far beyond a minimal 'use this to fetch a character' statement.

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 behavior. The description adds valuable context beyond annotations: it clarifies that the files[] array is a logical canonical inventory, not an exact archive listing, and that this tool avoids downloading the zip. This is meaningful behavioral nuance that helps an agent interpret results correctly.

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 with no filler. The first sentence states the deliverable and the download behavior, the second explains usage and the key caveat with an alternative. Information is front-loaded and 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 single-parameter read-only tool with rich annotations, the description fully covers what the tool returns, why to use it, and the important caveat about files[]. The absence of an output schema is mitigated by the description naming the manifest and JSON Schema. Nothing essential is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers the single parameter characterId with a simple description. With 100% schema description coverage, the description adds little beyond the schema, and none is strictly needed for this straightforward parameter. 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?

Description states exactly what the tool returns: the tizo-export.json manifest plus its JSON Schema, without downloading the zip. It explicitly frames the purpose as learning the Phaser integration shape and field meanings, and distinguishes itself from get_export_command for exact archive contents. This is a specific verb+resource with clear sibling differentiation.

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 direct usage guidance: use this to learn integration shape before wiring an export into a game project. It also names get_export_command as the alternative when exact shipped contents matter, and explains the files[] limitation. This is explicit 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?

Annotations already mark it read-only, open-world, idempotent, and non-destructive, so the description adds substantial behavioral context beyond those hints: the 402 response carries topUpUrl, the 403 carries capSettingsUrl, freeCreditLimit reports applies:false with exemptionReason:'api_key', and the cap cannot be edited via API. This is valuable non-obvious behavior an agent needs to act correctly.

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 core purpose and is dense rather than padded. It is long, but nearly every sentence contributes decision-relevant guidance about balance vs. cap, error responses, and user communication. It could be trimmed slightly without losing value, but it remains well organized.

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 read-only billing tool with no output schema, the description is unusually complete: it covers response semantics, error-code behavior, the freeCreditLimit exception, and the exact decision path for insufficient balance versus daily cap. An agent has enough information to call the tool and interpret the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the schema already documents limit, apiKeyId, and includeLedger. The description adds some context by explaining that ledger entries carry apiKeyId/apiKeyName, which deepens the meaning of filtering, but it does not materially compensate for or add to the individual 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 opens with 'Current credit balance, and optionally the recent ledger,' which identifies the exact resource and the two modes of the call. It also clarifies that ledger entries carry apiKeyId/apiKeyName, making the tool's specific value distinct from generic getters like get_subscription_allowances.

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 is explicit about when to call it: 'Check the balance before proposing any paid generation.' It also gives conditional guidance depending on the result, including what to say when the balance is short, and distinguishes a balance shortfall from a daily spend cap trip. No alternative tool is needed because the description fully covers when this read 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?

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?

Annotations already mark the tool read-only, open-world, idempotent, and non-destructive, which is consistent. The description adds substantial behavioral context beyond those annotations: the need to execute curl externally, the API key requirement, size-variant filename behavior, Sparrow prefix routing, and the whole-character scope. It fully discloses what the agent must know before invoking it.

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

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

The description is front-loaded with the core outcome and then delivers dense, high-value constraints without filler. Every sentence contributes operational or scoping information an agent needs, from shell execution to engine-specific export behavior. It earns its length through content density rather than wordiness.

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 correctly explains what the tool returns: a download URL and a curl command line. It also covers prerequisites, export scope, engine-specific restrictions, and filename behavior. Nothing essential for correct invocation appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 even without additional parameter detail. The description adds meaningful nuance beyond the schema, such as size-agnostic canonical filenames for Phaser sheet/atlas pairs and Sparrow prefix/multisparrow assetPath routing rules. It effectively complements the structured 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 uses a specific verb and resource: it builds an authenticated download URL and ready-to-run curl line for zip exports. It clearly scopes the tool to character, asset, and map bundles, and distinguishes it from single-animation dashboard exports. The behavior is unambiguous even among many sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit operational guidance: run the curl in your own shell, requires SPRITESHIP_API_KEY to be set, and warns that multi-MB zips must not be passed through the model. It also clarifies that this exports whole characters rather than a single animation, but it does not explicitly name sibling alternatives like get_ui_pack_export_command.

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 already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond these by adding critical behavioral context: 'Free advisory version check' (no cost), 'Does not install files, grant permissions, spend credits or require an update' (clarifies side-effects), and 'Report an available update ... once' (confirms idempotency in a specific way). It also clarifies that 'Unknown is not outdated' and never downgrades, which is safety-relevant. 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 efficient and well-structured. It opens with the core purpose ('Free advisory version check'), then immediately gives usage instructions, followed by edge-case clarifications and a list of what it does not do. Every sentence adds value; there is no fluff or redundancy. The structure is front-loaded with the most important information.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It covers when to call, how to construct the call, what to expect (report update once), constraints (no downgrade, unknown is not outdated), and side-effects (none). An agent has everything needed to invoke this tool correctly without further inference.

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 detailed description including pattern and usage guidance. The description repeats the 'omit when unknown' instruction but adds no new semantic information beyond what the schema already provides. With full schema coverage, baseline 3 is appropriate; the description does not need to compensate.

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

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

The description states a specific verb ('check') and resource ('SpriteShip skill updates'), and clearly indicates it is an advisory version check. It distinguishes itself from sibling tools like get_credits or get_project by focusing on update detection, and it specifies exactly what it does not do (install, grant permissions, spend credits). This is a clear, non-tautological 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?

The description explicitly instructs when to call: 'Call once when starting SpriteShip work in a session' and how to handle the parameter: 'passing the version actually read from the installed skill; omit it when unknown.' It also clarifies edge cases: 'Unknown is not outdated; never downgrade a newer local copy' and states to report updates only once. This is explicit, 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.

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

Beyond the readOnly/idempotent annotations, the description discloses critical behavioral details: queued:true means not started and no cost incurred, terminal statuses include a credits block, and it mandates reporting credits.net and balance. It also warns against quoting pre-flight estimates and attaching purchase suggestions, which are non-obvious side effects not 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 long, but every sentence carries essential operational detail—polling cadence, failure handling, credit reporting, animation quality gate, and cost reporting rules. It is front-loaded with the core purpose, then progressively adds necessary nuance without redundancy. No filler exists.

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 lack of an output schema, the description thoroughly covers all response-handling requirements: interpreting queued status, handling error enrichment, reporting credits, and checking animation quality gates. It leaves no ambiguity about what the agent should do with the tool's result.

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 sole parameter jobId is fully described in the schema as 'Job id.' The description adds context that write tools return this ID, but the parameter meaning itself is already clear from the schema. No additional semantic depth is needed for such a trivial parameter, 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 polls a job and explicitly ties it to every write tool that returns a jobId. It differentiates itself from sibling tools like retry_job and cancel_job by focusing on status retrieval, giving a specific and unambiguous 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?

It provides explicit when-to-use guidance: poll after write operations, poll every few seconds, handle terminal states, and avoid retry when failureAction is edit_input. It also instructs when not to claim completion (animation quality gate) and how to handle credits reporting, covering both usage and non-usage 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the read-only nature is covered. The description adds useful behavioral context beyond annotations by stating that returning mapData:null when the map has never been saved, and also clarifies that several values are immutable or must be preserved on round-trip. This provides edge-case and usage information that the annotations do not.

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

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

The description is long, but the tool has no output schema, so it must document a fairly intricate payload. It is front-loaded with a high-level identity and then escalates from simple facts about immutability to more specialized rendering and gameplay details. While some details could arguably live in a schema, the description is not bloated with unrelated information.

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

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

Because no output schema is present, the description itself must explain enough for an agent to know what the map will contain. It covers the map row, saved data, the materialRendering state, terrain materialGrid, navigation, custom fields, z-order, elevation rules, cell constraints, and the null case. That is a high level of completeness for a 1-parameter, read-only fetch 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?

The schema already documents mapId as 'Map id.' with 100% coverage, so the description does not need to restate it. It adds nothing technical beyond the phrase 'map row,' so the parameter retains the baseline meaning already supplied by 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 names a specific resource ('A map row plus its saved level data') and itemizes the distinct kinds of data it returns: gameplayId, custom-field values, terrain, materialRendering, and Navigation paths. This clearly separates it from sibling fetch tools like get_asset or get_project and from list_maps, which returns a list rather than a full saved-map payload.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly covers what the tool returns, so an agent can infer this is the correct tool for fetching one map's full saved state. However, it never explicitly states when to use it instead of list_maps or get_project, nor does it say anything about retrieving only metadata or confirming a map's existence. Usage is implied rather than directly instructed.

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 read-only, idempotent, and non-destructive behavior, so the description adds value by warning that the legacy assetSuggestions field is always null and should not be polled. This is a concrete, non-obvious behavioral detail beyond what annotations provide.

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

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

Two sentences with no filler: the first front-loads the main purpose, and the second adds a targeted warning. Every clause 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 single-parameter read-only tool with no output schema, the description names the main returned elements and flags a stale field. It does not describe error or not-found behavior, but annotations already cover the safety and idempotency profile, making this sufficient for typical use.

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% for the single projectId parameter, and the schema already says 'Project id.' The description adds no new parameter-level semantics, but none are needed here.

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

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

States clearly that the tool returns a single project and names its contents: description, registered mount slots, and saved style guide. This distinguishes it from siblings like list_projects and get_project_style_guide.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'One project' implies this is for fetching a single project, but there is no explicit when-to-use guidance or mention of alternatives. With a get_project_style_guide sibling available, the description could be clearer about not using this tool for style-guide-only needs.

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 cover readOnly, idempotent, openWorld and non-destructive traits, so the bar is lower. The description still adds real behavioral context: old projects without an adopted guide get an initial suggestion, and existing assets retain their saved guide versions, which is meaningful fallback and versioning behavior 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?

Two tightly written sentences with the primary action front-loaded and edge cases following. No filler, though the structure is a touch terse for the edge-case behavior it packs in.

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?

No output schema exists, so the description carries the burden of explaining the return, and it only vaguely describes what a 'guide' or 'initial suggestion' contains. It handles edge-case behavior well but leaves the shape of the returned guide unspecified.

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?

With schema description coverage at 0%, the description must compensate for the undocumented projectId parameter, but it never mentions it. The parameter name is self-explanatory, which prevents a 1, but no format, scope, or meaning 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?

States a specific verb and resource ('Read the current guide'), and the mention of 'initial suggestion' implicitly distinguishes it from suggest_project_style and save_project_style_guide. It is clear what the tool returns, though it doesn't name the sibling alternatives outright.

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 the read context and notes the fallback for old projects, but gives no explicit when-to-use guidance or direction toward suggest_project_style or save_project_style_guide. Usage is inferable rather than stated.

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, idempotent, non-destructive), the description discloses meaningful runtime behaviors: disabled benefits return zeroed values and are unusable, unused units accumulate up to three monthly grants while enabled, and the values are not generation credits. This is valuable, non-obvious context.

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?

Four sentences, each carrying essential information, with the core purpose front-loaded. There is no filler, repetition of the title, or irrelevant 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 parameterless read-only tool, this description fully equips an agent: it explains what is returned, how disabled benefits are represented, accumulation behavior, and what the data is not. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the schema has nothing to document and the baseline is 4. The description adds useful semantics about what the response covers (limits, caps, balances) and how disabled benefits behave, which compensates for the absence of an output 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 a specific action ('Read') and a specific resource ('currently enabled subscriber benefits') and distinguishes this from generation credits. This makes the tool's purpose unmistakable even among many sibling tools like get_credits.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong contextual guidance by stating what the tool reads and explicitly noting 'These are not generation credits,' which helps an agent avoid confusing it with get_credits. It does not name an alternative tool explicitly, but the boundary is clear enough for selection.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds real behavioral context beyond them: artwork URLs expire, and native engine capability gaps should not be read as successful tests. These are non-obvious traits an agent would otherwise miss, though the second clause is terse and unexplained.

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 tight sentences with no filler, and the returnable-content list is front-loaded ahead of the caveats. The caveat sentence is somewhat compressed and under-explained, which slightly dents readability but not length.

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

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

With no output schema, the description must carry the return-shape burden, and it only partially does so by listing content categories without indicating structure, pagination, or what an empty/errored pack looks like. Adequate but with clear gaps for a read tool whose output is not otherwise specified.

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?

With a single required parameter and 100% schema description coverage ('Owned UI Pack ID'), the schema fully documents the input. The description adds no format, ownership, or scoping detail beyond what the schema already states, so the 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?

Names a specific verb (Read) and enumerates the resources returned: components, immutable revisions, capabilities, fonts, batch progress. This distinguishes it from write-side siblings like revise_ui_pack_png or create_ui_pack, though it never explicitly contrasts with the close read sibling get_ui_pack_batch.

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?

There is no statement of when to use this tool versus alternatives such as get_ui_pack_batch, get_ui_pack_batch_recovery, or list_ui_packs. The second sentence gives cautions about URLs and test outcomes, but not selection guidance 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 readOnly, idempotent, openWorld, and non-destructive, so the safety burden is covered. The description still earns credit by disclosing that a completed provider batch may not contain usable components and that a retained source URL is returned — semantic context an agent cannot get from annotations alone.

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?

A single compact sentence with the core action front-loaded. It is efficient, though 'paid batch' and the abrupt second clause compress meaning at the cost of clarity.

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 should carry return-value detail; it hints at a retained source URL but does not describe what a batch record actually contains. Combined with an undocumented batchId parameter, it is minimally adequate for a two-param read 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 coverage is only 50% — packId has a description ('Owned UI Pack ID.') but batchId has none anywhere. The description adds no syntax, format, or relationship information to compensate for that gap, so it must be scored below the 3 baseline that full coverage would grant.

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

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

States a specific verb (read) and resource (one UI Pack batch), plus an unexpected detail — the retained source URL — that tells an agent this returns more than just batch status. However, it never differentiates itself from close siblings like get_ui_pack or get_ui_pack_batch_recovery, and the phrase 'paid batch' is left unexplained.

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 clause 'provider completion does not prove usable component delivery' is a caveat about the data, not guidance on when to pick this tool over get_ui_pack_batch_recovery or get_ui_pack. No when-to-use condition, no alternatives, and no prerequisites (e.g. required ownership) are given.

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, non-destructive, and openWorld, so safety is covered. The description adds genuinely new behavioral context by flagging the image URL as 'expiring,' signaling that the returned resource is time-sensitive, plus the fact that slot delivery status is included.

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 returned data and followed by the usage trigger; every phrase carries weight with no filler. It could be marginally tighter but wastes little.

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 does outline the return payload, and annotations cover the safety profile, so an agent can call it. However it omits the undocumented batchId meaning and any mention of the recovery workflow context the name implies.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: packId is documented ('Owned UI Pack ID.') but batchId has no description in the schema. The description does not explain batchId or the relationship between packId/batchId, so it fails to compensate for the coverage gap.

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?

Specific verb (Read) plus a concrete return set: original PNG dimensions, expiring image URL, source hash, and delivered/missing slot counts. This clearly distinguishes it as an inspection tool from the plain get_ui_pack_batch sibling, though it never names that sibling to sharpen the contrast.

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 clause 'Inspect artwork before choosing crops' supplies a sequencing trigger for using it, but there is no explicit when-not guidance and no alternative tools (e.g., get_ui_pack_batch, recover_ui_pack_components) are referenced for comparison.

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 cover readOnly/idempotent/non-destructive, but the description adds real behavioral context: the output is an authenticated curl command (auth requirement), it should not be piped into model context, and it gives an engine support matrix (Phaser full, Godot/Unity pending, GameMaker/Unreal artwork-only, Tiled metadata). Only the cryptic 'Recovery artworkOnly must be explicit' clause is left unexplained.

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

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

Front-loaded with the core purpose, and every clause carries information, but the style is telegraphic ('Godot/Unity native acceptance is pending', 'Recovery artworkOnly must be explicit') and the dangling final sentence is hard to parse without opening the schema.

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

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

There is no output schema, and the description explains what is returned (an authenticated curl command), how to handle it, and the per-engine caveats. It is largely complete, though it does not say whether the command/token expires or how the component-source variant differs in the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%, so the description must compensate, and it does reasonably: 'whole/selected' maps to packId vs componentIds/sourceComponentId, 'ZIP or component source' maps to the archive vs source extraction paths, artworkOnly gets a usage rule, and engine differences are called out. sourceFormat is still left to the schema.

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

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

States a specific verb and resource: 'Return an authenticated curl command for a whole/selected UI Pack ZIP or component source.' This clearly scopes it to UI Packs and distinguishes it from get_ui_pack (metadata) and get_export_command (generic). It stops short of naming those siblings explicitly.

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?

'Run locally; never put multi-MB ZIP data into model context' tells the agent how to consume the result, and 'Recovery artworkOnly must be explicit' implies a condition for that flag. However, there is no explicit statement of when to choose this tool over get_ui_pack, get_ui_pack_batch, or get_export_command.

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 meaningful behavior beyond annotations: imports use zero credits, no subscription or allowance check is performed, upload does not remove backgrounds or fix quality, and animated formats are rejected. It also clarifies the confirmed flag semantics and instructs persisting requestId for retries. This is rich, non-obvious context and does not contradict the readOnly, destructive, or idempotent hints.

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 core purpose and then moves logically through constraints, user-notice requirements, confirmation, transport, and retry behavior. It is dense but justifiable; minor redundancy such as 'Unlimited for every account, including free users' could be tightened without losing information.

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

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

The description covers the full invocation path: pre-upload notices, file format and size constraints, confirmation semantics, local-file transport choice, and requestId persistence for retries. Since there is no output schema, success and error response behavior is left implicit, which is the only material gap for a mutating import 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?

With 0% schema coverage, the description compensates well: it maps kind to Object vs Character, explains when confirmed should be true, and advises against using imageBase64 for large local files in favor of the multipart endpoint. projectId and name are not explicitly defined, though they are named in the preferred endpoint and are relatively self-explanatory in context.

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

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

The description names a specific verb and resource: 'import ONE still PNG or WebP as an Object or Character,' so the purpose is immediately clear. It also communicates key constraints such as still images only and no animated files. It does not explicitly distinguish itself from sibling tools like create_asset or create_character, so it stops short of full sibling differentiation.

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 strong usage context: imports are free and unlimited, the user must receive a transparency/quality notice before confirmation, and confirmed should only be set after approval. It also provides transport guidance, preferring multipart POST over large base64 for local files. It does not name an alternative tool or clearly state when a sibling such as create_asset should be chosen 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?

ReadOnly, idempotent, non-destructive hints are already in annotations dry; the description adds valuable behavioral details: exposed fields and the mapping of API wire types to semantic types, plus the critical warning that hasAnimation must never be inferred from asset type.

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 compact and information-dense. Each clause earns its place; the static-type and hasAnimation caveats prevent real misinterpretation. Minor USD: no explicit statement of return shape/order, but not required for this read-only list.

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 read-only listing tool, the description sufficiently clarifies type names and a tricky inference issue. It doesn't state default ordering or scope (e.g., project context), but the openWorld and projectId parameter capture the main filtering 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?

The schema fully documents all five parameters with descriptions and a limit enum range. The description does not add parameter semantics beyond domain type mapping, 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 names the exact resource (assets), enumerates the asset categories included, and explicitly disambiguates legacy type names (e.g., collections remain `tileset`, kits as `terrain`, brushable materials as `texture`), making the tool's purpose unmistakable versus list_characters and list_maps.

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 explains what is returned and clarifies type semantics, but it never states when to prefer this over siblings like get_asset or how the list should be used. The guidance is implicit rather than explicit.

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 reveals that pose generation has no job ID, making this the correct polling mechanism, and explains the meaning of the status fields (pending, done, error) and the stall condition. This goes beyond the annotations, which only declare read-only and idempotent hints.

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, with each sentence providing necessary context: field list, usage scenario, and stall warning. It is concise yet complete without any redundant or irrelevant information.

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

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

Given the tool's role in the generation workflow, the description covers all necessary aspects: field enumeration, status semantics, integration with generate_pose and generate_character_animation, and troubleshooting guidance for stalled poses. It is fully self-contained for a user to understand when and how to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, characterId, is described in the schema as 'Character id.' The description adds no further meaning or context for this parameter, so it does not enhance understanding beyond the schema. Since schema coverage is 100%, a 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 clearly states the tool lists all poses on a character, enumerates the returned fields, and explains its role as the poll target after generate_pose and source for generate_character_animation, distinguishing it from related 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?

It explicitly states when to use this tool: after generate_pose to poll for completion, and to fetch ready pose IDs for generate_character_animation. It also warns about interpreting 'pending long after pendingSince' as a stall, providing actionable 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=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 cover read-only, open-world, idempotent, and non-destructive behavior. The description adds important hidden semantics beyond those annotations: gameType is the project-wide default perspective at creation, while a character's stored gameType later governs its own animation and turn behavior. No contradictions with annotations are present.

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 compact sentences provide the full return shape and the key usage constraint without unnecessary filler. The most important facts about the default project gameType are front-loaded in the second sentence, just after the list definition.

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 list-only with one optional parameter and rich annotations, the description is nearly complete: output fields are listed and the critical gameType nuance is explained. The only missing element is explicit mention of pagination or truncation by the optional limit, but the schema already documents default 100 and max 500.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter, limit, and the input schema already fully documents it with description, default, minimum, and maximum; schema parameter coverage is 100%. The description itself adds no parameter-specific meaning, 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 tool clearly returns all of the user's projects and explicitly lists the fields returned: id, name, gameType, style, itemCount, createdAt, updatedAt. This also differentiates it from sibling tools like get_project and list_assets by scoping the tool to the project resource set.

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 contextual guidance: it tells the agent to read project.gameType before generating anything because it is the default perspective for new content. It does not explicitly mention when to avoid this tool or name alternatives, but the sibling list and 'all projects' framing make the intended usage 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds billing behavior the annotations do not convey – that selection, preview and export are free of customer credits – which is genuine extra context, though return format and pagination remain undisclosed.

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

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

Two short sentences, scope stated first, cost caveat second. No filler and nothing buried.

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

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

For a zero-parameter list tool with no output schema, the description covers what the tool returns and its cost profile. It stops short of describing the catalog's shape or ordering, a minor gap given the small surface area.

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?

Zero parameters, so there is nothing for the schema to document and this dimension defaults to the 4 baseline. No parameter-level meaning is required or missing.

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

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

States a specific verb+resource: 'Read the retained licensed Google Fonts catalog.' An agent knows exactly what is returned. It does not name a sibling or explain how it differs from other list_* tools, so it stays at 4 rather than 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 credit-cost note ('selection, preview and export cost zero customer credits') implies when this is cheap to call, but there is no explicit when-to-use guidance or named alternative. Usage is implied rather than stated.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds one genuinely useful behavioral detail the annotations lack: results are scoped to packs the caller owns. It says nothing about result size, pagination, or ordering.

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?

A single short sentence carrying verb, resource, and both scope qualifiers with zero filler. Front-loaded and fully earned.

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 read-only list tool whose annotations cover safety and idempotency, the description is close to complete; the ownership scoping is the key bit an agent needs. Missing only return-shape/pagination context, and there is no output schema to cover it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single param projectId, so the description must compensate. Saying the listing is 'optionally within a project' does convey that projectId is optional and acts as a scope filter, which is real added meaning, but no format or expected value is given.

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

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

States a specific verb (List) and resource (UI Packs) plus scope (owned, optionally by project), which is enough to distinguish it from get_ui_pack and list_ui_fonts. It stops short of explicitly naming those siblings but the resource noun 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?

The 'owned' qualifier and 'optionally within a project' hint at when to use it, but there is no explicit when-to-use/when-not guidance and no reference to alternatives like get_ui_pack for a single pack. Usage is implied rather than stated.

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?

Annotations indicate non-destructive (destructiveHint=false) but description adds crucial behavior: 'the source animation is untouched,' 'FREE, no AI,' and async returns via job polling. It also discloses that frame windows index the FULL capture, which is an important caveat for correct use.

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 delivers value: purpose, classic example, proposal hint, indexing note, and return contract. It is front-loaded with the core action and remains compact despite covering multiple important nuances.

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

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

The tool is async (returns jobId), has a non-trivial input (phase windows), and relies on external context (phaseProposal). The description covers all of this: how to get proposals, indexing semantics, output shape, and polling guidance. No significant gaps remain.

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 covers 100% of parameters, so baseline is 3. The description adds meaningful semantics beyond schema: clarifies that frame windows are absolute indices into the FULL capture, and suggests phaseProposal as a verbatim source for the phases array. This elevates the score.

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

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

The description states a specific verb+resource: 'Carve ONE multi-state clip into separate game-phase animations by frame windows.' It gives a concrete example (jump → crouch/rise/fall/land) and distinguishes this from other animation tools by emphasizing it splits one clip into multiple exportable animations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly explains when to use this tool (multi-state clips needing game-phase separation) and provides the classic jump example. It even guides users to leverage phaseProposal from get_character. However, it doesn't explicitly mention alternatives or when not to use it, leaving room for minor ambiguity.

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. The description adds substantial behavioral detail beyond that: it explains the conditional return of detailed summaries only when a snapshot is present, the upgrade path for v1 lock files, the explicit actions it plans (without executing them), and the safety constraint about local file deletion. It also discloses rate-limit handling via Retry-After, which is not implied 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 dense but each sentence contributes meaning. It is front-loaded with the core purpose and then adds conditional behavior, upgrade notes, limits, and safety in a logical order. It is longer than typical, but the tool's complexity warrants the length. No redundancy or filler sentences.

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 planning tool with no output schema, the description covers the main return categories (unchanged/changed/unavailable, detailed summaries, actions), conditions for detailed summaries, legacy support, request limits, rate limiting, and safety. It doesn't describe the exact JSON response structure, but it lists the information types. Given the tool's complexity, this is a strong but not exhaustive coverage.

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 itself contains descriptions for each property (id, kind, engine, version, snapshot, artworkOnly, componentIds), so the description doesn't need to repeat them. The description adds valuable semantics around the snapshot parameter: it clarifies that snapshots come from prior calls and enable richer summaries, and explains the v1 upgrade behavior. Since schema coverage is effectively complete, the description's additional guidance on when to provide snapshot and the limit of 100 entries justifies a high score.

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

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

States a specific verb and resource: 'Compare the versions in assets/spriteship/spriteship.lock.json with current SpriteShip state in one call.' It clearly distinguishes itself from individual getters and lists by being a bulk comparison that returns per-entity statuses. The mention of returning actions (fetch/download/review-removal) further clarifies its planning role.

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 clear context for when to use this tool: for checking changed entities and planning sync actions. It implicitly contrasts with individual get_* tools by being bulk and comparative. It also gives operational guidance: honor Retry-After, request limit of 100 entries, and the safety rule about not deleting without confirmation. It doesn't explicitly name alternatives but the context is sufficient for an agent to decide.

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, it discloses that the operation is FREE and no-AI, that it cannot change art, that image-only characters return NO_ANIMATIONS_TO_REBUILD without creating a job, and that targeted rebuilds return an operationId/jobId to poll. This gives agents a strong behavioral model.

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

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

The description is front-loaded with the core purpose and is reasonably sized, but it includes dense jargon like 'exact pose-owned scale references' and 'sibling-independent' that is unlikely to help an agent. Some sentences overlap with schema information and reduce conciseness.

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 and lack of an output schema, the description covers the main use cases, response format, and an important edge case (image-only characters). It is not fully complete because it leaves some technical phrases vague and doesn't explain failure modes beyond the image-only case.

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 provides 100% parameter description coverage, so the baseline is 3. The description adds some context around the animation parameter's optionality and full-character rebuild behavior, but it largely restates what the schema says and does not clarify parameter formats or constraints beyond that.

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

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

The description clearly identifies the tool as a repair/refresh tool that re-renders an animation from durable cached frames, with a specific verb and resource. It differentiates itself from art-generation siblings by explicitly stating it never re-generates art and only repacks/normalizes frames.

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 conditions: use it when a sheet looks stale or wrong after edits, or after a previous rebuild failed. It also states when not to use it (to change art) and how to distinguish targeted vs full-character rebuilds, though it does not name an alternative tool by name.

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=false, destructiveHint=false, and idempotentHint=false. The description adds meaningful non-structured behavior: no credit charge, no provider call, and that previously delivered siblings are preserved. The stale-source guard via sourceHash is implied but not explicitly explained as a failure mode.

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?

Four short sentences, each contributing something (action, cost, integrity guard, follow-up). Slightly clipped telegraphic style, but front-loaded and waste-free.

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 non-idempotent write tool with no output schema and only 25% schema coverage, the description covers cost and preservation behavior but omits what happens on hash mismatch, whether recovery is repeatable, and what the post-recovery validation check returns.

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 only 25%, so the description must carry weight. It clarifies that crop bounds are 'original-pixel rectangles' and that sourceHash must be 'current', but says nothing about packId, batchId, or the 0-7 index semantics of the crops array.

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

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

States a specific verb and resource: cropping missing slots from a retained original PNG. The phrase 'already delivered siblings remain untouched' implicitly separates it from siblings like revise_ui_pack_png and replace_ui_component_png, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear triggering condition ('after visual review' of missing slots) and a follow-up step ('Inspect validation after recovery'), plus a cost rationale (no provider call or credit charge) that affects tool choice. It stops short of naming an alternative tool to use instead when the conditions don't hold.

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 paid nature and cost rate, explains the dryRun cost-preview default, guarantees earlier takes are preserved (reinforcing destructiveHint=false), and states the return contract with polling guidance. 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 compact and front-loaded, leading with the PAID warning and cost formula. Every sentence earns its place: scope, preservation guarantee, dryRun default, and jobId return. The all-caps emphasis highlights the most action-relevant facts without bloat.

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 7-parameter mutation tool with no output schema, the description covers the essential operational contract: single-pair scope, preservation of existing takes, cost preview default, required user approval, and the returned jobId with polling direction. Parameter details are already fully covered by the schema.

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 highlighting the dryRun default, tying the cost preview to the approval workflow, and clarifying that durationSeconds only informs the cost estimate. This meaningfully supplements the structured 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 states a specific verb, resource, and scope: 'Re-run video generation for a SINGLE motion pair of an animated asset, leaving its other pairs alone.' It further distinguishes itself by explaining that the new take is an additional iteration and earlier takes are preserved, which separates it from broad regeneration or duplication siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear context is provided: this tool is for regenerating exactly one motion pair while preserving other pairs, and it defaults to a cost preview before spending. It does not explicitly name alternatives or exclusions, but the scope condition is concrete 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?

Annotations indicate readOnly=false, destructiveHint=false, idempotentHint=false, which are consistent with the description's statement that the cleaner version is kept only if it measures better, and that it can never make the animation worse. The description goes beyond annotations by detailing the matteRepair stamp semantics, the conditional keep, the unchanged motion, the async pattern (returns { jobId } and poll get_job), and the source video expiration failure. This rich context is not redundant with annotations and enhances transparency. 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 concise yet packed with valuable details: purpose, safety guarantee, retry behavior, failure mode, and return usage. It is front-loaded with the main action and condition. The opening 'FREE, no AI' may be slightly tangential but adds context about cost/technology. Overall, each sentence earns its place, though the density could be overwhelming for a quick scan.

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 that there is no output schema, the description compensates by clearly stating the return shape ({ jobId }) and the subsequent steps (poll get_job, re-read quality block). It also covers prerequisites (deliveredIssues containing 'matte'), the non-destructive conditional behavior, retry semantics, and the SOURCE_VIDEO_EXPIRED failure mode. This completes the tool's context for an async mutation operation, making it highly informative.

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 provides 100% coverage for both parameters, with descriptions for 'animation' (Animation slug to re-matte in place) and 'characterId' (Character id). The tool description does not add significant parameter-specific meaning; it only mentions 'ONE animation's source video', which aligns with the existing schema. Given the high schema coverage, the baseline of 3 is appropriate, with no need for the description to compensate.

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 fixes edge artifacts (matte) on one animation's source video, specifically as a repair for quality read issues containing 'matte'. It distinguishes itself by targeting animation-specific quality defects and explicitly mentions the resource (animation) and the action (re-matte). This provides a specific verb+resource combination that sets it apart from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: 'the repair for a quality read showing deliveredIssues containing "matte"' with examples (green fringe, flickering holes, ragged edges). It also provides an exclusion: if the same frames were already tried (matteRepair stamp), regenerate the animation instead. It further mentions the FREE and no-AI nature, as well as the SOURCE_VIDEO_EXPIRED failure, giving clear context for decision-making.

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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing what survives a rename (IDs, artwork, historical revisions), the cost model ('for free'), the optimistic-concurrency guard via expectedName, and the downstream effect that re-sync refreshes the exported display name. This is exactly the mutation-relevant context annotations can't provide.

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

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

Two sentences, no waste, front-loaded with the action and cost, followed by the safety mechanic and preservation guarantees. Every clause 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 non-idempotent mutation tool with no output schema, the description covers cost, concurrency behavior, and preservation/sync side effects. It stops short of describing failure/error behavior or the return value, but is otherwise complete enough to call 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 only 50% — packId and componentId are documented but name and expectedName are not. The description compensates by explaining expectedName is the component's CURRENT name used as a stale-edit guard, though the new-name parameter is left to inference.

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

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

States a specific verb (Rename) and resource (an owned UI component) and adds a distinguishing constraint ('owned', 'for free'). An agent can immediately tell this apart from save_ui_component_defaults, replace_ui_component_png, and revise_ui_pack_png in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational context — 'Supply its current name as expectedName to reject stale edits' — which tells the agent how and when the call is safe to make. It does not, however, name alternative tools or state when another sibling should be preferred 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?

Annotations cover the safety profile (non-read-only, open-world, non-idempotent, non-destructive), and the description adds genuinely new behavioral facts: the prior revision is preserved, behavior metadata is revalidated, and hard input limits apply. It still does not say what happens on validation failure or whether the call consumes the referenced revisionId.

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 compact clauses, front-loaded with the primary action and followed by side effects and limits; every phrase carries information. 'Free' is a marginal inclusion but does convey no-cost invocation.

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

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

For a mutation tool with no output schema, the description covers the main effects and input limits, which is the minimum viable set. It omits ownership/permission expectations (the schema only hints 'Owned'), failure behavior, and what the caller sees after revalidation, leaving real gaps for a write operation.

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 only 50%: revisionId and imageBase64 carry no schema descriptions, and the description adds nothing about either — it does not explain whether revisionId targets the revision being replaced or the new base, nor what encoding/format imageBase64 expects. The size constraints loosely map to imageBase64 but without stating the field.

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

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

The description states a specific verb and resource: saving a locally edited PNG for a UI component, plus secondary effects (revalidate metadata, preserve prior revision). It distinguishes scope from the sibling revise_ui_pack_png by targeting a single component, but it never names that sibling explicitly, so the agent must infer the boundary from the tool name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent can infer this is for pushing a locally edited PNG back, and hard constraints (4 MB, 2048 px, no SVG) narrow applicability. There is no explicit when-to-use, when-not-to-use, or routing to revise_ui_pack_png or import_asset_image.

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=false and openWorldHint=true, but the description adds crucial behavioral context: the operation is synchronous and free, modern manifest revisions are never re-sliced, legacy paths retain source-sheet re-cutting, fitItemIndices is one-shot, omitted fields preserve current values, and cellOffsets:[]/cellInset:0 clear values. It also tells the agent to call get_asset afterwards. This goes well beyond the annotations and makes the side effects and return behavior clear.

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

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

The description is dense but every sentence earns its place: sync/free status, main operation, per-revision path differences, legacy prerequisites, field semantics, clearing semantics, and follow-up call. The most important operational facts (FREE, SYNCHRONOUS, no polling) are front-loaded. It is long, but the tool has real complexity to convey.

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 6-parameter synchronous tool with no output schema, the description covers the operation, the revision-dependent behaviors, the legacy upgrade prerequisite, clearing semantics, and the recommended follow-up call. There is no obvious missing piece an agent would need to safely invoke it or interpret the flow.

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 params are already documented. The description adds meaning beyond the schema by explaining how parameters interact: anchor chooses the shared fixed point, cellOffsets apply per-item nudges, cellInset removes legacy separator bleed, fitItemIndices makes items fill their shared cell while preserving aspect ratio, and omitted fields keep current values. It doesn't enumerate every enum value, but the schema already does that.

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

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

The description states a specific verb+resource: 'Rebuild a staged, tileset, or terrain collection's presentation layout', and clearly differentiates itself from siblings like animate_asset, fix_asset_seams, or revise_asset by describing the layout/arrangement operation. It names the key dimensions (anchor, cellOffsets, cellInset, fitItemIndices) and distinguishes modern manifest revisions from legacy revisions, so an agent can identify the tool's unique role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: 'FREE and SYNCHRONOUS (no jobId — do not poll)', 'Legacy terrain must be upgraded to independent items first', and 'call get_asset afterwards for fresh presigned tile URLs'. It also states what not to expect (no AI) and how to clear fields, leaving little ambiguity about when this tool 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?

Annotations indicate this is not read-only but the description adds valuable behavioral detail beyond them: it is FREE, reuses the saved image, and never generates or charges for another image. It also discloses cooldown/retry behavior, which is not inferable from annotations or schema. This meaningfully informs agent expectations.

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 deliver a clear trigger, cost implication, and retry behavior with zero filler. The most decision-relevant fact ('FREE') 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?

For a simple two-parameter recovery action with no output schema, the description covers the key operational context: trigger condition, cost semantics, and cooldown/polling flow. The only minor gap is the lack of detail about the response value or how to interpret success beyond polling list_character_poses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden for parameter meaning. It identifies that a 'failed pose' is involved but does not explain what characterId and poseId represent beyond their names, nor how to obtain valid values. The agent must infer that poseId refers to the failed pose and characterId to the owning character.

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

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

The description states a specific verb ('Resume') and resource ('failed pose' / 'saved pose background removal'), and adds a precise trigger condition ('when list_character_poses reports removalRecoveryAvailable'). This clearly distinguishes it from sibling retry/resume tools like retry_job or resume_ui_pack_batch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: only when list_character_poses reports removalRecoveryAvailable. It also provides operational guidance for cooldown handling and subsequent polling. It does not explicitly name exclusions or alternatives, but the usage context is clear enough.

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