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?

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotent, so the safety profile is covered structurally. The description adds non-obvious behavioral context the annotations can't: credit cost per clip, the free first H3 Max Turbo render, and the no-silent-substitution policy. It stops short of describing what a successful call returns (job id vs. finished asset) or that generation is asynchronous.

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?

Purpose and default model are front-loaded, followed by model-name mappings and the pre-purchase alternatives. It is a bit long and redundantly repeats the shortcut mapping that the model parameter schema already contains verbatim, which is the main thing that doesn't fully earn its place.

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

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

Given seven parameters, no output schema, and existing annotations, the description covers selection, cost, and prerequisite workflow well. The remaining gap is that it never indicates generation is asynchronous or points to check_generation, so an agent must infer how to retrieve the 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?

Schema description coverage is 100%, so the schema already documents every parameter including the friendly-name shortcuts, durations, and resolutions. The description largely restates the model mapping already present in the schema's model field, adding the user-facing naming intent but little new syntax. Baseline 3 applies when the schema does the heavy lifting.

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 ('Generate an AI video') and enumerates the concrete model options, which immediately separates it from generate_image and edit_image. An agent knows exactly what this tool produces 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?

Explicitly routes to alternatives: 'Call list_models or quote_generation first when the user wants to review models and costs before spending credits.' It also gives a rule for the retired Seedance 1.5 Pro (say so, suggest Seedance 2.0 Mini rather than switching silently), which is exactly the when/when-not guidance the dimension asks for.

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?

Annotations already declare readOnlyHint and destructiveHint=false, and the description reinforces this with 'Free: never starts a generation.' It also discloses what it returns (exact account prices, prompts, budget guidance, output checks), adding value beyond 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?

Front-loaded with the workflow definition, then usage and cost disclaimers. Three sentences plus a short fragment; every sentence earns its place, though the 'Free: never starts a generation' fragment is slightly clipped.

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 planning tool with no output schema, the description covers what is returned (prices, prompts, budget guidance, output checks) and how image_url absence is handled. Nothing needed 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?

Schema coverage is 100%, so the schema already documents all six parameters thoroughly. The description mentions budget guidance and image directions but adds no syntax or format details beyond what the schema provides.

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: 'Plan a complete product-photo workflow' with two image directions, user selection, and a short video. This clearly separates it from siblings like generate_image, generate_video, and quote_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?

Explicitly says 'Use before making product ads or product videos,' giving a clear usage context. It doesn't name a specific sibling alternative for comparison, but the sequencing guidance 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, 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.