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

Annotations already disclose the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the description isn't carrying that burden. It does add meaningful context that the output is a transparent-background composite rather than an in-place edit, but it says nothing about overwrite behavior, failure modes, or the fact that offset/blur are pixel-space operations subject to image size.

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?

A single twelve-word sentence with zero filler, leading with the operation and ending with the output characteristic. Nothing is redundant against the title or schema.

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 an output schema present and full parameter documentation, the description needn't explain return values or argument formats. What it does convey — implicit subject segmentation plus transparent-background shadow compositing — covers the surprising behavior. Minor gap: no hint about behavior when segmentation finds no subject, or that output_path controls whether an existing file is overwritten.

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%, and every parameter (offset_x/y, blur_radius, shadow_color, output_path, image_path) is documented with type, default, and units in the schema. The description adds no parameter-level meaning beyond that, which is the expected baseline 3 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?

The description states a specific compound action: segment the subject out of the image and render a drop shadow behind it on a transparent background. That 'cut out the subject' framing also implies built-in background removal, which is the key detail an agent needs to distinguish this from siblings like blur_background or color_background. It stops short of naming an alternative explicitly, so it isn't a 5.

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?

There is no guidance on when to choose add_shadow over remove_background (which also produces a transparent cutout) or create_mask. No prerequisites, no exclusions, no mention of what happens on images without a detectable subject. The agent must infer the use case entirely from the verb.

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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the description is not carrying that burden. It does add meaningful semantics — the subject stays sharp, so background blur implies subject detection rather than a uniform blur — but it says nothing about what happens if no subject is found, whether the source file is modified, or that a new file is produced.

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?

One sentence, front-loaded with the goal effect ('keep the subject sharp'), zero filler. Nothing could be removed without losing meaning.

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 deterministic image transform with full schema coverage, complete annotations and an output schema, the description covers the essential what-and-how-it-looks. The only remaining gap is failure/edge behavior when subject detection does not apply.

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% and all three parameters (image_path, radius, output_path) have their own descriptions including ranges, defaults and format constraints. The description adds nothing about radius tuning or output naming, so 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?

States a specific verb and effect: blur the background while keeping the subject sharp, which cleanly separates it from remove_background, color_background and gradient_background as an effect choice. It does not explicitly name or contrast a sibling, so a 4 rather than a 5.

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 parenthetical '(portrait-style bokeh)' implies the intended use case (subject-isolating portrait imagery) but there is no explicit when-to-use, when-not-to-use, or routing signal against the sibling background tools. Usage must be inferred from the effect description rather than stated.

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=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds only the bare transformation semantics and says nothing about how alpha/transparency in the source image is handled, whether the subject is segmented first, or whether any input file is touched — the details that actually matter for a background-replacement operation.

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?

A single front-loaded sentence with zero filler. It is efficient, but the length is also the source of the definition's thinness rather than a sign of completeness.

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?

An output schema exists and the input schema is fully annotated, so return values and parameters need no explanation. Still, for an image mutation tool the description leaves open how the subject/background separation happens and whether transparency is preserved — relevant gaps given no destructive/segmentation context is supplied elsewhere.

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 color formats, accepted image types, and the output_path default are all documented in the schema. The description adds no parameter meaning beyond that, which is the correct baseline when the schema does the work.

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?

A specific verb+resource ('Replace the background') with a qualifier ('solid color') that distinguishes it from blur_background and gradient_background without naming them. An agent can pick it apart from siblings on the fill type alone, though it never states that it also differs by not removing the subject first.

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 adjective 'solid' implicitly signals when this is the right choice over gradient_background or blur_background, but there is no explicit when-to-use statement, no prerequisites, and no named alternatives. Usage is inferable rather than stated.

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 that this is a non-read-only, non-destructive, non-idempotent, open-world operation. The description adds the useful output convention (white subject, black background), but does not disclose file-writing behavior, overwrite semantics, or what happens when the model fails to find a subject.

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?

A single front-loaded sentence that conveys the action, the output type, and the color convention without any redundant or filler text.

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 simple three-parameter schema with full descriptions, existing output schema, and annotations covering safety and mutability, the description is nearly complete for correct invocation. Its main gap is the lack of sibling differentiation, which is primarily a usage-guidance concern.

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 fully documented in the schema. The description adds no parameter-specific detail beyond the image-level output convention, so the 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 states a specific verb and resource ('Create a black-and-white subject mask') and defines the output convention (white = subject, black = background), which clearly distinguishes it from sibling background-editing tools. It does not explicitly contrast itself with alternatives like remove_background, so it falls short of a 5.

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 says what the tool does but gives no when-to-use guidance, no exclusions, and no mention of when an agent should choose create_mask over remove_background, blur_background, or other sibling tools. The usage context is only implied by the tool name and output definition.

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 openWorldHint, so the safety profile is covered. The description adds genuinely new context that annotations cannot express: the call itself does not consume quota, which is the key fact an agent needs before making a budget-conscious decision.

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 short sentences, front-loaded with what is returned and followed by the operational cue. Minor sloppiness: "Free: does not use quota" is terse to the point of ambiguity about whether "Free" means a plan tier or zero cost.

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?

An output schema exists, so return values need no explanation, and with no parameters the remaining burden is just purpose and cost semantics, both covered. Slightly more detail on what the plan/limit fields look like would push it higher.

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 takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate and no ambiguity is introduced.

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: show the FAPIHUB plan, its limits, and used/remaining request counts. It is unmistakably distinct from the sibling image-processing tools (remove_background, create_mask, etc.), which are all content operations while this is a quota/meta lookup.

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 an explicit trigger: "Check it before processing many images," and notes that calling it is free of quota cost. It does not name alternatives or exclusions, but none are needed since no sibling overlaps this purpose.

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 non-read-only, non-destructive, open-world, and there is an output schema for return values. The description adds only the gradient direction, and says nothing about whether the source image is modified vs. a new file written (the schema's output_path default implies a new file, but the word 'Replace' is ambiguous), nor about alpha handling in the colors.

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?

A single front-loaded sentence with no filler; every clause carries meaning. It is arguably too terse for a mutation tool rather than padded, so no penalty for waste.

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 annotations, a full schema and an output schema, the remaining gaps are the semantics of alpha in the color values (how transparency composites with the original background) and confirmation that the input file is left intact. Neither is stated, so the definition is minimally adequate rather than 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 description coverage is 100%, so formats, size limits and output naming are already documented. The description does contribute one piece of meaning the schema lacks – that top_color maps to the top of the gradient and bottom_color to the bottom – but that alone is a modest addition over the schema baseline.

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 concrete verb+resource ('Replace the background') plus the specific effect ('vertical gradient from top_color to bottom_color'), which implicitly separates it from color_background, blur_background and remove_background. It doesn't name a sibling explicitly, so it stops short of a 5.

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?

Use is only implied by the operation itself; there is no statement of when to pick this over color_background (solid fill) or when not to use it, and no preconditions such as needing an existing background to replace.

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 the safety profile (destructiveHint=false, openWorldHint=true, idempotentHint=false), and the description adds that the result is a transparent PNG cutout. It does not disclose that a file is written to disk, whether an existing file at output_path is overwritten, or why the operation is non-idempotent — context the agent would need before running it on a real path.

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?

A single front-loaded sentence that names the action and the exact output format with no filler. Nothing is redundant or buried.

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?

An output schema exists, so return values need not be explained, and the description correctly covers the transformation and its artifact. The only real gap is routing versus the mask/background-altering siblings, which matters given six adjacent tools.

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 image_path, output_path and the model enum are already documented in the schema. The description contributes nothing extra about model selection trade-offs or format constraints, 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?

States a specific verb (remove) and resource (background) plus the concrete output artifact: a transparent PNG cutout of the subject. This is clearer than a bare 'remove background', but it never addresses the closest sibling, create_mask, which an agent could reasonably confuse with a subject-cutout operation.

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?

There is no when-to-use or when-not-to-use guidance, and no alternative is named. With six siblings including create_mask, blur_background, color_background, gradient_background and add_shadow, the agent is left to infer that this tool is the one that isolates the subject rather than altering the background.

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