Resize, compress, convert, crop, rotate and watermark images, one at a time or in a zip.
Scored across 2 tools
The two tools have clearly distinct roles: create_upload only obtains a signed URL for large/on-disk files, while process_images performs all image transformations. Descriptions cross-reference each other explicitly (file_id from create_upload) so an agent cannot reasonably confuse them.
Both names follow a clean snake_case verb_noun pattern (create_upload, process_images). No mixed conventions or vague verbs.
Two tools is on the thin side, but they map to a genuine two-step pipeline: stage a large file, then transform it. Nothing extraneous, though the surface is minimal enough that a single-purpose server feels borderline.
The process_images tool covers a broad transformation matrix (resize, crop, convert, compress, watermark, EXIF stripping) and accepts inline, URL, or uploaded sources, so core workflows are covered. Minor gaps exist: no way to delete or list previously uploaded files, and no async job handle for long-running zip processing.
Get a one-hour signed upload URL for an image or a zip that is too large to send inline (over 3 MB; up to 100 MB here) or that already sits on disk. PUT the raw bytes to upload_url with a Content-Length header, then pass file_id to process_images. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| bytes | Yes | Exact size of the file you will upload, in bytes (at most 100 MB) | |
| filename | No | Original file name, used to name the output |
| Name | Required | Description |
|---|---|---|
| method | Yes | |
| file_id | Yes | |
| max_bytes | Yes | |
| expires_at | Yes | |
| upload_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (not read-only, not idempotent, not destructive); the description adds substantive facts the agent cannot get elsewhere: the URL expires in one hour, the caller must PUT raw bytes with a Content-Length header, and the returned file_id must be forwarded to process_images. It also notes the operation is free, which matters for an agent deciding whether to route a large file this way.
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?
Two sentences, zero waste: the first establishes purpose and eligibility, the second gives the exact call sequence. Size limits and the critical PUT instruction are front-loaded rather than buried.
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?
Even though an output schema exists, the description still tells the agent what to do with the returned upload_url and file_id, which is the non-obvious part of the contract. Combined with the expiry window and size bound, nothing an agent needs to invoke this correctly is missing.
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 both 'bytes' and 'filename' are already documented in the schema. The description restates the size ceiling implied by the schema but says nothing about 'filename' or how the declared byte count relates to the actual PUT payload. Baseline 3 is appropriate when the schema carries the parameter detail.
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?
States a specific verb and resource ('Get a one-hour signed upload URL') and immediately scopes it to images/zips over 3 MB up to 100 MB or files already on disk. This clearly separates it from inline submission and from the sibling process_images, which is named as the downstream consumer.
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?
Gives explicit selection criteria (>3 MB, up to 100 MB, or already on disk) that route the agent here rather than to inline sending, and names the alternative tool to call next ('pass file_id to process_images'). The full workflow is spelled out with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| fit | No | How to fit into width x height: scale-down never enlarges; cover fills and crops; pad adds borders | scale-down |
| url | No | Or a public https URL of an image or zip | |
| flip | No | Flip: h = horizontal, v = vertical, hv = both | none |
| width | No | Width in pixels | |
| format | No | Output format (keep turns HEIC into JPEG and GIF into PNG) | keep |
| height | No | Height in pixels | |
| rotate | No | Rotate clockwise (degrees) | |
| file_id | No | Image or zip file (up to 25 MB on this page) | |
| quality | No | Quality 1-100 for JPEG, WebP and AVIF; lower is smaller. Ignored with target_bytes | |
| crop_top | No | Crop: top edge (px, or % of the height with crop_unit percent) | |
| filename | No | Name for the output when the source has none | |
| max_side | No | Instead 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_left | No | Crop: left edge (px, or % of the width with crop_unit percent) | |
| crop_unit | No | Unit 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_date | No | With 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 | |
| background | No | JPEG only: colour under transparent areas, #rrggbb | #ffffff |
| crop_width | No | Crop: width (px, or % of the width with crop_unit percent) | |
| crop_aspect | No | Instead of the four crop fields: the largest centered crop of this width:height ratio, per image | |
| crop_height | No | Crop: height (px, or % of the height with crop_unit percent) | |
| data_base64 | No | Base64 bytes of an image or zip, up to 3 MB decoded; use create_upload (up to 100 MB) or url above that | |
| resize_unit | No | Unit 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 contain | px |
| watermark_x | No | With watermark_position custom: the centre of the text, % of each image's width from the left (0-100) | |
| watermark_y | No | With watermark_position custom: the centre of the text, % of each image's height from the top (0-100) | |
| target_bytes | No | Instead 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_copyright | No | With strip_metadata: keep the EXIF Copyright tag. XMP and IPTC rights are not kept | |
| strip_metadata | No | Remove EXIF, GPS location and camera data | |
| watermark_size | No | Watermark 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_text | No | Watermark text | |
| watermark_color | No | Watermark color, #rrggbb | #ffffff |
| watermark_image | No | Logo 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_opacity | No | Watermark opacity, 0.05 to 1 | |
| watermark_position | No | Watermark position; custom places the centre of the text at watermark_x, watermark_y | bottom-right |
| watermark_size_unit | No | Unit 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_size | No | Logo width, % of each image's width (2-50). Default 15 |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| bytes | Yes | |
| items | Yes | |
| skipped | Yes | |
| expires_at | Yes | |
| megapixels | Yes | |
| content_type | Yes | |
| download_url | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_uploadprocess_imagesImage toolkit: resize, convert, compress, crop, metadata, hashes, favicons, OCR, QR codes, barcodes.
Image toolkit: resize, compress, crop, watermark, convert, rotate, EXIF read/strip.
Resize, convert, compress, crop, thumbnail and watermark images from your AI chat.
Resize, convert to WebP, compress, crop, rotate and strip EXIF from images
Add one secure layer between your agents and this server.