image-processing

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

With no annotations provided, the description carries the full burden and does a solid job: it discloses that the operation is free, that dimensions may be omitted if the header cannot be read, that C2PA manifests are reported but not validated, and that the tool fetches from URL or base64. It does not cover auth/privacy caveats, but for this tool the disclosed limitations are meaningful and relevant.

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 opens with a clear one-line purpose and uses a structured responses section for practical detail. It is moderately sized and front-loaded, though the example response mentions only two of the many documented output fields, which is slightly misleading and prevents a perfect score.

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 one-parameter tool with no output schema, the description is fairly complete: it names the main metadata fields, the cost output, the C2PA behavior, and a key failure mode (unreadable header). A minor gap is that it does not enumerate which vision models are considered, but this is not essential for invoking the 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?

The input schema already documents the single 'source' parameter with good coverage, including public URL, base64, and data URI formats. The description adds little beyond repeating 'URL or base64' and does not enrich the schema's meaning, so the 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 uses a specific verb ('Fetch... and return') with a clear resource ('image metadata') and enumerates concrete outputs: size, pixel dimensions, source format, vision model token costs, and C2PA presence. This clearly distinguishes analyze_image from sibling transformation tools like compress_image, resize_image, and crop_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 implies its use case by listing what it returns—especially the free token cost estimate for vision models—and the 'Always free' note provides practical selection context. However, it does not explicitly state when not to use it or name alternatives such as estimate_cost, so it falls 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?

With no annotations provided, the description bears the full burden of behavioral disclosure. It clearly states the tool is a mutation (write) operation, describes the free-tier quota behavior (X-Pig-Billed: 0 if output not smaller), mentions the surcharge for quality_target searches, and notes the enhancement processing order. However, it does not disclose whether the input source is stored, how long results are available, or rate limits. Given the complexity, it covers the most critical behavioral traits well.

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 block of text with clear sections: purpose, format support, quality modes, free-tier rule, enhancement order. It uses clear sentences without redundancy. However, it could be more structured (e.g., bullet points for formats or modifiers). Length is justified by the tool's complexity (10 params, 3 delivery modes). 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 complex image processing tool with 10 parameters, multiple output formats, and delivery modes, the description provides substantial context beyond the schema. It explains the quality_target workflow, enhancement ordering, free-tier behavior, and format support. No output schema exists, but the description notes responses are binary images with Content-Type headers. Missing: explicit details on delivery mode semantics (inline vs PUT vs callback) — these are in the schema but the description doesn't summarize trade-offs. Overall, strong coverage for the complexity.

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 high (90%), so the baseline is 3. The description adds context by listing supported formats and explaining the quality_target workflow (SSIM target, formats supported, surcharge). It also mentions the enhancement order and free-tier behavior. However, much of the param info (q range, strip meaning, format list) is already in the schema. The description does not add value for all params (e.g., source, delivery remain schema-only). It compensates enough to stay at 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?

The description starts with a powerful verb ('Compress') and noun ('image'), immediately followed by the mechanism ('Re-encode...to reduce file size'). It lists supported formats and distinguishes the two quality modes (q vs quality_target). The siblings include convert_image, resize_image, crop_image — this description clearly separates compression from those transformations.

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 explains when to use q vs quality_target (mutually exclusive, latter for SSIM-guided size reduction) and mentions optional enhancement modifiers (denoise, equalize, sharpen) and their processing order. It also notes that free-tier quota is not consumed if the output isn't smaller. However, it doesn't explicitly say when to prefer this over convert_image or optimize_for_vision, nor does it state when not to use it (e.g., for lossless color space conversion).

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 covers delivery methods (inline, put_url, callback), security details (credentials never stored, HMAC signatures), surcharges for quality_target, and the order of modifier application. However, it does not mention idempotency, rate limits, or whether the original source is modified.

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, starting with a brief summary followed by detailed explanations of options and delivery modes. The inclusion of response headers and example outputs is helpful. While slightly lengthy, each sentence provides necessary context, and it avoids 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?

For a tool with 12 parameters, multiple delivery modes, and optional enhancement modifiers, the description covers most aspects comprehensively. It explains quality_target behavior, delivery authentication, and modifier order. Minor gaps include lack of explicit error response documentation, but the examples and schema cover the expected output.

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?

Despite 92% schema coverage, the description adds significant value beyond the structured schema. It explains the relationship between q and quality_target, the mutual exclusivity with lossless, the modifier pipeline order (denoise -> equalize -> op -> sharpen), and the meaning of the quality search headers. This helps the agent understand parameter interactions.

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 all supported formats (jpeg, png, webp, tiff, gif, avif). It distinguishes convert_image from sibling tools like compress_image, crop_image, resize_image, etc., by focusing on format conversion.

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 explains what the tool does in detail but does not explicitly provide guidance on when to use this tool versus alternatives such as compress_image or optimize_for_vision. The context of siblings implies it is for format conversion, but no direct comparisons or exclusion criteria are 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. It discloses mutual exclusivity of modes, smart crop clamping, trim header reporting, and enhancement order. However, it omits major behavioral aspects like the delivery parameter (inline vs put_url vs callback) and autorot EXIF handling, which are important for agent usage.

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 followed by mode details and enhancements. However, the response examples are redundant and uninformative (repeated 'string' JSON), adding unnecessary length. Could be more concise.

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 complexity (14 parameters, no output schema), the description covers modes and enhancements but fails to explain the delivery parameter, autorot behavior, or error responses. The response section is minimal and does not clarify the return format beyond 'binary' and Content-Type examples.

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 93%, so baseline is 3. The description adds value by grouping parameters into modes, clarifying mutual exclusivity, and specifying enhancement application order. It also explains gravity options and trim threshold context beyond 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 'Crop an image' and explains the three mutually exclusive modes (manual, smart crop, trim). It uses a specific verb-resource pair and distinguishes the tool from siblings like resize or compress by focusing on region extraction.

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 when to use each mode (e.g., manual for explicit coordinates, smart crop for automatic window picking, trim for removing borders). However, it does not explicitly compare to sibling tools or state when not to use crop_image, leaving the selection largely implicit.

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 explicitly states the tool is free, does not fetch or process anything, returns exact USD price, and explains behavior for free tier and compress operations that do not shrink the file. The response example further enriches transparency by showing fields like free_tier_remaining. It does not contradict any provided metadata.

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 relatively concise, with a few clear sentences followed by a detailed example response. While the example response is lengthy, it adds value by clarifying the return structure. Overall, the description is well-structured and avoids unnecessary verbosity, though the example could be trimmed slightly.

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 (5 parameters, 2 required, nested objects) and no output schema, the description is highly complete. It explains when to use it, how to use it with headers, behavior under free tier and compress, and includes a full response example with all fields. Nothing essential is missing for an AI agent to understand 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?

Schema description coverage is 100%, so baseline is 3. The description adds little beyond the schema: it mentions that only 'avif' changes price for format, which is already in the schema. No additional parameter context or examples are provided that significantly enhance understanding beyond what the schema already communicates.

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 estimates the price of an operation, using a specific verb ('Estimate') and resource ('price of an operation'). It distinguishes itself from sibling processing tools (e.g., compress_image, convert_image) by being the only cost estimation tool, and explicitly mentions it does not fetch or process anything.

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 guidance on when to use: 'Use it before paying' and explains how to integrate with X-Max-Cost-USD to limit costs. It also notes that the list price is returned even if the request would be free. However, it does not explicitly mention situations where this tool should not be used or suggest alternatives, though siblings are distinct enough.

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 the transparency burden. It clearly states that the tool returns supported formats and options, which implies a read-only query operation. The absence of side effects or side-channel behavior is adequately conveyed for a tool of this simplicity.

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 somewhat redundant: 'Get supported formats and options' and 'Returns supported output formats and their configurable options' restate the same idea. The Responses section adds standard HTTP status detail, but the first two sentences could be merged into one efficient line.

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, parameterless query tool, the description is reasonably complete. It states the purpose and the return value. Although there is no output schema, the description explains what is returned (supported formats and options). The sibling context clarifies that this is a non-action informational tool, making the overall picture adequate.

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 accepts zero parameters, so the input schema provides no semantic content. The description correctly adds no parameter information because there is none to add. Per the rubric, a 0-parameter tool receives a baseline of 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?

The description clearly identifies the tool's function: it gets supported formats and returns their configurable options. The verb 'Get' and the specific resource 'supported formats and options' make the purpose unambiguous, and it is distinct from sibling tools that perform image transformations.

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?

Usage context is implied: given the sibling tools all perform image operations, this is evidently a query/utility tool for retrieving format information. However, there is no explicit guidance on when to use it instead of alternatives, nor any mention of prerequisites or exclusions.

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 are provided, so the description carries the full burden. It discloses key behaviors: image is fetched once, operations apply sequentially, max 10 operations, and response content types. It omits side effects like writing to PUT URLs or callbacks, but covers essential processing behavior well.

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 and front-loaded with the core behavior, followed by structured response examples. No wasted words; the separation of processing logic and responses aids readability.

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?

The tool is complex with delivery modes and multi-step processing, and the description covers the pipeline flow and limits. Missing details like error cases and delivery side effects are partly covered by the schema, making the description adequate for selection and invocation.

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%, with detailed descriptions for source and operations. The description restates operation types but adds little beyond the schema. It does not clarify delivery semantics, which are complex but already well described in 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?

Description clearly states 'Run a multi-step image pipeline' and details that it chains operations (resize, compress, convert, crop) in sequence. This distinguishes it from sibling single-operation tools like resize_image and 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?

The description implies use for multi-step workflows by explaining sequencing and a 10-operation limit. It doesn't explicitly contrast with single-operation siblings, but the use case is evident from the 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?

With no annotations, the description carries the full burden and does well: it discloses that resizing alone saves bytes/latency but not tokens, that max_tokens behaves differently across Claude/OpenAI/Gemini, and that in-budget images are returned untouched and free (X-Pig-Billed: 0). It does not discuss rate limits or auth, but those are less central here.

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 main paragraph is front-loaded and dense with meaningful info about provider-specific behavior and token economics. The Responses section is slightly redundant with repeated Content-Type headers and 'string' placeholders, but it does provide return-type hints in the absence of an output 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?

Given no output schema, the description explains the outcome (resized image, token cost report, free/billed header) and includes response examples. The schema covers the remaining parameter semantics well. Minor gap: it does not detail error cases beyond the schema's note on unknown model IDs.

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 83% and parameter docs are already detailed (e.g., max_tokens and target_model). The description reinforces max_tokens behavior but adds little beyond the schema's own parameter descriptions, 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 clearly states the tool resizes an image for a vision model and reports its token cost before and after. This specific verb+resource+scope distinguishes it from sibling tools like resize_image or compress_image, which do not include model-specific token reporting.

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 provides clear context: use this when preparing an image for a vision model, and explains when to pass max_tokens to trade resolution for tokens. However, it does not explicitly name alternatives or state when not to use this tool versus resize_image or compress_image, so it lacks explicit exclusions.

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 key behaviors without annotations: metadata stripping (including C2PA), no upscaling, surcharge for quality_target, and the 'free if not smaller' rule. It also explains security aspects of PUT/callback delivery (no credential storage, HMAC signing, SSRF whitelisting).

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, well-structured paragraph that front-loads the purpose and systematically covers options, costs, and security. It is dense but not verbose, conveying substantial information efficiently.

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?

The description covers all major aspects: purpose, delivery modes, quality controls, metadata handling, cost, and response behavior (including binary output and free condition). It is complete given the tool's complexity and the provided schema, with no significant gaps.

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?

It enriches schema descriptions with contextual details: format transparency handling, delivery mode security, and cost implications (same price as convert, flat surcharge). The description adds meaning beyond the schema, such as the condition for free result.

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: 'Optimize an AI-generated image for the web' and specifies it as the step after image generation. This distinguishes it from sibling tools like compress_image or convert_image by targeting AI-generated output and web readiness.

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 indicates when to use this tool ('The step after image generation') and compares pricing to convert, implying alternatives. It also covers delivery modes and quality controls, giving clear guidance on scenarios like async delivery via callback URLs or cost implications of quality_target.

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 the full burden. It discloses the processing pipeline order (denoise -> equalize -> op -> sharpen), autorot behavior, opt-in features, and delivery mode details (including security considerations for put_url and callback_url). However, it does not mention error handling, size limits, or performance implications, which would be valuable for an agent.

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 front-loaded with the main purpose but includes verbose response examples and some redundancy (e.g., repeating parameter details from the schema). It could be more concise by omitting the example responses or merging the mode explanations. Still, it is structured logically.

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 complexity (13 parameters, no output schema), the description covers the main modes, modifiers, and delivery options, but it lacks explicit error scenarios, constraints (e.g., maximum image size), and a structured description of the return value beyond content type examples. It is adequate but leaves gaps an agent might need to discover through trial and error.

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 92%, so the baseline is 3. The description adds context about the two modes and the default gravity, but the schema already provides detailed descriptions for most parameters. The description does not introduce meaning beyond what the schema offers, so a score 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's purpose: 'Resize an image' and distinguishes two modes (scale by factor or fill exact box). It uses specific verbs like 'scale', 'fill', and 'smart-crop', and the sibling tools (e.g., crop_image, compress_image) are clearly different operations, so an agent can easily understand what this 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 explains when to use the internal scale vs. fill modes and that they are mutually exclusive, but it does not provide any guidance on when to choose resize_image over sibling tools like compress_image or convert_image. An agent would need to infer the context from the tool names alone.

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