Claude Imagine

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

The description adds meaningful operational detail beyond the annotations: it never starts anything, consumes no credits, can wait for a running task, and is restricted to the caller's own generations. These points align with readOnlyHint, idempotentHint, and destructiveHint=false, and enrich what the agent knows about side effects.

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

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

Two sentences front-load the core action and resource, then add the key caveats (no cost, no side effects, waiting behavior, id provenance) without redundancy. Every sentence carries distinct useful information.

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

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

For a single-parameter read/idempotent tool with rich annotations, the description covers the essential behavior: what it returns, when it waits, where the task id comes from, and that it is free and non-starting. No output schema is present, but this level of detail is sufficient for an agent to select and invoke the tool correctly.

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

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

The schema already covers task_id fully, but the description adds value by specifying that task ids come from generation replies or list_generations and explaining how the task_id relates to finished versus running generations. This helps the agent select the correct value beyond the schema's simple field description.

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

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

The description opens with a specific verb ('Return') and resource ('one of the caller's own image or video generations by task id'), which is far more informative than the title. It distinguishes itself from generation tools by explicitly stating it never starts a new generation and from list_generations by targeting a single task id.

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

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

The description clearly indicates when to call it: when you already have a task id and need the finished generation, or when a generation is still running and should be awaited. It also tells the agent where task ids come from, though it does not explicitly name sibling alternatives or say when not to use them.

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 are conservative (destructiveHint=true, not readOnly, not idempotent) but generic; the description adds real value by clarifying that the original is untouched and only a new image is produced, and that Claude Imagine credits are consumed. It stops short of describing response shape, latency, or failure modes beyond the max_credits schema note. The "original is untouched" statement does not contradict destructiveHint, which here reasonably extends to credit consumption rather than data loss.

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, front-loaded with the core verb and resource, with no filler. Every clause contributes either scope, invocation detail, or prompt-craft advice.

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 tell the agent the result is a new image rather than a mutation of the source, but it does not say what the return payload contains (e.g., a new URL). Credit budget behavior is covered by the max_credits schema, so the remaining gap is minor.

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

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

Schema description coverage is 100%, so the baseline is 3; the description still adds meaning by specifying that image_urls should be the full-resolution URL (typically from an earlier generation), disambiguating it from thumbnails. The prompt guidance about stating what must stay the same also enriches the prompt parameter beyond the schema example.

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?

"Edit an existing image with a text instruction" names a specific verb and resource, and the word "existing" implicitly separates it from the sibling generate_image. An agent can tell it produces a new edited image rather than a fresh generation without opening the schema.

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

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

Gives clear invocation context: pass the full-resolution URL of the image to change, and state what must stay the same in the prompt. It does not explicitly name when to prefer generate_image or another sibling instead, but the operational context 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?

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotency, so the safety profile is covered. The description adds meaningful context beyond them: the operation consumes Claude Imagine credits and the return payload is both inline image data and a full-resolution URL. It does not explain why the call is destructive or irreversible (credit spend on a rejected/failed job), which is the one residual gap.

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 short sentences with zero waste: purpose first, return shape second, routing alternative last. Nothing is buried and no sentence merely restates the tool name.

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 supplies the return contract (inline image plus full-resolution URL). For a paid, non-idempotent generation tool with check_generation and quote_generation siblings, it leaves open whether this call blocks or is polled, and whether cost should be quoted first — a modest but real 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%, with model choices, aspect-ratio enum, prompt length limit, and max_credits budget behavior all documented in the schema itself. The description only echoes 'text prompt' and adds no parameter syntax or format detail beyond the structured fields, 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?

Specific verb+resource ('Generate an AI image from a text prompt') plus scope and cost mechanism ('using Claude Imagine credits'), and it explicitly distinguishes itself from the sibling edit_image. An agent can separate it from edit_image, generate_video, and list_generations 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?

It names the alternative tool and the condition that selects it ('To change an existing image, use edit_image'), which is genuine routing guidance. It does not address other plausible siblings such as quote_generation for pre-cost estimation or check_generation for job status, so the coverage is clear but not exhaustive.

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

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

Discloses that the first H3 Max Turbo clip is free, subsequent usage costs credits, and the max_credits parameter caps spending with a defined behavior (nothing started, reply lists what fits). This goes beyond the annotations by detailing cost-related behavior and budget handling.

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

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

Though relatively long, every sentence provides necessary detail: model options, aliases, cost policy, defaults, and when to defer to sibling tools. The structure is logical and front-loaded with the core action, without redundant or unrelated content.

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

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

Given the sibling tools (check_generation, quote_generation, list_models, get_credits), the description covers the full context: what to do before generating, how to set budget, and what model to choose. The absence of an output schema is acceptable since the tool likely starts an async job and returns a generation ID, which is implicitly covered by the sibling check_generation.

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 descriptions cover all 7 parameters (100% coverage), and the description text adds valuable aliases and default rules (e.g., 'h3' -> h3-max-turbo, default only when user did not name a model). This fully clarifies parameter meaning and allowed 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 states the tool generates AI videos, specifies the models available, and distinguishes it from siblings like generate_image and edit_image. The verb 'Generate' and resource 'AI video' are explicit, and the model list differentiates it from other 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?

Explicitly instructs when to call list_models or quote_generation first, namely when the user wants to review models and costs before spending credits. Also clarifies when to omit the model parameter, providing unambiguous usage guidance.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, and the description ('Get the remaining credit balance') is consistent with these. The description adds no extra behavioral context beyond what the annotations provide, but since it is a simple read operation, no further disclosure is necessary. It neither contradicts nor meaningfully extends 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 a single, front-loaded sentence that states the action and resource without any filler. Every word contributes to the meaning, making it exceptionally concise and well-structured.

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

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

For a zero-parameter, read-only tool with no output schema, the description fully captures what the tool does. There are no missing details an agent would need to call it correctly; the absence of parameters and the simple nature of the tool make this description complete.

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

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

The tool has no parameters, and the schema coverage is 100% (empty schema). With zero parameters, the description has no parameter semantics to clarify, so a baseline of 4 is appropriate. No additional explanation is needed.

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 ('Get') and a clear resource ('remaining credit balance for this account'), making the tool's purpose unambiguous. It is clearly distinct from the sibling tools 'generate_image' and 'list_models' based on the action and resource mentioned.

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?

While the description does not explicitly mention alternatives or exclusions, the purpose is self-evident and the tool has no parameters, so there is little ambiguity about when to use it. The siblings are unrelated in function, and the absence of explicit guidance does not hinder correct 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?

The annotations already mark the operation as read-only and non-destructive, and the description adds valuable behavioral context: it is free, returns records only, never starts anything, and is scoped to the caller's own account. 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?

Three sentences, each earning its place: what is listed, how to use the results, and the side-effect/safety note. The key scoping detail 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?

For a read-only list tool with optional filters and no output schema, the description is complete enough: it covers scope, ordering, side-effect absence, and how to consume the returned task ids/URLs with downstream tools. The annotations cover the safety profile, so 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?

The input schema has descriptions for limit and query, but type and status are only bare enums. The description partially compensates by clarifying the content is image and video generations and that results are newest first, but it does not explain the type/status filter semantics or parameter combinations beyond what the schema already offers.

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: listing the caller's own recent image and video generations, newest first, including website-made generations. This scope distinguishes it clearly from siblings like check_generation, edit_image, and generate_video.

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

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

The description explicitly says when to use it: to find an earlier result to show again, edit, or animate. It also routes the agent to the correct next tools by mentioning task ids with check_generation and URLs with edit_image / generate_video.

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 communicate readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds one useful behavioral detail beyond annotations: that each model has an associated credit cost, which informs the agent about the nature of the returned data. However, it does not mention response format, pagination, or ordering, but given the simplicity and annotation coverage, a 3 is appropriate.

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

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

The description is a single sentence that front-loads the action and states the essential output detail. There is no wasted wording, and it is appropriately sized for a tool with no parameters and a simple return set.

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 straightforward list tool with no parameters, no output schema, and annotations covering safety, the description provides sufficient context: it specifies what is listed (models) and a key attribute (credit cost). It could be slightly more explicit about the return structure (e.g., array of objects with model ID and cost), but that is a minor gap given the simplicity.

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

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

The tool has zero parameters, and schema description coverage is 100% (vacuously). With 0 params, the baseline is 4, and the description does not need to explain any input semantics. It correctly focuses on the output (models and credit costs) rather than parameters, which 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 action (list), the resource (available image and video models), and a specific detail (credit cost). It distinguishes itself from siblings like generate_image and generate_video, which perform generation, and get_credits, which presumably queries credit balance. The verb and resource are 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 does not explicitly state when to use this tool versus alternatives. However, the purpose is clear and siblings are semantically distinct (generation vs. listing), so the intended usage is implied. No exclusions or conditions are provided, which keeps it at a baseline 'implied' level 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 discloses that the call is free, never starts a generation, and returns exact account prices, prompts, budget guidance, and output checks. This is consistent with the readOnlyHint and idempotentHint annotations, adding practical detail about what the agent will receive without contradicting the annotations.

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

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

The description is concise, with three sentences covering purpose, return value, cost, and usage timing. It is well-structured and free of redundancy, making it easy for an agent to parse quickly.

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

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

Despite having no output schema, the description sufficiently informs the agent of what to expect (prices, prompts, budget guidance, output checks) and references related tools like list_models for duration validity. This is complete enough for correct selection and 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?

All six parameters have clear descriptions. For example, max_credits explains the full budget scope, retries included, and the STOP behavior; video_model explains the fallback logic; image_url explains the behavior when absent. Schema coverage is 100% and each description adds meaningful 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 explicitly states the tool's purpose: to plan a complete product-photo workflow, returning prices, prompts, budget guidance, and output checks. It clearly distinguishes its role from generation tools by instructing to use it before making product ads or videos and noting it never starts a generation.

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

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

It provides explicit usage guidance: 'Use before making product ads or product videos.' It also clarifies cost behavior ('Free: never starts a generation') and describes how budget and model selection are handled, steering agents to this planning step before invoking sibling generation tools.

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

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

The description explicitly states that the call is free, reserves nothing, and starts nothing, which complements the readOnly and idempotent annotations. There is 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 brief and front-loaded with the core purpose, followed by a clear usage directive and a concise side-effect statement. Every sentence adds value.

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

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

The description sufficiently explains what the tool returns and that it does not execute generation. It does not specify output format, but no output schema exists and the core behavior is clearly covered.

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

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

The schema already has full description coverage for all parameters, including enums and the generate_video-only constraints. The description adds no extra parameter-level meaning beyond the schema.

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

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

The description clearly states the tool returns the exact credit cost for specific generation tools before making the call, and also includes balance and plan eligibility. It distinguishes this quoting purpose from actual generation or checking balances.

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

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

It explicitly says to use this tool whenever price or budget comes up and to avoid estimating. It does not explicitly name sibling alternatives like get_credits, 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.