image-processing

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

No annotations are provided, but the description explains it fetches an image and returns size in bytes. It does not disclose error handling, side effects, or that it is read-only, which would be helpful.

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 short and front-loaded with the purpose. The example response adds clarity. However, the first sentence is somewhat redundant with the title, and the 'Always free' could be integrated.

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 tool with one parameter and no output schema, the description covers purpose, parameter format, and an example response. It does not explicitly address error conditions but is reasonably 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 input schema covers 100% of the single parameter with a detailed description. The tool description adds minimal extra value beyond the schema, so baseline 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 analyzes an image from a URL or base64 and returns its size in bytes, which distinguishes it from sibling tools like compress_image or crop_image that modify images.

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 implies use when needing image metadata (size), and notes it is always free. However, it lacks explicit when-not-to-use or mention of alternative tools for other analysis.

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?

Lacks details about lossy vs lossless behavior, quality degradation trade-offs, or that metadata is lost unless 'strip' is false. No annotations exist to compensate. The response examples are present but not descriptive of 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?

The description is short but cluttered with multiple example response blocks that repeat similar information, making it less concise. Front-loading is minimal.

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?

No annotations, no output schema, and the description omits important context like quality reduction implications, size reduction expectations, and explicit output handling. Incomplete for a compression tool.

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 covers 80% with good parameter descriptions. The tool description adds minimal value beyond listing supported formats, but the schema already 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 name and description clearly indicate compression via re-encoding with quality/format options, and list supported formats. It distinguishes from siblings like resize_image and convert_image by focusing on file size reduction, but could more explicitly differentiate from convert_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?

No guidance on when to use compress_image versus alternatives (e.g., convert_image, image_pipeline). The description does not provide context for selection among sibling 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?

No annotations provided, so description bears full burden. It details conversion behavior (formats, quality, strip, lossless), delivery methods (inline, put_url, callback), and response types (200 with binary). It also mentions security aspects (SSRF protection, no credential storage). However, it does not explicitly state that the original image is unchanged.

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 well-structured with a summary line, bullet-like list of options, and response examples for each content type. It is front-loaded but includes repetitive example responses. Still, it efficiently conveys essential information without unnecessary fluff.

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 parameters, no output schema, no annotations), the description covers all parameters and responses in detail. The only minor gap is not specifying the default delivery mode (likely inline) when delivery is omitted, but overall it is highly 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 83%, and the description adds meaningful context beyond field descriptions: quality range (1-100) mapping to libvips Q, lossless only for webp, strip metadata, and detailed delivery options with security notes. Every parameter is well-explained.

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 'Convert image format' and lists supported formats (jpeg, png, webp, tiff, gif). This distinguishes it from sibling tools like compress_image or resize_image, making the purpose 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 implies usage for format conversion but does not explicitly compare with siblings or state when to use this tool versus alternatives (e.g., compress_image, image_pipeline). No 'when to use' or 'when not to use' guidance is given.

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 no annotations, the description carries full burden for behavioral disclosure. It states the basic action but omits traits such as side effects (e.g., does it modify the original?), auth requirements, or error cases. The response section hints at output format but does not address safety or limitations.

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 core description is concise and front-loaded. However, the inclusion of a lengthy responses section with multiple examples adds verbosity without critical additional insight, slightly reducing conciseness.

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, the description covers core purpose and response format. However, it lacks details on coordinate validation, error handling, and constraints relative to the source image, leaving gaps for an agent to handle edge cases.

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 high (86%), so baseline is 3. The description adds minimal extra meaning beyond the schema: it mentions top-left corner and dimensions, but the schema already defines x, y, width, height clearly. The delivery parameter is left to 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 clearly states the tool's purpose: 'Crop an image. Extract a rectangular region from an image.' It specifies the verb (crop) and resource (image), and distinguishes itself from sibling tools like resize_image or analyze_image by its specific action.

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 implies when to use (when you need to crop an image), but lacks explicit guidance on when not to use or alternatives among sibling tools. No exclusions or comparisons are provided, leaving the agent to infer usage context.

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?

No annotations provided, so description carries burden. It implies a read operation but does not explicitly state it is non-destructive or any behavioral traits.

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?

Short and to the point, but could be better structured with explicit labeling of response content.

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

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

Adequate for a zero-parameter info tool, but lacks details about possible response structure or any prerequisites.

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 exist, and schema coverage is 100%. Description does not need to add parameter meaning, and it correctly omits such info.

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 it returns supported formats and options, which is a specific resource. It distinguishes from sibling image processing tools by focusing on information retrieval.

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?

Implied usage for getting format info before image conversion, but no explicit guidance on when to use or not use, nor alternatives.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It discloses key behaviors: the image is fetched once, operations are applied sequentially, and max 10 operations. However, it does not mention failure handling, rate limits, authentication needs, or what happens if the source is invalid.

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 structured with a header and bullet-like list, but it includes verbose response examples with multiple Content-Type variations. The response section could be more concise and the 'Example Response' with 'string' is unclear. Overall, it is adequately sized but has some 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 three parameters (one complex nested object) and no output schema, the description provides basic operational context but lacks details on how to choose delivery mode, error scenarios, or the exact response format. The response section attempts to cover output but is confusing.

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 67% (source and operations have descriptions in schema). The description adds the constraint 'Max 10 operations per pipeline' and reiterates sequential application, which is already in the schema. It does not describe the delivery parameter or its modes, so the added value is minimal.

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: 'Run a multi-step image pipeline' and lists the specific operation types that can be chained. It distinguishes itself from sibling tools (single-operation tools like resize_image, compress_image, etc.) by emphasizing the chaining of multiple operations.

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 implies when to use this tool—when multiple operations are needed in sequence—and provides context by naming sibling tools. However, it does not explicitly state when not to use it (e.g., for single operations) or provide alternatives, but the sibling list serves as implicit guidance.

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

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

Discloses delivery modes and security details, but the response examples are confusing ('string' instead of actual binary) and error cases are omitted. No annotations provided.

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 and structured, but the response section is verbose with repetitive examples that add little value.

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 main usage but lacks error handling, edge cases, and a clear specification of the return type for inline delivery.

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?

Adds context beyond schema by explaining the relationship between scale parameters and delivery options, though schema already covers 83% of parameters.

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 'Resize an image' and explains the scaling parameters (scale, scale_x, scale_y), distinguishing it from siblings like crop_image or compress_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 guidance on when to use uniform vs independent scaling and output formats, but lacks explicit when-not-to-use or prerequisites.

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