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

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

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

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

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

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

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

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

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

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

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

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

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

The description clearly states the tool's purpose: 'Make a texture tile seamlessly.' This is a specific verb+resource combination that immediately distinguishes it from sibling tools like revise_asset or reprocess_asset. It also provides critical context about being a paid image-to-image call, which further differentiates it from free inspection tools.

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

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

The description gives explicit usage guidance: check get_asset first, use the free seamMetric.pass verdict to avoid spending credits on cells that already tile, and do not spend on passing cells. It also instructs to use the dryRun argument to preview cost and get explicit user approval before the real call. This clearly tells the agent when to use this tool versus alternatives.

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