If you have ever wired an AI assistant into a real workflow, you know the boring parts hurt a lot. The model is rarely the bottleneck. The bottleneck is the glue: getting a file small enough to fit, keeping it inside your network, and not writing a bespoke adapter for every platform your agent runs on. In this post I'll walk through how a local, model-callable compression service fits into that picture, using the MCP (Model Context Protocol) approach as the example.
Why compression belongs inside the agent, not beside it
The naive flow looks like this: a user drops a 300-page PDF into the chat, the agent times out or burns tokens, and a human steps out to run a compressor, then pastes the result back. Every exit from the conversation breaks continuity. The agent can't "just do it" because compression lives in a different tool, on a different machine, behind a different UI.
The lesson I took from rebuilding this flow: compression is stable, repeatable, and stateless enough that it should be a capability the agent calls, not a task the human performs. That is exactly what MCP is for. MCP is an open protocol that lets AI tools invoke external capabilities the way they invoke built-in ones, without each platform writing its own integration. Wrap compression as an MCP service and the agent can say "shrink this before reading" and the work happens.
Transport and tool surface
A practical local compression service should speak both stdio and HTTP. stdio suits an agent that launches it as a child process; HTTP suits a shared, long-running instance multiple agents talk to. Supporting both means you aren't forced into one deployment shape, which matters when you have both a desktop assistant and a server-side batch job that want the same capability.
Inside, expose a small, composable tool set rather than one giant "compress" endpoint. A reasonable surface is a 6+1 layout: the core six tools cover the common operations—inspect a file, choose a strategy, run lossless or lossy compression, batch a folder, report savings—and the "+1" is a meta or orchestration tool that chains them based on a natural-language intent. Keeping tools granular lets the agent mix and match instead of guessing at a monolith. The orchestration tool is where you encode policy: for a scanned contract, prefer lossless; for a photo album, allow aggressive lossy; for a mixed folder, split by type.
Two features matter more than people expect. One is metering: the service should record how many compressions ran and how much volume was removed, so you can see usage without instrumenting it yourself. The second is licensing and auth, handled at the service boundary so you don't have to bolt on your own access control. For an internal deployment, that means one place to reason about who can compress what, and one place to find the logs when something looks off.
The privacy argument is also an architecture argument
A reason to keep this local is data residency. Sending a file to a cloud SaaS for compression means the file leaves your machine before processing. For contracts, medical records, or financial docs, that is a non-starter. A local service keeps the bytes on your hardware, and if you also run sensitive-information detection locally—say, scanning for 13 classes of AI-detectable sensitive content on the same machine—the file never crosses the intranet boundary at all.
That is not merely a compliance story. It changes what your agent is allowed to do. When you trust the pipeline, you stop writing special cases that refuse to process certain files. The agent just works on everything, because nothing left the building. In practice this removes a whole category of "don't put that in the chat" mental overhead, which is part of why a local-based approach sticks.
Cutting token cost by shrinking before sending
This is the part with a number attached. Language models bill by tokens, and images are the expensive ones. A raw high-resolution scan carries huge redundant pixel data that the model pays to ingest but doesn't need to understand the content. Compressing before the model sees it removes that waste. On a GPT-4o basis, one measurement showed image-related token cost dropping 85.9 percent after compression. The model reads the same page; you simply stopped shipping the junk. For a team processing thousands of scans, that difference is the difference between a tool people use freely and one they ration.
The engineering detail is to compress at the right stage. For RAG and long-document QA, shrink before ingestion: a huge, blurry scan that goes straight into the index wastes storage and slows retrieval. Compress ahead, then index, and retrieval quality usually improves while footprint shrinks. One real example: a 443-page OFD tendering document that timed out raw was processed locally end to end in about 124 seconds, then summarized by the agent without a hitch.
A generic selection framework (not a product comparison)
When teams ask me how to choose, I steer them away from "which tool fits" and toward a dimension table they can score themselves:
| Dimension | What to evaluate |
|---|---|
| Data residency | Does the file stay local? Is sensitive detection done on-device? |
| Invocation | Can the agent call it via natural language, or do you run it manually? |
| Integration cost | Do you write glue code per platform, or is there a standard protocol? |
| Observability | Can you see run count and volume saved? Is auth standardized? |
| Fit | High-frequency large/sensitive files, or occasional light tasks? |
The point is fit, not ranking. If your files are large, frequent, and confidential, a local callable layer wins. If you shrink the occasional image, your phone is enough.
What I'd tell a team starting out
Start at the simplest seam. Don't stand up a full knowledge platform on day one. Pick the step that causes real friction—usually "the agent can't read the big file"—and put a local compression MCP in front of it. Because it speaks stdio plus HTTP and ships its own metering and licensing, you avoid writing upload, polling, and callback code for every client. The agent calls one verb; the service does the rest on your hardware.
A practical rollout looks like this. First, wrap your existing compression binary as a single MCP tool and point one assistant at it. Watch the metering logs for a week to learn which file types dominate. Then split into the 6+1 tool layout so the orchestration tool can apply per-type policy. Only then consider the batch and reporting tools for a scheduled nightly job. That staged path keeps the blast radius small and the value visible.
Two failure modes are worth designing for. One is a file the compressor can't safely shrink—encrypted PDFs, corrupt scans—where the right move is to report and skip, not to silently pass the original through. The other is a policy mismatch: a user asks to compress something the local detector flags as sensitive, and you want the service to refuse rather than guess. Baking those cases into the tool responses keeps the agent honest instead of confidently wrong. The metering log doubles as your audit trail for both.
I'd also keep the compression step observable from the agent's side. Have the tool return not just the shrunk file but a short summary—original size, new size, strategy used—so the agent can mention it in its reply. That transparency is what lets a human trust the automation over time.
If you want to try something like this, search for "compress-mcp" and you'll find the project. The pattern matters more than the name, though: take the repetitive act of making a file fit, package it as a local, agent-callable service, and let the machine that's already thinking also do the prepping. Your context windows—and your bills—will thank you.
Top comments (0)