x402image

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

Annotations indicate readOnlyHint=false and openWorldHint=true. The description adds transparency by disclosing cost ($0.005 per call) and output characteristics (short-lived signed URL). No contradiction with annotations.

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

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

The description is concise (four sentences) and front-loaded with the main purpose. Every sentence adds value: purpose, cost, input, parameters, output. No wasted words.

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 simplicity (2 parameters) and no output schema, the description covers all necessary aspects: input source, parameter details, pricing, and output format. It is complete for agent usage.

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 description explains both parameters (format with allowed values, quality with range and default) and the requirement that at least one is needed. This adds significant meaning beyond the schema, which only provides type and constraints. Schema description coverage is 50%, but the description compensates fully.

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's purpose: 'Convert format and/or compress an image.' This specific verb+resource combination effectively distinguishes it from siblings like resize, upscale, and remove_background.

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 specifies input via source URL, required parameters (format and/or quality), and output as a short-lived signed URL. While it doesn't explicitly name alternatives, the context of sibling tools makes the use case clear. However, no explicit when-to-use or when-not-to-use guidance is provided.

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?

With readOnlyHint=false, the description adds critical behavioral details: it's a paid call, pricing is sum of ops' prices, mentioning 402 error for missing payment, and output is a short-lived signed URL. This goes beyond annotations, though rate limits or idempotency are not covered.

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 extremely concise: three sentences cover purpose, pricing, input format, and output. It uses clear structure with 'Input:' and 'Output:' labels, making it easy to parse. Every sentence is essential.

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 no output schema, the description adequately describes output as 'short-lived signed URL'. It covers input, process, pricing, error handling, and how to discover ops. Could briefly note that order matters, but 'ordered pipeline' implies it.

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% (baseline 3). The description adds value by clarifying 'source' as a public https:// URL, 'steps' as ordered array with example, and directing to service_info for op-specific params. This enriches the schema-defined meaning.

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 defines the tool: it applies an ordered pipeline of image ops in a single paid call. It distinguishes itself from sibling atomic tools (optimize, resize, etc.) by being a composite pipeline, which is explicitly stated.

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 advises calling without payment for a quote and to use service_info for available ops and prices, providing context for tool selection. However, it does not explicitly exclude use cases (e.g., for single ops, use atomic tools).

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

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

The description discloses the AI model, cost, input format, optional parameter, and output as a short-lived signed URL. Annotations are minimal (readOnlyHint=false, openWorldHint=true) and are not contradicted. Some gaps (e.g., error handling) but overall good transparency.

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 concise sentences with key info front-loaded. Every sentence adds value: core function, cost, input, parameters, output format. No unnecessary words.

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 2 parameters, no output schema, and minimal annotations, the description covers the essentials well. It explains the tool's purpose, input, optional param, and output. Minor omissions (URL duration) but overall 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 50% (only source described). The description adds meaning for the 'background' parameter ('optional fill color... omit for transparent cutout'), which is not in the schema. This compensates for the low schema coverage.

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 'Remove an image's background, isolating the subject (BiRefNet AI segmentation).' It uses a specific verb and resource, and distinguishes itself from sibling tools which are all different operations (optimize, resize, etc.).

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 provides clear context for usage (cost, input requirements, optional background fill) and implies usage for background removal. However, it does not explicitly state when not to use or compare to alternatives, though siblings are unrelated.

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 cost per call and output as short-lived signed URL, adding context beyond annotations which already indicate non-read-only behavior.

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?

Concise and front-loaded with main purpose; could be slightly more structured but 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 moderate complexity and missing output schema, the description provides comprehensive coverage of parameters, constraints, and output type.

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?

Explains each parameter's meaning (e.g., fit options, gravity purpose, background for pad) beyond the schema, which only describes source.

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 verb (resize/crop) and resource (image), and distinguishes from sibling tools like optimize or upscale.

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 input and parameter guidance, but does not explicitly state when to use this tool vs. alternatives like upscale or remove_background.

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?

Adds value beyond annotations by stating it's free, requires no payment/input, and returns data; no contradictions with readOnlyHint.

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 concise sentences, front-loaded with key info ('Free'), no wasted words.

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 no parameters and no output schema, description fully explains what it returns and its purpose.

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?

No parameters, so schema coverage is 100%; description adds no parameter details needed, but baseline for 0 params is 4.

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?

Clearly states it returns service metadata and list of paid image tools with prices, distinguishing it from action-oriented sibling 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 advises to call first for discovery, but does not explicitly list when not to use alternatives; context is clear though.

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?

Although annotations are minimal (only readOnlyHint=false and openWorldHint=true), the description adds valuable behavioral context: pricing ($0.02 per call), the model used (ESRGAN), and output nature (short-lived signed URL). This goes beyond what annotations provide.

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 extremely concise: two sentences plus a clear input/params/output bullet. The purpose is front-loaded, and every sentence adds value without redundancy.

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 moderate complexity (2 params, nested object, no output schema), the description covers input format, parameter constraints, pricing, and output format. It lacks comparison with sibling tools, but overall it provides sufficient context for an AI to use 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 description explains that 'width and/or height' are target pixels and that at least one is required, which is not explicitly stated in the schema (the params object is required, but individual dimensions are not). Schema coverage is 50%, and the description compensates well.

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's main function: 'Upscale an image with AI super-resolution (ESRGAN) for sharper enlargement.' This is a specific verb ('upscale') and resource ('image') with a clear goal, and it distinguishes from sibling tools like 'resize' by specifying AI super-resolution.

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 mentions input/param/output format and pricing but does not provide explicit guidance on when to use this tool vs. alternatives (e.g., 'resize'). It lacks statements like 'Use this for high-quality enlargement; use resize for simple dimension changes.'

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