"Make this 1200 pixels wide" or "get this under a megabyte" is normally a trip to a web uploader, which is also the moment a client's product photo or a screenshot with something on screen leaves your machine. The MCP Image server does the same small jobs locally: resize, convert between PNG, JPEG, BMP, GIF and TIFF, compress with a real before-and-after byte count, crop, batch-thumbnail a folder, watermark with your business name, and strip the EXIF and GPS block a phone camera writes into every photo. No network call of any kind, not even for licensing.
claude mcp add image -- npx -y @theluckystrike/mcp-imageCursor reads the same block from .cursor/mcp.json:
{
"mcpServers": {
"image": {
"command": "npx",
"args": ["-y", "@theluckystrike/mcp-image"]
}
}
}Claude Desktop takes the identical block in claude_desktop_config.json. Data lives under
~/.local/share/mcp-servers/image/: a register of the last 500 operations, not your images,
which stay where you put them.
The tool most people reach for first is image_compress, and the surprising part is that
its one real knob, quality, only does anything on a JPEG output. A JPEG throws away detail to
get smaller, and quality controls how much. A PNG is lossless: there is no such dial, and a server that
silently accepted quality: 40 for a PNG and returned the same file would look like it worked
while doing nothing.
Before shipping that behaviour, the alternative was actually tried: pass a PNG through palette
quantization, the standard way to shrink a PNG by cutting it down to a small fixed set of colours. Run
against a 300x220 noisy test PNG, quantizing to 16 colours did not shrink the file. It produced a 115,451
byte file against a 39,262 byte original, 2.9 times larger, because the encoder here still writes RGBA
either way, and quantizing colours destroys the row-to-row pixel similarity that PNG's own deflate step
was exploiting to compress in the first place. A tool that claims to compress and hands back a bigger file
is worse than one that is honest about which knob exists at all, so the server does not quantize. Instead
it reports the byte count before and after, the percentage saved, and the method that did the work, and if
compressing a PNG would only reduce it by resizing, it says so plainly: for a PNG the lever is
max_width, not quality. The output format follows the extension of
out_path, so the practical move for a PNG screenshot you actually want smaller is to write it
out as a .jpg instead, where quality applies and a photo typically drops 80 to 95 percent.
image_resize fits inside a box, fills and crops the overflow, or stretches exactly, with
one of width or height following the other. image_crop refuses a rectangle that runs past an
edge rather than silently clamping it. image_thumbnails and image_batch_resize
reserve every output path before writing any of them, so a collision on file three does not leave files one
and two behind as a half-finished batch. image_watermark reads the shared business name from
the same profile the invoice and docx servers write, or takes custom text on Pro.
image_dominant_colors reports the hex codes that cover most of an image and the share each one
holds.
image_strip_metadata decodes the image to raw pixels and re-encodes from those pixels
alone, so EXIF, GPS coordinates, the camera and lens, the capture time, XMP packets and colour profiles are
not deleted one field at a time, they are simply never handed to the encoder. Every other writing tool here
has the same side effect: resizing a photo also drops its EXIF, since it goes through the same
decode-then-encode path.
A 4 KB PNG can declare a 20,000 by 20,000 pixel canvas in its header. Decoding that allocates roughly 1.6 GB of raw RGBA and can take the process down before any size check written after the decode would ever run, so the declared width and height are read out of the file's own 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 pixels on a side is refused there, with the memory it would have taken named in the error.
Free covers image_info unlimited, and resize, convert, compress, crop and strip-metadata on
sources up to 4 megapixels, batches of 5 files. Pro ($19 once, lifetime) removes the size and batch limits,
opens custom watermark text instead of only the business name, and adds dominant-colour reports. Product
page: MCP Image Tools.
quality is a JPEG-only parameter; a PNG is lossless and has no such dial. A measured test of the obvious alternative, palette quantization, produced a file 2.9 times larger (115,451 bytes against 39,262) because quantizing destroys the pixel similarity PNG's own compression depends on. Use max_width for a PNG, or write the output as .jpg where quality genuinely shrinks the file.
No. There is no network call of any kind, including for licence checks, which are verified offline. A client photo never leaves the machine it was resized on.
PNG, JPEG, BMP, GIF and TIFF, detected by magic bytes rather than file extension. No WebP, AVIF, HEIC or SVG: there is no pure JavaScript decoder for those worth shipping without a native dependency.
No, on purpose. Every tool writes a new file and refuses to overwrite an existing out_path unless you pass overwrite: true, and an out_path that resolves to one of the inputs is refused outright so a result can never be written back over the source that produced it.
Up to 50 MB on disk and 10,000 pixels per side on Pro; free tier tools cap sources at 4 megapixels. The pixel limit is checked from the file header before anything is decoded, specifically to refuse a decompression bomb.