Why We Relaxed Our Zero-Retention Policy for MCP Server Compressions
We added a five-minute hold on compressed outputs from the hosted MCP server so we can return a short-lived download URL instead of inline binary content. Your original image is still discarded immediately after encoding. The local mochify binary — CLI and mochify serve — still has nothing held server-side at all.
Published 29 May 2026 by the Mochify Engineering Team. The softening is narrow on purpose, and we'd rather describe the server accurately than carry a phrase that no longer matches what it does.
What's in This Guide
The Problem We Hit
The hosted MCP server at mcp.mochify.app used to return compressed images inline to the conversation as binary content. On paper this was the cleanest possible path: one round-trip, no extra fetch step, no third-party storage. In practice it broke. Chat clients vary widely in how they render or save binary returns from MCP tool calls, and the two most common outcomes were the tool call hanging without completing, or the result appearing in the response but proving impossible for the user to save.
From our side the compression was working: sub-second responses, large reductions, the right output format. The bytes were getting back to the client. The handoff from the chat client to the user was where things came apart, and for a tool that positions itself as the image toolkit for AI-native workflows, "the compression works but you can't actually get your file" is not an acceptable outcome. The full breakdown lives in how the Mochify MCP server works.
The Fix We Wanted to Build
We're agentic-workflow led: the hosted MCP has to actually deliver compressed images to the user, regardless of how well or badly the chat client handles binary returns. That ruled out staying inline. The obvious shape was URL passback. The tool response becomes a short text URL, the chat client treats it like any other link — every chat client handles links — and the user fetches or saves the file directly. Tokens-in-context drop on the return side because a URL is a few dozen bytes rather than an encoded image. Reliability across chat clients goes up because clients have years of experience handling links and almost none handling inline binary from tools.
The question wasn't whether to do URL passback. It was how to do it without quietly breaking the privacy posture that made Mochify worth using in the first place.
What We Shipped, and What We Held the Line On
We chose the smallest possible relaxation that actually solves the problem.
The compressed result is held in memory in a pickup store keyed by an unguessable hash, with a five-minute TTL. After five minutes the bytes are evicted whether or not the URL was ever fetched, and the URL stops resolving at the same moment. The tool response itself explicitly states "expires in ~5 minutes" alongside the URL, so downstream tools and saved scripts have no excuse to drift past the expiry.
What we deliberately kept:
- Your original image is still streamed into the encoder in RAM and discarded immediately. No disk writes of the source, no logs containing image data, no change from the web app or any other surface.
- No per-account history of compressed images. No analytics on what was processed beyond the usage counter exposed by the
check_usagetool. - The two local install paths — the
mochifyCLI andmochify serveas a local MCP server — don't touch the pickup store at all. The compressed bytes come back fromapi.mochify.appto your local binary and are written straight to your disk. End-to-end zero retention is intact for any workflow where you've installed the binary.
What This Means for Your Workflow
Use the hosted MCP server if drag-and-drop chat is the experience you want, and the compressed image transiting files.mochify.app for up to five minutes is a trade-off you're comfortable with. For most users, most of the time, that's a fine line to draw.
If you need a stronger end-to-end privacy posture, install the local binary with brew install mochify and use either mochify serve (chat-driven) or the CLI direct (build pipelines, batch jobs, anything scripted). Compressed bytes never sit on Mochify infrastructure beyond the encoding step itself. If you need to take Mochify off the path entirely, self-host the engine via the Docker self-hosting guide.
A softer retention claim is a less catchy marketing line than "wiped immediately." We'd rather match the words to what the server actually does.
FAQ
Does my original image still get wiped immediately?
Yes. The original is processed in RAM, encoded, and discarded the moment the response goes out. No disk writes of the source, no logs containing image data, no change from before.
What exactly is held for five minutes?
Only the compressed output, on the hosted MCP path. We hold it in memory so we can serve it via a short-lived download URL instead of trying to return the bytes inline (which was unreliable across chat clients). It is evicted after five minutes regardless of pickup.
Does this affect the local install or the CLI?
No. The local mochify binary (whether you run it as a CLI or as a local MCP server with mochify serve) receives compressed bytes from api.mochify.app and writes them straight to your disk. No pickup store is involved on those paths.
Why not encrypt the compressed result client-side so the pickup is opaque to Mochify?
We considered it. It's a stronger story and we may build it later. For this first cut we chose the simplest viable architecture so we could ship the URL passback fix without delay.
How do I know when the URL expires?
The tool response states "expires in ~5 minutes" alongside the URL, and the URL stops resolving at that point. Any downstream automation can rely on the five-minute window without guessing.
Try Mochify — privacy-first image compression
Tell Mochify what you need in plain language and Magic Flow handles the rest, whether you're on the hosted MCP or running the local binary.
Start Optimizing Free