io.github.theluckystrikePublished by GitHub account theluckystrikev0.23.0Updated Nov 3, 2026
Create zip archives, list their contents with safety flags, and extract without unsafe entries.
McpStamp Zip Archives's hosted MCP server (mcp.zovo.one); no sign-in required; Streamable HTTP; 12 tools.
No AI overview yet: these facts come from the registry entry and the server itself.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/io.github.theluckystrike%2Fzip-archive-create-extract-bomb-guard/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Add this to your client's mcpServers config.
{
"mcpServers": {
"mcpstamp-zip-archives": {
"type": "http",
"url": "https://mcp.zovo.one/mcp/zip"
}
}
}Make a zip, look inside one, and unpack one, in the conversation you are already in. Pack a folder with a glob
(**/*.csv, everything except node_modules). Read the one README out of an archive without unpacking it.
Ask what is inside a zip somebody sent you and be told before you open it: absolute paths, .., symlinks,
duplicate names, and the entry that claims to be 200 MB inside a 199 KB file. Bundle a month of invoices,
quotes and exports into one file to send to an accountant. Everything runs on your machine: no upload, no
account, no API key, and no network call of any kind.
In the official MCP Registry (io.github.theluckystrike/zip-archive-create-extract-bomb-guard).
npm publish for @theluckystrike/mcp-zip is pending, so npx -y @theluckystrike/mcp-zip returns 404 today. Until then, the .mcpb one-click bundle or a clone+build is the working path.
Claude Desktop, ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or
%APPDATA%\Claude\claude_desktop_config.json (Windows):
Claude Code:
Cursor, .cursor/mcp.json:
Reading is never metered. The free tier is a limit on what you write, because an archive somebody sent you is exactly the one you most need to inspect before opening, and a paywall in front of that would be a paywall in front of the safety check.
Get Pro: https://mcp.zovo.one/buy/zip - $19 one time, or $39 for every server in the suite, lifetime. Keys verify offline; nothing is sent anywhere.
The choice was fflate (pure JS, 0 dependencies, synchronous zipSync/inflateSync) against writing a
STORE/DEFLATE writer on node:zlib, which is available with no dependency at all.
The container format is written here either way. This server reads the central directory itself, in
src/zipfile.ts, roughly 200 lines: sizes, names, methods, CRCs, external attributes. It has to, because every
guard in the server is a decision made from those headers before anything is inflated, and a library that
hands back {name: bytes} has already decompressed the bomb by the time you can look at it. So the argument for
a library was never "it saves me the format".
What is left is the compressor, and that is the part not to write. node:zlib would do it, but its raw-deflate
calls are async-first, they carry a thread-pool round trip per call, and the sync ones each build a native
stream; packing 200 small files is 200 of those. fflate's deflateSync is a pure-JS implementation with no
native handle, it packs 200 files in 74 ms (measured below), and it means the package still has no native build
step, which is the rule for this whole suite: npx has to work everywhere.
The trade is stated plainly: fflate builds the archive in one buffer, so this server refuses inputs over 512 MB rather than pretending to stream, and it does not read ZIP64 (over 4 GB or over 65,535 entries), which is refused by name rather than misread.
Every file below was zipped at level 6 on this machine. The "type" column is what a person would call the file; the ratio is what actually happened.
PDF and DOCX barely move, and that is not a surprise once you look inside them: both are already deflate containers, so zipping them again is packaging, not compression. Bundling a month of invoices is worth doing for the one file, not for the space.
The two CSV rows are the interesting pair. Same tool, same shape, same size, 34x apart: the one with forty repeated client names compresses 82.69x, the one with unique values 2.40x. Nothing about "it is a CSV" predicts which one you have.
A compression bomb is refused by ratio, and the obvious instinct is to set that ceiling low, well under the
1022x a zeros file reaches. The table above says why that is wrong: a real CSV export, of the kind
zip_bundle_month collects from the expense tracker, reached 82.69x, which is 83% of the way to a 100x
ceiling and well past a 50x one. A ceiling tuned to be comfortably below a bomb would refuse a real monthly
export, and the person on the other end would learn to pass max_ratio on everything, which turns the guard
off permanently.
So the ratio is the second guard, not the first. The first is the total: the selected entries' declared
uncompressed sizes are added up and compared against a ceiling (1 GB by default, max_total_mb to change it),
because 200 MB out of a 199 KB file is a decision you can make about the archive as a whole without judging any
entry. Both are read from the central directory, so refusing a bomb costs no decompression at all:
fflate.inflateSync(data, { out: new Uint8Array(n) }) looks like the whole answer: cap the buffer, cap the
damage. It is not, and the way it fails is quiet. A 100,000-byte entry inflated into a 10-byte buffer returns
10 bytes and throws nothing. An archive whose header declares 10 bytes for a 100 KB entry would extract as a
10-byte file, reported as a success, with the truncation invisible.
So the buffer bounds the memory and the CRC-32 in the central directory proves the bytes. Every entry this server writes out is checksummed against the header before it reaches the disk, and a mismatch refuses the entry by name. That is the check that turns a lying header from silent data loss into a sentence.
M-series laptop, over stdio, per call, cold store:
Everything stays on your machine. There is no network code in this server at all: no fetch, no HTTP client, no
telemetry. Archives are written where you say, and a small register of what was created lives under
~/.local/share/mcp-servers/zip/ (or $XDG_DATA_HOME). License keys verify offline with a public key.
Zip passwords are not supported, and passing one is refused rather than ignored: the classic zip cipher is broken and AES zip encryption is a vendor extension no two tools agree on, so a "password protected" archive from here would be a false promise.
Built by theluckystrike. Support: [email protected]
Any MCP client (Claude, Cursor, Windsurf, VS Code) can read this repository's documentation directly via GitMCP - no install:
Source: servers/zip/README.md at commit 6535b33
License status
Report this endpoint's licence state for your token as JSON: the product, the tier free or pro, why it is not Pro, and the checkout URL. Call it to explain a free-tier refusal. No arguments, nothing changes.
Takes no parameters.
Activate license
Turn Pro on for this connection with key, an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. Data under your token stays; a wrong or expired key changes nothing. license_status confirms it.
keyrequiredUpload a file or an archive
Send a file to this hosted endpoint. There is no filesystem here, so instead of a path you upload the file once with zip_upload and then pass its name wherever a path is asked for: an archive to zip_list, zip_extract, zip_extract_text or zip_add, a plain file to zip_create. Give exactly one of content_base64 (the file's bytes, the only paste form an archive can take), content (text, for a text file to pack) or url. url: fetch a public file instead of pasting base64 (recommended above about 10 KB): the url is fetched here with a 10 second timeout, at most 3 redirects, public http(s) hosts only, and a 1 MB cap, and a name ending .zip is checked for the PK magic before anything is stored. Uploads are kept for your token between calls; zip_files lists them and zip_delete_upload removes one. The request body cap is 256 KB, so the practical ceiling on a paste is about 190 KB of file once it is base64 inside a JSON-RPC envelope.
urlnamerequiredcontentcontent_base64List uploaded files
List the files stored for your token on this endpoint, with their sizes. These are the names every path argument here resolves against.
Takes no parameters.
Delete an uploaded file
Delete one uploaded file stored for your token. The register rows zip_history lists are kept.
namerequiredCreate a zip archive
Call this tool to pack files uploaded with zip_upload into a new .zip and get a download link valid for one hour. Entry names are always relative, so the archive cannot write outside where it is unpacked.
dirlevelpathsexcludeout_pathrequiredpasswordpatternsoverwriteList a zip archive
Call this tool to list an archive's entries with sizes and ratios and flag what is dangerous: absolute paths, .., symlinks, encrypted entries, duplicate names and bombs. Read-only. Run it before zip_extract.
pathrequiredlimitpatternsmax_ratioExtract a zip archive
Call this tool to unpack an archive; every entry comes back as its own download link valid for one hour. Traversal, absolute-path and symlink entries are refused, a size and ratio cap stops a zip bomb, and dry_run reports exactly what would be written.
pathrequireddry_runout_dirpatternsmax_ratiooverwriteskip_unsafemax_total_mbAdd files to a zip
Call this tool to add files to an existing archive under their own names, or under prefix. A name clash is refused unless replace. An archive holding unsafe entries is refused rather than rewritten.
pathrequiredlevelpathsrequiredprefixreplacepasswordRead one entry as text
Call this tool to read one text entry out of an archive without unpacking anything: give the entry name and the text comes back inline. Binary entries are refused by name rather than printed as noise.
pathrequiredentryrequiredmax_charsBundle a month of documents
Local (stdio) install only. On this hosted endpoint /mcp/invoice, /mcp/quotes, /mcp/expense-tracker, /mcp/docx and /mcp/resume return their documents as one-hour download links and keep no output folder to read, so there is nothing for this tool to bundle. Pack the files with zip_upload plus zip_create instead.
monthdry_runserversout_pathoverwriteArchives created
List the archives created for your token, newest first, with entry counts, sizes and names, plus how much of the free 20 a month is used. Each download link expires after an hour; the row keeps the name.
limit100% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
{ "mcpServers": { "zip": { "command": "npx", "args": ["-y", "@theluckystrike/mcp-zip"] } }}claude mcp add zip -- npx -y @theluckystrike/mcp-zip{ "mcpServers": { "zip": { "command": "npx", "args": ["-y", "@theluckystrike/mcp-zip"] } }}refuse a 500 MB bomb (497.8 KB on disk) 3 ms, nothing inflated, out_dir not even created