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?

Annotation Contradiction: destructiveHint=true implies destructive behavior, but the description explicitly says 'the original is untouched' and 'the result is a new image.' This direct contradiction makes the behavioral profile unreliable, so a score of 1 is required.

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

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

Three sentences, no filler, and the core action is front-loaded. The guidance about preserving content earns its place and does not bloat the description.

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 the non-obvious operational facts: credit usage, non-destructive output, and prompt phrasing advice. It does not explicitly discuss cost quoting or when to prefer a generation tool, but the rich schema and sibling context make those gaps 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 adds minor value by advising use of the full-resolution URL and emphasizing that the prompt should preserve unchanged content, but the schema already documents all parameters thoroughly.

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 ('Edit'), resource ('existing image'), and method ('text instruction'). The contrast between 'result is a new image' and 'original is untouched' clearly distinguishes it from generation-focused siblings like generate_image.

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 the tool: editing an existing image, not creating one. It also gives a practical prompt-construction rule ('say what must stay the same'), but it does not explicitly name sibling alternatives or state when not to use this 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?

Description notes that the tool 'Returns the image inline plus its full-resolution URL', which is useful beyond annotations. It hints at credit consumption ('using... credits'), but annotations already mark destructiveHint=true. No contradiction; the description adds context that generation consumes credits and returns a URL, which is valuable given the annotations don't cover return 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?

Description is compact, with front-loaded purpose and return info. The additional usage guidance is essential and concise. Slightly long due to the resolution parameter explanation, but that's in the schema, not the main description, so overall the main description is efficient.

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 (6 params, 4 enums, no output schema), the description covers purpose, usage, return format, and routing to siblings. Missing output schema is compensated by describing the return. All critical aspects for correct invocation are addressed.

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 baseline is 3. Description adds significant value: explains that style sets framing and aspect ratio (and prompt should only describe subject), that resolution is for size signals only with detailed guidance, and that max_credits is a budget cap. This goes beyond schema 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 the verb ('Generate'), resource ('AI image'), input ('text prompt'), and an explicit tie to 'Claude Imagine credits', distinguishing it from siblings like edit_image and generate_video. The first sentence 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?

Explicitly tells when to use the tool (new image from prompt) and when not (to change an existing image, use edit_image). It also instructs to call list_styles first for specific use cases (e.g., YouTube thumbnail, book cover) and pass its id as style. This is clear, actionable routing.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: the tool is free, results surface as a picker card in claude.ai, and there are exactly four styles per category. 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?

Three tight sentences, front-loaded with purpose, then cost, then usage workflow. The single-word sentence 'Free.' earns its place as a key behavioral fact, and nothing is redundant or padded.

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

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

For a simple read-only list tool with one optional parameter and rich annotations, the description covers purpose, categories, count, cost, and the consumption flow. With no output schema, it could have specified the exact return object shape in more detail, but it does state the critical fact that the result contains an id to pass to generate_image, which is what an agent needs.

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%, setting the baseline at 3. The description adds real value by mapping the opaque enum values (cover-art) to human concepts ('album and podcast cover art') and clarifying the relationship between the category field and the enumerated looks. This helps an agent choose the correct enum value without opening 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 states a specific action (listing named styles) tied to a specific resource (generate_image) and enumerates the exact categories with a per-category count ('four styles each'). It is clearly distinguishable from siblings like list_models and list_generations by explicitly framing the output as the style picker for generate_image.

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 an explicit trigger condition ('Call it when the person wants one of those') and a full follow-up workflow: show the picker, then pass the chosen id as style to generate_image. It lacks an explicit 'when not to use' or direct alternative naming for cases like video or editing, so it falls just short of a 5.

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

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

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value beyond these by stating it is 'Free' and that 'nothing is reserved or started,' which clarifies that no quota is consumed and no side effects occur. This contextualizes the read-only nature with operational implications, exceeding what annotations alone convey.

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

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

The description is two sentences with zero waste. The primary purpose (exact credit cost) is front-loaded, followed by the use case and a critical behavioral note (free, nothing reserved). Every word contributes to agent decision-making.

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 conditional parameters and no output schema, the description covers the essential context: what it does, when to use, and that it is non-committal. It does not detail return structure, but the mention of 'balance and plan eligibility' gives a hint. Given the annotations and schema coverage, the description is sufficiently complete 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 coverage is 100%, so all five parameters (tool, model, duration, resolution, with_image) are already fully described in the schema. The description does not add any parameter-specific guidance or clarify conditional usage (e.g., duration only for generate_video), so it provides no extra semantic value beyond the schema. 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 provides the exact credit cost for three specific tool calls (generate_image, edit_image, generate_video) along with the caller's balance and plan eligibility. The verb 'quote' and resource are specific, and it distinguishes itself from executing those calls by saying 'before making it.' It also implicitly differentiates from get_credits by including balance and plan eligibility, not just cost.

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 'Use it whenever price or budget comes up instead of estimating,' which is a clear when-to-use directive. It also notes 'Free; nothing is reserved or started,' indicating it is a non-committal query. However, it does not name alternative tools or explicitly state when not to use it, leaving some inference to the agent.

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