Ziplark
Free cross-platform archiver: GUI, CLI, and an MCP server
8 followers
Free cross-platform archiver: GUI, CLI, and an MCP server
8 followers
Ziplark is a free, open-source archiver on one small Rust engine, driven three ways: a desktop app, a CLI, and an MCP server. Reads ZIP, RAR5, 7z, tar, ISO; creates ZIP/7z/tar with AES-256. Cross-platform, zip-slip-safe, tiny. The first archiver an LLM can drive.
Free
Launch Team
Dropbox SignSimple, secure eSignatures for the way your team works.
Promoted
Curious how the MCP server actually handles large archives without ballooning context windows, any plans for streaming responses or chunked reads so an LLM can poke through a 10GB ISO without choking?
@glayuranlakuti Good question — and it's the one thing I actually changed because of it.
Listing is paged now: ziplark_list returns at most limit entries (default 200) starting at offset, always alongside the archive's true total_entries — so listing a 200,000-entry ISO costs the same context as listing a small ZIP. When the result is truncated it also carries a top_level summary: entry counts grouped by directory, descending past a single root, so an agent can see the shape of a huge archive without paging through it at all. And since paging is usually the wrong move, include filters before paging (glob or substring), with a dirs flag for files-only or directories-only.
On the data side nothing is ever read into the context: extraction streams to disk, and ziplark_extract takes include + exact, so an agent pulls out exactly the two files it wants from a 10 GB archive instead of the whole thing. ziplark_test verifies by decompressing and discarding — no temp copy, no bytes returned.
All of that is on main now and ships in the next build. Thanks for asking the question that pushed it.
Rust-based archiver that handles weird formats without bloat, and the MCP server angle is genuinely useful for piping archives into agent workflows. Caught it zip-slip safe out of the box too, which is more than I can say for most tools I have tried.
@glhanfy2w Thanks — the zip-slip guard is the part I'm most paranoid about: it checks the entry name and what is actually on disk, so a symlink planted by an earlier entry of the same archive can't be used to redirect a later write. Since launch I found one more way through it — a directory entry landing where a symlink already sits, which mkdir -p happily follows out of the destination — so directory entries now go through the same on-disk check, in every format.