McpStamp Image Tools

mcp-image

Say "make these five photos 1200 pixels wide" or "shrink this screenshot and strip the GPS out of it" and it happens, on your machine, in a second. This MCP server does the small image jobs that otherwise send you to a web uploader: resize, convert between PNG, JPEG, BMP, GIF and TIFF, compress with a real before-and-after byte count, crop, thumbnail a folder, watermark with your business name, and drop the EXIF block a phone camera writes into every photo. No upload, no account, no native dependency, no image editor.

In the [official MCP Registry](https://registry.modelcontextprotocol.io/v0.1/servers/io.github.theluckystrike%2Fimage-resize-convert-compress-watermark/versions/latest) (io.github.theluckystrike/image-resize-convert-compress-watermark).

Listed on the [AI Product Index](https://index.percall.dev/l/zovo-image.html) - live remote endpoint at mcp.zovo.one/s/image, free tier, no signup.

The image chores of a freelance business, done from chat instead of from a browser tab you would rather not hand a client photo to.

60-second install

npm publish for @theluckystrike/mcp-image is pending. Until then, the .mcpb one-click bundle or a clone+build is the working path, both are verified below.

One-click (.mcpb): download image.mcpb from the latest release and double-click it in Claude Desktop: https://github.com/theluckystrike/mcp-servers/releases/latest

(claude_desktop_config.json):

{

"mcpServers": { "image": { "command": "npx", "args": ["-y", "@theluckystrike/mcp-image"] } } }

Claude Code:

claude mcp add image -- npx -y @theluckystrike/mcp-image

(.cursor/mcp.json):

{

"mcpServers": { "image": { "command": "npx", "args": ["-y", "@theluckystrike/mcp-image"] } } }

The npx form above starts working the moment the package is published. Until then, use the .mcpb bundle above, or build from source with exactly these three commands:

git clone https://github.com/theluckystrike/mcp-servers.git && cd mcp-servers

npm install npm run build -w packages/mcp-license -w servers/image

Then point your client's command at node with one arg: the absolute path to servers/image/dist/index.js.

To run in Pro mode set MCP_LICENSE_KEY in the same config block, or call license_activate once with your key.

Tools

Resource: image://recent returns the last 25 operations, newest first, with the inputs, the files written and when. Prompt: prepare_for_web takes a camera-sized image down to a page-sized JPEG, drops the metadata that came with it, and reports the bytes saved.

What you can say

Worked example

You: This photo is too big for the site. Get it to 1600 wide and drop the metadata.

image_info { path: "~/photos/DSC_0491.jpg" } -> 6000x4000, 24 MP, JPEG, 8.4 MB, no alpha

image_compress { path: "~/photos/DSC_0491.jpg", max_width: 1600, quality: 80, max_bytes: 256000, out_path: "~/photos/DSC_0491-web.jpg" } -> 8.4 MB -> 243.7 KB (8809124 -> 249556 bytes, -97.2%) -> Method: JPEG quality 62 (searched down from 80 in 5 encodes to fit 250.0 KB) and a resize to 1600 px wide -> ~/photos/DSC_0491-web.jpg, 1600x1067, JPEG

The JPEG re-encode also drops the EXIF block the camera wrote, including the GPS coordinates. The original file is byte-for-byte unchanged.

Free vs Pro

The free limit is on what gets written, not on what gets read: a 12 MP phone photo taken down to 1600 px wide is a free call, because that is the job. Writing 12 MP back out again is the Pro one.

A tier limit is an answer, not an error, and nothing is written when one refuses a call.

Pro is a one-time $19, or $39 for every server in the collection, lifetime.

quality is a JPEG parameter, and only a JPEG parameter

This is the one thing about image compression that surprises people, so the server says it in its own answer rather than accepting a number and quietly doing nothing with it. A JPEG throws away detail to get smaller, and quality is the dial for how much. A PNG is lossless: there is no dial. Passing quality: 40 to a PNG output does not make a PNG 60% smaller, it makes exactly the same PNG.

So the output format follows the extension of your out_path, and that is the lever:

• out_path: "shot-small.jpg", quality applies, and a photo typically drops 80-95%.
• out_path: "shot-small.png", quality is reported as not applicable, and only max_width removes bytes.

Palette quantisation was measured as an alternative for PNG and rejected: re-encoding a 300x220 noisy PNG through a 16-colour quantiser produced a larger file (115,451 bytes against 39,262), because the encoder here writes RGBA either way and quantising only destroys the row-to-row similarity that the deflate step was exploiting. A tool that claims to compress and returns a bigger file is worse than a tool that says which knob exists.

image_compress therefore always reports the byte count before and after, the percentage, and the method that did the work, and, if the output came out larger, it says so and tells you to keep the original.

Decompression bombs are refused from the header, before anything decodes

A 4 KB PNG can declare that it is 20,000 by 20,000 pixels. Decoding it allocates 1.6 GB of RGBA and takes the process down before any size check written after the decode could ever run. So the declared dimensions are read out of the container header, PNG IHDR, the JPEG SOF segment, the GIF logical screen descriptor, the BMP info header, the first TIFF IFD, and a file over 10,000 px on a side is refused there, with the memory it would have taken named in the message:

Error: /path/bomb.png declares 20000x20000 pixels in its PNG header and was refused before decoding:

this server caps a side at 10000 px. A small file that declares an enormous canvas is a decompression bomb - decoding it would allocate 1526 MB of RGBA. Nothing was decoded.

The decoded size is checked again afterwards, because a header probe can come back empty on an unusual TIFF, and a guard that only sometimes runs is not a guard.

Existing files are never overwritten, and inputs are never modified

Every tool writes a new file and leaves its inputs byte-for-byte alone, there is no in-place mode, on purpose. An out_path that already exists is refused:

Error: /path/shot-small.png already exists and nothing was written.

Pass overwrite: true to replace it, or give a different out_path.

The path is reserved with an exclusive create, not an existence check, so two processes writing the same out_path at the same time cannot clobber each other: one wins, the other is refused and writes nothing. image_thumbnails and image_batch_resize reserve every one of their output paths before writing any of them, so a collision on file 3 does not leave files 1 and 2 behind as a half-done batch, and the reservations are released, so nothing empty is left on disk either.

Pass overwrite: true when replacing the file is what you want.

overwrite: true still does not let an output be an input. Writing a result back over one of its own sources destroys that source, the pixels are already decoded in memory and get written over the file they came from, so a 4000 px original becomes the 512 px thumbnail and every later read of that path is quietly wrong. So an out_path that resolves to (or shares an inode with) any input of the same call is refused before any work happens.

What "strip metadata" actually does

image_strip_metadata decodes the image and re-encodes it from the raw pixels. EXIF, GPS coordinates, the camera and lens, the capture time, XMP packets and embedded colour profiles are not removed one by one, they are simply never handed to the encoder, so they cannot come out the other side. Two consequences worth knowing:

• The pixels are the same, the bytes are not. A JPEG goes through the encoder a second time, so the copy is not bit-identical to the original even though it looks the same. Keep the original if that matters.
• Every other writing tool here has the same effect as a side effect. Resizing a photo also drops its EXIF.

Limits

• Inputs over 50 MB are refused: an image decodes to width x height x 4 bytes of raw RGBA regardless of how well it is compressed on disk.
• 10,000 px per side, checked from the header first and from the decode second.
• Read and written: PNG, JPEG, BMP, GIF and TIFF, detected by magic bytes rather than by file extension. No WebP, no AVIF, no HEIC, no SVG, there is no pure-JavaScript decoder for those that is worth shipping, and this server takes no native dependency.
• An animated GIF is read as its first frame. This server does not do ani