zipnative-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WORKERS | No | Worker pool size for parallel compression in create_zip / modify_zip. When unset, the engine's default pool size is used. | |
| MAX_ENTRIES | No | Operator ceiling for the maximum number of entries accepted by the server, overriding the engine's default limit. | |
| ZIPNATIVE_MCP_PORT | No | TCP port for Streamable HTTP mode. When set, the server listens on 127.0.0.1:<port>/mcp instead of using stdio. When unset, the server runs over stdio (default, 256 MiB frames). | |
| MAX_UNCOMPRESSED_BYTES | No | Operator ceiling for the maximum uncompressed byte count accepted by the server, overriding the engine's default limit. | |
| ZIPNATIVE_MCP_CACHE_DIR | No | Opt-in SHA-256 response cache directory. When set, identical requests (same tool, same inputs) return a cached response instead of re-executing. | |
| ZIPNATIVE_MCP_HTTP_TOKEN | No | Bearer token required for HTTP requests (Authorization: Bearer <token>). Only meaningful when ZIPNATIVE_MCP_PORT is set; without this variable HTTP mode allows unauthenticated loopback requests. The Host/Origin loopback guard still applies. | |
| ZIPNATIVE_MCP_OUTPUT_DIR | No | Sandbox directory for file-mode archive output and zipPath/sourcePath inputs. File I/O is disabled unless this variable is set; absolute paths, traversal, non-container extensions and NUL bytes are all rejected, and the real path of every file read and parent written must stay inside the sandbox (a planted symlink or junction is SECURITY_VIOLATION on both sides). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| inspect_zipA | Read-only archive report in ONE call: size, entry / file / directory counts, Zip64, comment, compressed vs uncompressed totals, per-method counts, encrypted / symlink / data-descriptor / Zip64 / cp437 / duplicate / unsafe-name counts, date range, a |
| list_zip_entriesA | Read-only central-directory inventory without decompressing anything: every entry (duplicates included) in directory order as a full row — name + encoding, sizes, ratio, CRC-32, method, timestamp, decoded flags, Unix mode, symlink, Zip64, data descriptor, host system, offsets, named extra fields, the sanitized path an extraction would use (null = unsafe name), comment. |
| read_zip_entryA | Read ONE entry without extracting the archive, by |
| verify_zipA | Deep verification in one call — zipnative's verifyZip report verbatim: eager structural validation, then every entry's CRC-32 / size / local-header agreement. |
| extract_zipA | Extract with every engine guard ON unless you name the relaxation: zip-slip / absolute / drive / UNC / NUL / ADS / Windows-device names → ZIP_PATH_TRAVERSAL (rejectTraversal:false SKIPS them, listed in |
| scan_zip_forwardA | Walk LOCAL headers in stream order with bounded memory (zipnative's central-directory-less reader). The only tool that works on a truncated archive or a stream cut mid-way (it cannot skip an SFX prefix: the stream must start at a local header) — and the only one whose result is NOT authoritative: forward iteration trusts local headers ALONE, so a hostile archive can present different content here than inspect_zip / list_zip_entries report (the upload-scanner differential). Prefer those tools whenever the whole archive is available; use this one for forensics ( |
| sanitize_entry_pathsA | Apply zipnative's single traversal gate |
| create_zipA | Write a ZIP from inline entries ( |
| modify_zipA | Edit an existing archive without recompressing anything: operations add / replace / remove / rename / setComment applied in order. mode 'append' (default) = save(): the original bytes stay verbatim and edits are appended — fast and byte-preserving, BUT removed or replaced payloads REMAIN in the file (data remanence: recoverable by anyone; a ZIP_DEAD_BYTES_RATIO diagnostic fires past 50 % dead bytes, and 7-Zip is known to read the stale payload). mode 'compact' = saveCompact(): a rewrite without the dead bytes, entries SORTED by raw name bytes (an insertion-ordered layout — EPUB mimetype first, JAR manifest first — is not kept; 'append' keeps it), still no recompression, removed data truly gone, SFX prefix dropped; add |
| canonicalize_zipA | Make ANY archive reproducible: zipnative's canonicalizeZip() rewrites a Gradle, Maven, zip, Explorer or 7-Zip archive into the canonical deterministic form zipnative itself writes — entries sorted by raw name bytes, one timestamp (the DOS epoch, or a pinned |
| merge_zipA | Merge 1–32 archives into one WITHOUT recompressing anything: zipnative's addFromReader() transplants each entry's compressed bytes with its method, CRC, sizes, timestamp, attributes, comment and extra fields, in O(bytes copied). Each source is zipBase64 XOR zipPath with an optional filter. Every entry is CRC- and size-checked before it is copied (verify, default true), so a corrupt payload is refused with its ZIP_* code instead of being propagated; an entry whose method has no codec here (ZIP_UNSUPPORTED_METHOD) and encrypted entries are refused. A foreign name the writer will not accept (e.g. a bsdtar './'-prefixed entry) is ZIP_INVALID_ENTRY_NAME — exclude it with that source's filter. Name collisions: onConflict 'error' (default, ZIP_DUPLICATE_ENTRY_NAME), 'first' or 'last' (summary.dropped lists what was not kept). order 'canonical' (default) sorts like create_zip. Run canonicalize_zip on the result for the full canonical form. Output base64 or a sandbox file (streamed). |
| compute_crc32A | The ZIP checksum (IEEE 802.3 CRC-32, the engine's slice-by-8 implementation) of inline bytes / text or a sandbox file (streamed in 1 MiB chunks). |
| inflate_rawA | Decompress a raw DEFLATE (RFC 1951) stream — e.g. the payload from read_zip_entry mode:'raw' — with a MANDATORY |
| describe_engineA | Offline preflight (no archive needed): server / engine / tool-API versions, the deflate tier in use and the pinned deterministic tier, runtime codecs (node:zlib, CompressionStream, DecompressionStream) and worker threads, the codec registry, the engine's default |
| draft_governance_issueA | Produce a LOCAL GitHub issue draft + compliance report for zipnative / zipnative-mcp and NEVER submit it — the agent drafts, a human reviews and files it under their own identity (Human-In-The-Loop contract, .github/AGENT_RULES.md). No GitHub write path and no network path exist in this server. The draft is checked against the zero-dependency + reproduction policy; a policy violation (a new runtime dependency, duplicateSearchPerformed:false) is GOVERNANCE_VIOLATION; a missing field (reproduction included) is VALIDATION_ERROR. targetRepo 'zipnative' for engine behaviour (parsing, writing, limits, codecs), 'zipnative-mcp' for wrapper behaviour (schemas, sandbox, transport). Returns markdown inline (outputMode:'file' also writes a .md inside the sandbox). Use it only after reproducing a defect — for questions read describe_engine / docs/AGENT_CONTRACT.md instead. Present the draft AND the report to the user, then STOP. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| governance_contract | The non-negotiable AI-governance / Human-In-The-Loop contract for zipnative-mcp: the agent is a draftsman, the human is the only gate, zero runtime dependencies, no autonomous GitHub writes, no network. |
| draft_issue_workflow | Step-by-step workflow for drafting a GitHub issue with the draft_governance_issue tool and handing it to a human for review and submission. |
| secure_extraction | Recipe for taking in an archive from an untrusted source: verify, inspect with CI checks, dry-run the plan, extract with every guard on, and when (not) to relax a guard. |
| reproducible_archive | How to obtain the same bytes from repeated create_zip calls and across runtimes: pinned dates, canonical order, the deterministic encoder pin, and how to prove it. |
| incremental_update | How modify_zip edits without recompression, what append mode leaves behind (remanence, the 7-Zip stale-payload differential), and when to compact. |
| forensic_scan | When and how to use scan_zip_forward, what its local-headers-only result can and cannot tell you, and how to reconcile it with the authoritative readers. |
| verify_before_trust | The minimal read-only sequence (verify_zip → inspect_zip checks → list → dry run) to run on any archive before extracting it. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Most tools target clearly distinct operations (create/modify/canonicalize/merge/extract/inflate/CRC), and descriptions explicitly cross-reference when to prefer one over another. The one soft spot is the read-only inspection cluster — inspect_zip, list_zip_entries, verify_zip and scan_zip_forward all report on an archive, and inspect_zip already performs eager structural validation that overlaps conceptually with verify_zip, so selection requires careful reading rather than being instantly obvious.
Every name is snake_case with a leading verb and an object noun: inspect_zip, list_zip_entries, read_zip_entry, verify_zip, extract_zip, create_zip, modify_zip, canonicalize_zip, merge_zip, compute_crc32, sanitize_entry_paths, describe_engine, draft_governance_issue. The pattern is predictable and the verb choice telegraphs the action.
15 tools sits at the top of the well-scoped band and each one covers a genuinely different lifecycle stage (inspect, list, read, verify, extract, create, modify, canonicalize, merge, plus utilities). Nothing looks redundant or padded; even the odd-seeming draft_governance_issue is a deliberate, documented HITL workflow.
Coverage is unusually thorough: full read/write lifecycle, compaction, determinism rewriting, merging, path sanitization, CRC utilities and engine introspection, with removal reachable via modify_zip. The notable gap is encryption — encrypted entries are explicitly refused rather than decrypted — and there is no tool to list or delete files already written to the sandbox output directory.