Skip to main content
Glama

convert_image

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).

Responses:

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"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoQuality (1-100). Maps to libvips Q parameter.
stripNoStrip metadata (EXIF, ICC profile, etc.) from the output.
effortNoAV1 encoder CPU effort (0-9). Higher = smaller file, slower. Only applies to avif.
formatYesTarget format: jpeg, png, webp, tiff, gif, or avif.
sourceYesImage source: a public URL (https://...) or a base64-encoded string (optionally as a data URI like data:image/png;base64,...).
autorotNoApply EXIF orientation before converting. Opt-in; default false, which preserves current byte-for-byte behavior.
denoiseNoMedian denoise before converting: radius 1-3 (window 3x3 to 7x7). Opt-in; no surcharge.
sharpenNoUnsharp-mask sharpen after converting (libvips defaults). Opt-in.
deliveryNo
equalizeNoAuto-contrast (histogram equalisation of the value channel; hue and saturation preserved) before converting. Opt-in.
losslessNoEnable lossless encoding. Only applies to webp and avif.
quality_targetNoTarget 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.

TDQS

B3.1/5.0
Behavior3/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Resources