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?

The description explicitly claims 'the original is untouched' and 'the result is a new image', while annotations declare destructiveHint=true. This is a direct contradiction about the tool's behavioral impact. The description does add useful context about Claude Imagine credits, but the contradiction is a serious transparency failure.

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

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

Three sentences, each earning its place: the first defines the operation and cost, the second specifies input and output behavior, and the third gives a critical prompt tip. The most important information is front-loaded and there is no filler.

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 four-parameter tool with full schema documentation, the description covers the core use case, key parameter behavior, and output semantics ('result is a new image'). The main gap is the unresolved contradiction with the destructiveHint annotation, which prevents fully trusting the description as complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by specifying that image_urls should be the 'full-resolution URL' from an earlier generation and by advising prompt authors to state what must stay the same. This gives practical parameter-level guidance that the schema alone does not fully convey.

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 ('Edit an existing image with a text instruction'), names the resource ('existing image'), and clarifies the output ('result is a new image, the original is untouched'). This clearly distinguishes edit_image from siblings like generate_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 makes clear this is for editing existing images, implying generate_image is for new creations, and gives practical usage guidance: pass the full-resolution URL and state what must stay the same. It does not explicitly name sibling alternatives or state when not to use it, but the context is sufficiently 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 convey readOnlyHint=false, idempotentHint=false, and destructiveHint=true, so the description is not required to repeat those. It adds valuable context by noting that generation consumes 'Claude Imagine credits' and that the result returns an inline image plus a full-resolution URL. This gives the agent useful expectations about cost and response shape.

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 no filler. The core action is front-loaded, the return behavior is stated, and the sibling alternative is placed at the end. Every sentence earns its place and the structure is easy to scan.

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

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

For a tool with 3 parameters, full schema coverage, and no output schema, the description is complete enough: it states the action, the resource consumed, the return value, and the key alternative. Nothing needed to call the tool correctly is missing. The schema covers the remaining model and aspect-ratio choices.

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 all three parameters are already documented with descriptions, enums, and defaults. The tool description does not need to add parameter-level detail. The model description in the schema already includes guidance about defaults and trade-offs, so the description adds no extra semantic value here.

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

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

The description clearly states the action: 'Generate an AI image from a text prompt.' It also distinguishes itself from the closest sibling, edit_image, by explicitly directing changes to existing images to that tool. The purpose is unambiguous and easily selectable from the sibling list.

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

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

The description explicitly tells the agent when not to use this tool: 'To change an existing image, use edit_image.' This provides a clear alternative and a condition for choosing it. The rest of the sibling tools are also clearly differentiated by the focus on image generation from a prompt.

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 indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds context that it involves spending credits (implied by the advice to review costs before spending credits), and clarifies default behavior (defaults to grok-imagine only when user didn't name a model). This goes beyond annotations by warning about cost implications, though it doesn't explicitly state the exact 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?

The description is three sentences, front-loading the core purpose, then providing mapping details and two actionable instructions. Every sentence carries relevant information with no redundancy, making it 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 tool with six parameters, three enums, and a destructive annotation, the description covers model selection, default behavior, and cost caution. It leaves out details like asynchronous execution or return values, but since there is no output schema and the parameter schema is complete, the description is reasonably complete. It could mention that generation may take time or return a job reference, but that's not critical.

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 each parameter is well documented. The description adds the crucial rule 'Never omit model when the user named one' and clarifies the default fallback, which is not directly in the schema. This gives the agent deeper understanding of model handling beyond the enum values, so it adds value above 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: generating an AI video, and lists the supported model families (Grok Imagine, Seedance, Veo, Kling). It clearly distinguishes from the sibling generate_image by focusing on video, and the verb 'generate' is precise. The mapping details further clarify what the tool does.

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 guidance: call list_models when the user wants to review models and costs before spending credits, and never omit model when the user named one. This directs the agent to the appropriate sibling for cost review and sets a clear rule for model handling, making usage conditions 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 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?

Beyond the readOnly/idempotent annotations, the description discloses that the call is free, reserves nothing, and starts nothing. This is important behavioral context for a pricing tool and is not redundant 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 short sentences each carry distinct value: what it returns, when to use it, and its side-effect profile. The key purpose 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 quote tool with no output schema, it describes the returned values (cost, balance, plan eligibility), the applicable tools, and the safety profile. Parameter constraints are fully covered by the schema, and annotations cover side-effect safety.

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 explains all five parameters. The description adds no parameter-level semantics beyond listing the same tool names in the enum.

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 function: returning the exact credit cost for a specified generation call before execution, plus balance and plan eligibility. Naming generate_image, edit_image, and generate_video as the priced operations differentiates it from the sibling generation and balance tools.

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

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

It explicitly tells the agent to use this tool whenever price or budget comes up rather than estimating. It does not, however, name alternative tools or exclusion conditions, such as when to use get_credits for balance-only queries.

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