Transform and optimize images by resizing, compressing, and converting across multiple formats. Streamline complex editing workflows using a multi-step pipeline for efficient sequential processing.
Analyze an image
Fetch an image from a URL or base64 and return its metadata: size in bytes, pixel dimensions, source format, and what it costs every supported vision model in tokens. Always free. Dimensions are omitted if the image header cannot be read. Also reports whether the input carries a C2PA (Content Credentials) manifest and in which container; the manifest is not validated.
200: Successful Response (Success Response) Content-Type: application/json
Example Response:
{
"size_bytes": 1,
"c2pa_manifest": true
}| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Image source: a public URL (https://...) or a base64-encoded string (optionally as a data URI like data:image/png;base64,...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses that the operation is free, that dimensions are omitted if headers cannot be read, that C2PA manifests are reported but not validated, and shows a success response. It does not discuss failure modes or data handling, but the provided caveats are meaningful.
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 'Analyze an image' and organized into a concise narrative followed by a response example. Every part earns its place: the output list, the free guarantee, the header caveat, and the C2PA note all add useful, non-redundant information.
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 single-parameter tool with no output schema, the description covers expected outputs, source requirements, caveats, and a partial JSON example. It is slightly incomplete in that the example does not illustrate all named response fields (e.g., dimensions, format, per-model costs), but it is still sufficient for basic 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 100%: the source parameter's description already explains public URLs and base64 data URIs. The tool description mostly repeats this information, adding no new parameter constraints or format details, so the baseline 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: fetch an image and return its metadata (size, dimensions, format, per-model token costs, C2PA status). It distinguishes itself from transform-focused siblings like compress_image and resize_image, and the 'Always free' qualifier helps separate it from cost-related tools like estimate_cost.
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 concrete input context by specifying public URL or base64 sources, and mentions the always-free nature. However, it does not explicitly state when to prefer this tool over siblings such as estimate_cost or get_format_info, nor does it mention exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compress an image
Re-encode an image with quality/format options to reduce file size. Supports jpeg, png, webp, tiff, gif. Instead of a q number you can set quality_target (0-1]: the smallest file with SSIM at or above the target, searched on the worker (jpeg, webp, avif; flat surcharge; outcome reported in X-Pictomancer-Quality-* headers). If the output is not smaller than the input, the request is free (X-Pig-Billed: 0) and does not consume free-tier quota. Optional enhancement modifiers: denoise (1-3), equalize, sharpen (applied denoise -> equalize -> op -> sharpen).
200: Processed image binary (Success Response) Content-Type: application/json Content-Type: image/jpeg
Example Response:
"string"Content-Type: image/png
Example Response:
"string"Content-Type: image/webp
Example Response:
"string"| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Quality (1-100). Lower = smaller file. Typical values: 60-80 for web, 85-95 for print. Maps to libvips Q parameter. | |
| strip | No | Strip metadata (EXIF, ICC profile, etc.) from the output. Reduces file size slightly. | |
| format | No | Output format: jpeg, png, webp, tiff, gif, or avif. If omitted, the original format is preserved. | |
| source | Yes | Image source: a public URL (https://...) or a base64-encoded string (optionally as a data URI like data:image/png;base64,...). | |
| autorot | No | Apply EXIF orientation before compressing. Opt-in; default false, which preserves current byte-for-byte behavior. | |
| denoise | No | Median denoise before compressing: radius 1-3 (window 3x3 to 7x7). Opt-in; no surcharge. | |
| sharpen | No | Unsharp-mask sharpen after compressing (libvips defaults). Opt-in. | |
| delivery | No | ||
| equalize | No | Auto-contrast (histogram equalisation of the value channel; hue and saturation preserved) before compressing. Opt-in. | |
| quality_target | No | Target SSIM (0-1]: the worker searches for the smallest file that still scores at least this. Alternative to q; mutually exclusive with it. Requires an explicit format among jpeg, webp, avif. Carries a flat surcharge for the extra encodes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses critical behaviors: free-trial condition, search process for quality_target, pipeline order of modifiers, delivery modes with security details, and billing headers. Very comprehensive.
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?
Well-structured: starts with purpose, then details on quality_target, free condition, modifiers, then response examples. Every sentence adds value; no 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 10 parameters, high schema coverage, no output schema but includes response examples and headers (X-Pig-Billed, X-Pictomancer-Quality). Covers input, delivery, modifiers, security, and outcomes completely.
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%), baseline 3. The description adds meaning beyond schema: mutual exclusivity of q and quality_target, surcharge for quality_target, modifier effects, and security notes on delivery 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 opens with 'Compress an image' and explains it re-encodes with quality/format options to reduce file size. It lists supported formats and distinguishes from sibling tools like convert_image by focusing on compression to reduce size.
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 explicit guidance on when to use q vs. quality_target, notes that the request is free if output is not smaller, and describes optional modifiers. However, it does not directly contrast with siblings (e.g., when to use convert_image instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert image format
Convert an image to a different format (jpeg, png, webp, tiff, gif, avif). Optionally set quality, strip metadata, enable lossless mode (webp, avif), or tune encoder effort (avif). Instead of a q number you can set quality_target (0-1]: the smallest file with SSIM at or above the target, searched on the worker (jpeg, webp, avif; flat surcharge; outcome reported in X-Pictomancer-Quality-* headers). Optional enhancement modifiers: denoise (1-3), equalize, sharpen (applied denoise -> equalize -> op -> sharpen).
200: Processed image binary (Success Response) Content-Type: application/json Content-Type: image/jpeg
Example Response:
"string"Content-Type: image/png
Example Response:
"string"Content-Type: image/webp
Example Response:
"string"| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Quality (1-100). Maps to libvips Q parameter. | |
| strip | No | Strip metadata (EXIF, ICC profile, etc.) from the output. | |
| effort | No | AV1 encoder CPU effort (0-9). Higher = smaller file, slower. Only applies to avif. | |
| format | Yes | Target format: jpeg, png, webp, tiff, gif, or avif. | |
| source | Yes | Image source: a public URL (https://...) or a base64-encoded string (optionally as a data URI like data:image/png;base64,...). | |
| autorot | No | Apply EXIF orientation before converting. Opt-in; default false, which preserves current byte-for-byte behavior. | |
| denoise | No | Median denoise before converting: radius 1-3 (window 3x3 to 7x7). Opt-in; no surcharge. | |
| sharpen | No | Unsharp-mask sharpen after converting (libvips defaults). Opt-in. | |
| delivery | No | ||
| equalize | No | Auto-contrast (histogram equalisation of the value channel; hue and saturation preserved) before converting. Opt-in. | |
| lossless | No | Enable lossless encoding. Only applies to webp and avif. | |
| quality_target | No | Target SSIM (0-1]: the worker searches for the smallest file that still scores at least this. Alternative to q; mutually exclusive with it and with lossless. Only for jpeg, webp, avif. Carries a flat surcharge for the extra encodes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It discloses the enhancement order (denoise->equalize->op->sharpen), the quality_target search with surcharge, and headers for quality outcome. However, it does not explain the response format clearly (binary vs JSON), delivery modes, or any side effects like overwrite or rate limits.
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 somewhat repetitive (first line repeated in expanded form) and mixes format details with enhancement modifiers and response info. While it is structured in paragraphs, it could be more concise by removing redundancies and front-loading the core purpose.
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 12 parameters and no output schema, the description should cover more. It omits delivery modes (present in schema but not described), the actual response nature (binary vs JSON string), and prerequisites (e.g., source validity). The response section is confusing with multiple Content-Type headers and JSON string 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 high (92%), giving a baseline of 3. The description adds meaningful context: explains quality_target as an alternative to q with SSIM search, the order of enhancement modifiers, and which formats support lossless/effort. This goes beyond the schema's parameter 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 converts image format and lists all target formats (jpeg, png, webp, tiff, gif, avif). It goes beyond a simple verb+resource by including optional quality and enhancement capabilities, but does not explicitly differentiate from sibling tools like compress_image or optimize_for_vision.
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 explicit guidance on when to use this tool versus alternatives such as crop_image, compress_image, or image_pipeline. The description implies usage for format conversion but does not provide when-to-use or when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crop an image
Extract a rectangular region from an image, in one of three mutually exclusive modes. Manual: give the top-left corner (x, y) and dimensions (width, height) in pixels. Smart crop: give 'gravity' (attention, entropy, centre) plus width and height; the window is picked automatically, clamped to the source if the target is larger. Trim: set 'trim: true' (optional 'threshold') to remove a uniform background border via content detection; the applied rect is reported in X-Pictomancer-Trim-* headers. Optional enhancement modifiers: denoise (1-3), equalize, sharpen (applied denoise -> equalize -> op -> sharpen).
200: Processed image binary (Success Response) Content-Type: application/json Content-Type: image/jpeg
Example Response:
"string"Content-Type: image/png
Example Response:
"string"Content-Type: image/webp
Example Response:
"string"| Name | Required | Description | Default |
|---|---|---|---|
| x | No | Left edge of the crop rectangle in pixels. Manual mode only. | |
| y | No | Top edge of the crop rectangle in pixels. Manual mode only. | |
| trim | No | Trim mode: removes a uniform background border via content detection. Mutually exclusive with x/y/width/height/gravity. | |
| width | No | Width of the crop rectangle in pixels. Required in manual and gravity modes. | |
| format | No | Output format: jpeg, png, webp, tiff, gif, or avif. If omitted, the original format is preserved. | |
| height | No | Height of the crop rectangle in pixels. Required in manual and gravity modes. | |
| source | Yes | Image source: a public URL (https://...) or a base64-encoded string (optionally as a data URI like data:image/png;base64,...). | |
| autorot | No | Apply EXIF orientation before cropping. Opt-in; default false, which preserves current byte-for-byte behavior. | |
| denoise | No | Median denoise before cropping: radius 1-3 (window 3x3 to 7x7). Opt-in; no surcharge. | |
| gravity | No | Smart-crop mode: picks the window automatically. One of ('attention', 'entropy', 'centre'). Requires width and height; mutually exclusive with x/y and trim. A target larger than the source clamps to the source size. | |
| sharpen | No | Unsharp-mask sharpen after cropping (libvips defaults). Opt-in. | |
| delivery | No | ||
| equalize | No | Auto-contrast (histogram equalisation of the value channel; hue and saturation preserved) before cropping. Opt-in. | |
| threshold | No | Trim sensitivity (must be positive; default 10.0). Only valid together with trim: true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses clamping behavior for oversized targets, reports trim results via X-Pictomancer-Trim-* headers, and specifies the enhancement pipeline order (denoise -> equalize -> op -> sharpen). The response section is ambiguous about actual return payloads, but the disclosed behavior is substantive.
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 efficient, but the Responses section is bloated and repetitive: it lists three nearly identical 'Content-Type / Example Response: string' blocks that add little usable information. This templated noise lowers overall structure quality.
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 14-parameter tool with no output schema and no annotations, the description covers the major decision axes: manual vs smart vs trim, enhancement modifiers, trimming headers, and response types. The response documentation is underwhelming but the core operational context is well covered.
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 the baseline is 3. The description adds value by explaining mutual exclusivity of modes, clarifying gravity's clamping, and noting threshold is only valid with trim. This goes beyond the schema's individual property 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 opens with a specific verb and resource ('Crop an image') and immediately distinguishes three mutually exclusive modes (Manual, Smart crop, Trim). This clearly differentiates crop_image from siblings like resize_image or 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?
The description gives concrete guidance for choosing among the three modes: manual requires explicit coordinates, smart crop uses gravity, trim removes uniform borders. It does not explicitly name alternatives like resize_image, but the mode-selection context is clear enough for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the price of an operation
Returns the exact USD price this API would charge for an operation on an input of the given size, without fetching or processing anything. Free. Use it before paying: send X-Max-Cost-USD on the real request to have the API refuse (412) instead of charging more than you allowed. The list price is returned even when the request could end up free (free tier, or a compress that does not shrink the file).
200: Successful Response (Success Response) Content-Type: application/json
Example Response:
{
"operation": "Operation",
"price_usd": 1.0,
"base_usd": 1.0,
"surcharges_usd": {},
"size_multiplier": 1.0,
"within_free_tier": true,
"free_tier_remaining": 1,
"currency": "Currency",
"network": "Network"
}| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Requested output format; only avif changes the price. | |
| operation | Yes | Operation to price. One of resize, compress, convert, crop, optimize_for_vision, optimize_generated, pipeline. analyze is always free. | |
| operations | No | For pipeline only: the ordered operations, each {type, format?}. Volume discount applies at 3+ operations. | |
| input_bytes | Yes | Size of the input image in bytes. Get it from analyze_image (free) if you do not know it. | |
| quality_target | No | Whether the request will use quality_target (SSIM search surcharge). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly states no processing occurs, it's free, and explains behavior even when requests could be free (free tier, compress that doesn't shrink). This is transparent about key behaviors.
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 and usage advice, followed by a response example. It is well-structured and each sentence adds value, though slightly longer than 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?
Given 5 parameters, no output schema, and no annotations, the description covers the essential points: pricing behavior, free tier, usage with max-cost header, and a detailed response example. It is complete for a cost estimation tool though could mention error 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 100%, so baseline is 3. The tool description does not add extra meaning beyond the schema's parameter descriptions. It reiterates some context (e.g., 'analyze is always free' in operations) but primarily relies on schema, which is adequate.
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 explicitly states 'Estimate the price of an operation' and elaborates that it returns the exact USD price without fetching or processing anything. This clearly differentiates it from sibling tools that perform actual image 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 advises using the tool before paying and mentions the X-Max-Cost-USD header to cap charges, providing explicit when-to-use guidance. It lacks explicit when-not-to-use or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get supported formats and options
Returns supported output formats and their configurable options.
200: Successful Response (Success Response) Content-Type: application/json
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Run a multi-step image pipeline
Chain multiple operations (resize, compress, convert, crop) in sequence. The image is fetched once, then each operation is applied to the output of the previous one. Max 10 operations per pipeline.
200: Processed image binary (Success Response) Content-Type: application/json Content-Type: image/jpeg
Example Response:
"string"Content-Type: image/png
Example Response:
"string"Content-Type: image/webp
Example Response:
"string"| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Image source: a public URL (https://...) or a base64-encoded string (optionally as a data URI like data:image/png;base64,...). | |
| delivery | No | ||
| operations | Yes | Ordered list of operations to apply sequentially. Each operation receives the output of the previous one. Max 10. |
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.
Resize an image for a vision model
Resize an image to the largest size a given vision model still benefits from, and report what it costs that model in tokens before and after. Every provider downscales oversized input before counting tokens, so this alone saves bytes and upload latency rather than tokens. Pass max_tokens to trade resolution for tokens: that lever is continuous on Claude, unavailable on OpenAI (cost follows the aspect ratio alone), and on Gemini reaches only a flat 258. An image already within budget is returned untouched and free (X-Pig-Billed: 0).
200: Processed image binary (Success Response) Content-Type: application/json Content-Type: image/jpeg
Example Response:
"string"Content-Type: image/png
Example Response:
"string"Content-Type: image/webp
Example Response:
"string"| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Quality (1-100). Maps to libvips Q parameter. | |
| format | No | Output format: jpeg, png, webp, tiff, gif, or avif. If omitted, the original format is preserved. | |
| source | Yes | Image source: a public URL (https://...) or a base64-encoded string (optionally as a data URI like data:image/png;base64,...). | |
| delivery | No | ||
| max_tokens | No | Optional cap on what the image may cost the target model. Without it the image is resized to the model's own ceiling, which saves bytes and upload latency but no tokens, because every provider already downscales oversized input before counting. Set a budget to trade resolution for tokens. The response reports the cost actually achieved: on OpenAI it cannot be lowered by resizing at all, and on Gemini only down to a flat 258. | |
| target_model | Yes | Vision model the image is being prepared for, e.g. claude-opus-5, gpt-4o, gemini-2.5-pro. Unknown ids are rejected rather than guessed: the wrong limits would silently resize to the wrong size. |
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.
Optimize an AI-generated image for the web
The step after image generation. gpt-image, DALL-E, Flux, Midjourney and Stable Diffusion hand back 2-8 MB PNGs; this returns the same picture as a web-ready webp (default), avif, jpeg or png, metadata stripped, transparency kept on webp/avif/png. Optional max_dimension caps the longest side (never upscales); optional q or quality_target (smallest file with SSIM >= target, flat surcharge) control quality. Same price as convert. If the result is not smaller than the input it is still returned but free (X-Pig-Billed: 0). X-Pictomancer-Bytes-Before/-After/-Saved-Percent report the saving. The input's C2PA manifest, if any, is reported in X-Pictomancer-C2PA-Input but is not carried over: re-encoding invalidates it.
200: Processed image binary (Success Response) Content-Type: application/json Content-Type: image/jpeg
Example Response:
"string"Content-Type: image/png
Example Response:
"string"Content-Type: image/webp
Example Response:
"string"| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Quality (1-100). Maps to libvips Q parameter. Omit to use the encoder default; or set quality_target instead. | |
| strip | No | Strip metadata. Defaults to true: generated images carry no EXIF worth keeping. Metadata includes any C2PA manifest, which would be invalid after re-encoding anyway. | |
| format | No | Output format: webp (default), avif, jpeg or png. webp, avif and png keep transparency; jpeg flattens it. | webp |
| source | Yes | Image source: a public URL (https://...) or a base64-encoded string (optionally as a data URI like data:image/png;base64,...). | |
| delivery | No | ||
| max_dimension | No | Cap on the longest side in pixels. Larger images are scaled down to fit, aspect ratio preserved; smaller images are never upscaled. | |
| quality_target | No | Target SSIM (0-1]: the worker searches for the smallest file that still scores at least this. Alternative to q; mutually exclusive with it. Carries a flat surcharge for the extra encodes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels. It discloses metadata stripping, transparency handling, never upscaling, pricing behavior (free if not smaller), relevant response headers (X-Pictomancer-*), C2PA not carried over, and delivery method semantics (presigned URL credentials never stored).
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 long but well-structured with headers for responses and explicit field lists. It front-loads the core purpose and behavior, then adds delivery specifics. The response examples are verbose and partly redundant with the schema, but they aid comprehension. Overall, it earns its length.
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 7 parameters, multiple delivery modes, and no output schema, the description covers all major aspects: input formats, output formats, quality control, pricing, metadata handling, security considerations, and delivery options. The response examples give concrete return types. It is complete for its 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 coverage is 86%, so baseline is 3. The description adds meaningful context beyond the schema: the relationship between q and quality_target (mutually exclusive, surcharge), default format, strip default rationale (C2PA invalidation), and delivery security details. This adds value but doesn't fully document every parameter nuance, so a 4 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+resource: 'Optimize an AI-generated image for the web', then clarifies it as the post-generation step and lists target formats and behaviors. It clearly differentiates from siblings like compress_image and convert_image by tying it to AI-generated sources and format-specific optimizations, though it doesn't explicitly name alternatives.
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 states when to use: 'The step after image generation' and mentions specific generators (gpt-image, DALL-E, etc.). It also notes 'Same price as convert' and describes the quality_target surcharge. However, it doesn't explicitly say when NOT to use this vs compress_image or convert_image, so the guidance is mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize an image
Scale an image by a factor, or fill an exact box. Use 'scale' for uniform scaling, or 'scale_x'/'scale_y' for independent axes (float factors, e.g. 0.5 = half size). Alternatively set 'width'+'height' for fill mode: resize and smart-crop to those exact dimensions in one call (optional 'gravity', default attention). The two modes are mutually exclusive. Optional enhancement modifiers: denoise (1-3), equalize, sharpen (applied denoise -> equalize -> op -> sharpen).
200: Processed image binary (Success Response) Content-Type: application/json Content-Type: image/jpeg
Example Response:
"string"Content-Type: image/png
Example Response:
"string"Content-Type: image/webp
Example Response:
"string"| Name | Required | Description | Default |
|---|---|---|---|
| scale | No | Uniform scale factor applied to both axes (e.g. 0.5 = half size). Use this for simple scaling; use scale_x/scale_y for independent axes. | |
| width | No | Target width in pixels for fill mode: resize and smart-crop to these exact dimensions in one call. Requires height. Mutually exclusive with scale/scale_x/scale_y. Upscaling is allowed. | |
| format | No | Output format: jpeg, png, webp, tiff, gif, or avif. If omitted, the original format is preserved. | |
| height | No | Target height in pixels for fill mode. Requires width. | |
| source | Yes | Image source: a public URL (https://...) or a base64-encoded string (optionally as a data URI like data:image/png;base64,...). | |
| autorot | No | Apply EXIF orientation before resizing. Opt-in; default false, which preserves current byte-for-byte behavior. | |
| denoise | No | Median denoise before resizing: radius 1-3 (window 3x3 to 7x7). Opt-in; no surcharge. | |
| gravity | No | Fill-mode smart-crop strategy: one of ('attention', 'entropy', 'centre'). Only valid together with width and height; defaults to attention. | |
| scale_x | No | Horizontal scale factor (e.g. 0.5 = half width). If only scale_x is given, scale_y defaults to the same value. | |
| scale_y | No | Vertical scale factor (e.g. 0.75 = 75% height). Optional; defaults to scale_x if omitted. | |
| sharpen | No | Unsharp-mask sharpen after resizing (libvips defaults). Opt-in. | |
| delivery | No | ||
| equalize | No | Auto-contrast (histogram equalisation of the value channel; hue and saturation preserved) before resizing. Opt-in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It thoroughly discloses behavioral traits: mutual exclusivity of scaling/fill modes, smart-crop default gravity, enhancement modifier order, delivery options (inline, put_url, callback), and that upscaling is allowed for fill mode. It also transparently describes delivery security details (HMAC signing, no credential storage). Minor gap: it doesn’t mention whether input source supports all formats for output.
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 in the first sentence, then dives into mode details, enhancement order, and delivery options. Every sentence adds value—no fluff. The response section is well-structured with clear HTTP status codes and example content types. At 13 lines of prose plus structured response info, it’s appropriately sized for a tool with 13 parameters and complex mode logic.
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?
While the description is thorough, it doesn't explain return values explicitly—though there is no output schema, the response section lists Content-Type headers providing some shape. It could mention that the result is the processed image binary for inline delivery. For a tool with 13 parameters and no output schema, the description covers the essential semantics and mode selection effectively.
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 very high (92%), so baseline is 3. The description adds significant value beyond the schema by clarifying the overall workflow (two modes, mutual exclusivity) and the enhancement pipeline order (denoise -> equalize -> op -> sharpen). It also explains gravity options succinctly. The description doesn’t add detail for every parameter (e.g., 'autorot' is not mentioned besides listing), but the schema already covers those 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 resizes images and distinguishes two main modes: uniform scaling via 'scale' or 'scale_x'/'scale_y', and exact fill via 'width'+'height' with smart-crop. It also mentions optional enhancement modifiers. This verb-resource definition effectively differentiates it from sibling tools like crop_image, compress_image, and 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?
The description provides explicit when-to-use guidance by describing the two mutually exclusive modes and their use cases ('scale' for uniform scaling, 'scale_x'/'scale_y' for independent axes, 'width'+'height' for fill mode with smart-crop). It does not explicitly mention when NOT to use this tool or suggest alternatives like crop_image or compress_image, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes (analyze, compress, convert, crop, resize, pipeline, optimize_for_vision, optimize_generated_image). However, there is some overlap between compress_image and convert_image (both deal with quality settings and can change format), and between resize_image and crop_image (resize's fill mode with smart-crop overlaps crop's smart crop). The pipeline tool could theoretically subsume any of the single-operation tools, which introduces a slight ambiguity in when to use pipeline vs. individual tools.
All tool names follow a consistent verb_noun pattern (analyze_image, compress_image, convert_image, crop_image, get_format_info, image_pipeline, optimize_for_vision, optimize_generated_image, resize_image). The naming is predictable and self-documenting, with no mixing of camelCase or other conventions.
With 9 tools, the server is well-scoped for an image processing domain. Each tool covers a core operation (analyze, compress, convert, crop, resize, pipeline, format info, and two optimization tools). The count feels appropriate—not too few to limit usefulness, not too many to be overwhelming.
The tool set provides comprehensive coverage for common image manipulation tasks: analysis, compression, format conversion, cropping, resizing, optimization for both general and AI-generated images, and a pipeline for chaining operations. Missing features like rotation, flipping, or color adjustments are minor but the core CRUD-like operations (read/analyze, write/convert, resize/crop) are well-represented, and the pipeline tool mitigates gaps by allowing combinations.