Pictomancer.ai

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

The description discloses that the tool is always free and that dimensions are omitted if the image header cannot be read. Since no annotations are provided, these behavioral details add valuable context, though error handling for fetch failures is 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 front-loaded with a one-line summary and then gives relevant details. It includes a response section and example, which is helpful but the example is minimal and only shows one field. Overall, it is concise and structurally sound.

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 has a single parameter and clear purpose, but the description only partially describes the return structure. It mentions metadata and token cost but does not specify which models or the full response format, and the example is incomplete. Given no output schema, this is a notable gap.

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 fully documents the 'source' parameter, including URL and base64/data URI formats. The description adds little beyond this, so it meets the baseline for high schema coverage but does not significantly enhance understanding.

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 fetches an image from a URL or base64 and returns metadata (size, dimensions, source format, token cost). This distinguishes it from sibling tools like compress_image and resize_image, which 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 usage for image analysis and metadata extraction, but it does not explicitly state when to use this tool versus alternatives like get_format_info. There is no mention of exclusions or preferred scenarios, so usage is only implied.

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. It discloses several important behaviors: free requests when output isn't smaller, the quality_target search process with surcharge and headers, autorot default false to preserve byte-for-byte behavior, and security details about delivery URLs never exposing credentials. This is exemplary transparency beyond the schema.

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 core purpose, but then includes a lengthy 'Responses' section with redundant Content-Type examples and placeholder 'string' responses. This section adds clutter without meaningful information. While the main paragraphs are efficient, the overall structure could be tightened.

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 a wide range of behaviors including formats, delivery modes, billing, quality_target, and security. It does not mention error cases or rate limits, and the response section is sparse. However, for a tool with 7 parameters and multiple delivery modes, the description is quite complete and covers most essential context.

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 86%, so baseline is 3. The description adds some context for quality_target (e.g., SSIM search, headers, surcharge) and mentions mutual exclusivity with q, but the schema already covers these details comprehensively. The description does not significantly enhance parameter understanding 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 opens with 'Compress an image' and immediately specifies 'Re-encode an image with quality/format options to reduce file size.' This clearly states the tool's purpose and distinguishes it from sibling tools like convert_image or resize_image. The verb+resource pair is specific and 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 clearly implies the primary use case is reducing file size, but it does not explicitly state when to prefer this over alternatives like convert_image or resize_image. It mentions the quality_target alternative to q within the tool, but doesn't provide exclusions or alternative tool guidance. The 'Compress an image' context is present, but no explicit when-not-to-use.

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 must carry the full burden. It discloses some behaviors such as quality_target search on the worker and a flat surcharge, and mentions outcome headers. However, it omits significant side effects like the ability to PUT/POST results to external URLs via delivery modes, and does not mention that source can be a URL with SSRF implications. The response section is also confusingly structured.

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 first paragraph is concise, but the Responses section is unnecessarily long with duplicate examples for each content type, showing only 'string'. This adds clutter without value, making the structure inefficient.

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 has 9 parameters with complex delivery options (inline, put_url, callback_url) and no output schema or annotations. The description only covers inline response and core conversion options, omitting delivery modes, security considerations, and other constraints. This is insufficient for a full understanding.

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 89%, so most parameters are already described. The description adds context for quality_target (SSIM target, surcharge, headers) and constraints like lossless for webp/avif and effort for avif. These are also present in the schema, so the added value is marginal.

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 'Convert an image to a different format' and lists supported formats (jpeg, png, webp, tiff, gif, avif). This distinguishes it from sibling tools like crop_image, resize_image, and compress_image, which have different verbs and resources.

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 when a format conversion is needed, but it does not explicitly state when to use this tool versus alternatives like compress_image or image_pipeline. There are no exclusions or alternative recommendations 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?

The description adds useful behavioral context beyond the schema, such as clamping smart crop windows to the source, trim removing a uniform background, and X-Pictomancer-Trim-* headers. However, the response section is confusing and potentially misleading: it lists Content-Type: application/json alongside image types and repeats the same 'string' example, which poorly communicates the actual binary response.

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 first paragraph is concise and well-structured, but the response section is bloated with repetitive, low-value content (multiple Content-Type lines with identical 'string' examples). This undermines the overall conciseness and does not earn its place.

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 11 parameters and no output schema, the description covers the main mode logic well but omits any discussion of the delivery parameter or how it interacts with cropping. The response section attempts to describe return values but is too flawed and confusing to be considered 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 already high (91%), but the description adds meaning by explaining how parameters interact—e.g., width/height required for manual and gravity modes, threshold only valid with trim, and mutual exclusivity of x/y, gravity, and trim. This goes beyond the schema's individual field descriptions.

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 crops an image and further specifies it extracts a rectangular region in one of three modes. This makes the purpose unambiguous and distinguishes it from sibling tools like resize or compress.

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 explains the three mutually exclusive modes (manual, smart, trim) and their parameter requirements, providing clear guidance on how to choose among them. It does not, however, compare this tool to siblings like resize_image or convert_image, so it stops short of a full when-not-to-use explanation.

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 burden. It says the tool 'Returns supported output formats and their configurable options' and includes a 200 response, which is basic behavioral disclosure for a read-only query. However, it does not explicitly state that this operation has no side effects or that it requires no input, though 'Get' implies read-only.

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 key purpose. The first sentence slightly restates the tool name, but the second sentence adds concrete value about what the response contains. The 'Responses' section is minimal and provides a small amount of useful context.

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 info tool, the description is sufficient: it states what the tool returns and includes a response note. However, it could be more helpful by relating the output to sibling tools (e.g., 'use these formats with convert_image'), but this is not essential.

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?

There are zero parameters, so the description cannot add parameter-level detail. The baseline for zero-param tools is 4, and the description appropriately clarifies that the tool returns available formats and options instead of performing a transformation.

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 'Get supported formats and options' with a clear verb and resource, and clarifies it returns supported output formats and configurable options. This distinguishes it from sibling image-processing tools, which perform actions rather than querying metadata.

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 explicit guidance on when to use this tool versus alternatives. It does not mention that it should be called before convert_image, compress_image, or other tools to discover supported formats, nor does it mention any exclusions or prerequisites.

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 of disclosure. It explains the sequential chaining and max operations, but omits significant side effects: the delivery parameter can write bytes to a presigned PUT URL or POST to a callback URL. The response section only mentions 'Processed image binary,' potentially misleading the agent into thinking inline delivery is always used. This is a notable transparency gap.

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 with a clear purpose. However, the response section is bloated with repeated 'Content-Type' and 'Example Response' lines that are identical and add confusion rather than value. This redundancy detracts from the overall 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?

The tool has a complex schema, no annotations, and no output schema. The description covers the pipeline concept and limit, but does not explain the delivery mode variations or how the return value differs when delivery is not inline. It also lacks error handling or authentication context. Given the complexity, this description is minimally viable but leaves important 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?

Schema description coverage is 67%, so the description should compensate. However, it adds no parameter-specific meaning beyond what the schema already provides. The 'Max 10 operations' constraint is already present in the operations parameter description. The 'image is fetched once' note is a behavioral trait, not a parameter semantic. The delivery parameter is completely absent from the description, relying entirely on 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 starts with 'Run a multi-step image pipeline' and details 'Chain multiple operations (resize, compress, convert, crop) in sequence.' This clearly identifies the tool's specific function of combining image operations, distinguishing it from single-operation siblings 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 provides clear context for when to use this tool: when multiple operations need to be chained. It states the image is fetched once and each operation applies to the previous output, plus the 10-operation limit. It does not explicitly name alternatives or exclusion criteria, but the multi-step versus single-step distinction is implied by the sibling tool names.

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 behavioral disclosure. It states that without max_tokens no tokens are saved, explains per-provider differences, and discloses that in-budget images are returned untouched and free (X-Pig-Billed: 0). It also documents the binary response shape, providing transparency beyond a simple resize action.

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 prose is front-loaded and well-structured, with clear paragraphs for behavior and provider nuances. However, the Responses section is bloated with repetitive Content-Type examples and placeholder 'string' responses that add noise and reduce 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?

For a tool with no annotations and no true output schema, the description covers the optimization logic, provider-specific token tradeoffs, the free/in-budget case, and the binary response. It does not explicitly address delivery modes, but those are well documented in the input schema, so overall completeness is strong.

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 83% of parameters with detailed descriptions, including max_tokens and target_model. The description reinforces max_tokens semantics but adds little that isn't already in the schema; q, format, source, and delivery rely on schema descriptions. 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 opens with a specific verb and resource: 'Resize an image to the largest size a given vision model still benefits from' and adds reporting of token cost before/after. This clearly differentiates it from the sibling resize/compress/convert tools by tying the action to vision-model token optimization.

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 gives actionable usage guidance: 'Pass max_tokens to trade resolution for tokens' and explains provider-specific behavior (continuous on Claude, unavailable on OpenAI, flat 258 on Gemini). It also notes that without max_tokens only bytes/latency are saved, which helps decide when the tool is useful. It does not explicitly name sibling alternatives but the context is 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?

With no annotations, the description carries the behavioral burden. It discloses the core operations (scaling, smart-crop, gravity default) and lists response content types, but it does not mention the delivery alternatives (put_url/callback), potential side effects, or any error behavior beyond 200.

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 introductory paragraph is concise and front-loaded with the essential mode information. However, the 'Responses' section is repetitive and verbose, listing the same 'string' example three times and multiple content types, so not every sentence earns its place.

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?

This is a complex 10-parameter tool with delivery modes (inline, put_url, callback) and no output schema or annotations, but the description omits the delivery parameter entirely and focuses only on scaling behavior. The response boilerplate does not compensate for the lack of guidance on asynchronous or URL-delivery use 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 description coverage is 90%, so the baseline is 3, but the description adds meaningful mode-level semantics by grouping parameters into scale and fill modes and explicitly stating mutual exclusivity. This goes beyond individual schema descriptions, though it does not explain the 'delivery' parameter.

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 images via scaling or filling an exact box, with specific mode definitions. However, it does not explicitly distinguish itself from sibling tools like crop_image or convert_image, so it falls short of full sibling differentiation.

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 'scale' vs 'scale_x'/'scale_y' vs width+height fill mode, and notes that the modes are mutually exclusive. It does not, however, discuss alternatives among sibling tools or when to choose this tool over crop_image or image_pipeline.

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