Skip to main content
Glama

Image Tools

process_images

Idempotent

Resize, crop, rotate, flip, compress (to a file size with target_bytes), convert (jpeg, png, webp, avif), strip EXIF and GPS metadata from, and watermark (text, logo or both) one image or a zip of up to 50 images (up to 500 files per zip; files that are not supported images are skipped and listed). Crops are in pixels by default; for a zip of different sizes use crop_unit "percent" or crop_aspect, which are worked out per image. Give exactly one source: file_id (from create_upload), url (public https) or data_base64 (up to 3 MB inline; use create_upload, up to 100 MB, or url above that). One image in returns one image; a zip returns a zip. AVIF output is scaled down to fit 1,200 px on the longest side and WebP output to 36 megapixels. Returns a 24-hour download_url with the size and format of every output, and for each output the kinds of metadata found in the input and left in the output (location, date, camera, serial number, ...) and whether the colour profile was kept; kinds only, never the values. keep_date and keep_copyright write back the EXIF date taken and copyright after stripping. Large zips can take up to a minute; use a client timeout of at least 120 s. Free. Daily quotas are counted per caller in output megapixels; see start.md.

Input Schema

NameRequiredDescriptionDefault
fitNoHow to fit into width x height: scale-down never enlarges; cover fills and crops; pad adds bordersscale-down
urlNoOr a public https URL of an image or zip
flipNoFlip: h = horizontal, v = vertical, hv = bothnone
widthNoWidth in pixels
formatNoOutput format (keep turns HEIC into JPEG and GIF into PNG)keep
heightNoHeight in pixels
rotateNoRotate clockwise (degrees)
file_idNoImage or zip file (up to 25 MB on this page)
qualityNoQuality 1-100 for JPEG, WebP and AVIF; lower is smaller. Ignored with target_bytes
crop_topNoCrop: top edge (px, or % of the height with crop_unit percent)
filenameNoName for the output when the source has none
max_sideNoInstead of width and height: the longest side in pixels, per image, so portrait and landscape images both get it on their long edge. Never enlarges unless fit is contain
crop_leftNoCrop: left edge (px, or % of the width with crop_unit percent)
crop_unitNoUnit of the four crop fields: px (whole pixels) or percent (0-100 of each image, so a zip of different sizes gets the same part of every image)px
keep_dateNoWith strip_metadata: keep the EXIF date taken (DateTimeOriginal and DateTimeDigitized, with their time zone and fraction of a second) so photos still sort by date. A date and time taken found only in XMP or PNG text is written as the EXIF DateTimeOriginal; IPTC dates are not kept
backgroundNoJPEG only: colour under transparent areas, #rrggbb#ffffff
crop_widthNoCrop: width (px, or % of the width with crop_unit percent)
crop_aspectNoInstead of the four crop fields: the largest centered crop of this width:height ratio, per image
crop_heightNoCrop: height (px, or % of the height with crop_unit percent)
data_base64NoBase64 bytes of an image or zip, up to 3 MB decoded; use create_upload (up to 100 MB) or url above that
resize_unitNoUnit of width and height: px, or percent (1-1000) of each image's own size, so a zip of different sizes is scaled alike. Over 100 enlarges only with fit containpx
watermark_xNoWith watermark_position custom: the centre of the text, % of each image's width from the left (0-100)
watermark_yNoWith watermark_position custom: the centre of the text, % of each image's height from the top (0-100)
target_bytesNoInstead of quality: the most bytes each output may have (10,000-50,000,000; 1 MB = 1,000,000), for upload forms with a size limit. Uses the highest quality from 45 to 92 that fits; if even 45 is too big, the image is scaled down too. Each item then reports the quality used, and over_target when it could not get under
keep_copyrightNoWith strip_metadata: keep the EXIF Copyright tag. XMP and IPTC rights are not kept
strip_metadataNoRemove EXIF, GPS location and camera data
watermark_sizeNoWatermark font size: px (8-400, whole numbers) or, with watermark_size_unit percent, % of each image's width (0.5-20, giving 12-1000 px). Default 4% of the width
watermark_textNoWatermark text
watermark_colorNoWatermark color, #rrggbb#ffffff
watermark_imageNoLogo for the watermark, with or instead of watermark_text: a file_id from create_upload, a public https url, or data:image/png;base64,... (up to 1 MB inline; an inline image and logo share the 3 MB inline limit). PNG with transparency is best; WebP and JPEG work. Up to 2 MB and 2048 px on the longest side; rasterise SVG to PNG first. With text, the logo sits left of the text and both are placed as one
watermark_opacityNoWatermark opacity, 0.05 to 1
watermark_positionNoWatermark position; custom places the centre of the text at watermark_x, watermark_ybottom-right
watermark_size_unitNoUnit of watermark_size: px, or percent of each image's width (so a zip of different sizes gets the same relative size)px
watermark_image_sizeNoLogo width, % of each image's width (2-50). Default 15

Output Schema

NameRequiredDescriptionDefault
kindYes
bytesYes
itemsYes
skippedYes
expires_atYes
megapixelsYes
content_typeYes
download_urlYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With annotations covering safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description still adds substantial behavioral context: unsupported files are skipped and listed, AVIF is scaled to 1,200 px and WebP capped at 36 MP, outputs return a 24-hour download_url, metadata is reported as kinds only and never values, and over_target is reported when target_bytes cannot be met.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The processing verbs are front-loaded and nearly every sentence carries a constraint or caveat that is not in structured fields. It is a single dense run-on paragraph, though, which makes the source-selection rule and the size limits harder to scan than they need to be.

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

Completeness5/5

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

For a 34-parameter tool with 100% schema coverage plus an output schema, the description covers the remaining agent-relevant concerns: input limits, mixed-zip behavior, one-in/one-out semantics, runtime, and where quota docs live (start.md). Nothing needed for a correct call is missing.

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 100%, so the baseline is 3, but the description adds cross-parameter rules the schema does not express: exactly one source, percent/aspect crop units chosen for mixed-size zips, and keep_date/keep_copyright writing EXIF back after stripping. It does not restate the enum values or per-parameter ranges, which the schema already handles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names specific verbs and resources (resize, crop, rotate, flip, compress, convert, strip EXIF/GPS, watermark) and states the exact input scope (one image or a zip of up to 50 images). It is distinguishable from the only sibling, create_upload, which it explicitly names as the source for file_id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives the hard rule 'exactly one source' and routes between file_id, url and data_base64 with size thresholds (3 MB inline, 100 MB via create_upload, url above that). It also sets an operational expectation (client timeout of at least 120 s for large zips) and explains where quotas are counted.

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.

Resources