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(): canonical rewrite, still no recompression, removed data truly gone, SFX prefix dropped. No edits and an unchanged comment return the same bytes ( |
| 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 violation (new runtime dependency, missing reproduction, duplicateSearchPerformed:false) throws GOVERNANCE_VIOLATION. 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 / AGENTS.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 13 tools
Every tool has a clearly distinct purpose: summary vs inventory vs verification vs content reading vs extraction vs creation vs modification vs low-level utilities (CRC, inflate) vs path sanitization vs engine introspection vs governance drafting. The descriptions explicitly state when to prefer one over another (e.g., 'Prefer inspect_zip for a one-shot summary'), eliminating ambiguity.
All tool names follow a consistent verb-first snake_case pattern (inspect, list, read, verify, extract, scan, sanitize, create, modify, compute, inflate, describe, draft). Even multi-word names like scan_zip_forward and sanitize_entry_paths adhere to the convention, making the pattern predictable.
13 tools is well within the ideal 3-15 range and each tool earns its place: comprehensive ZIP handling (inspect, list, read, verify, extract, create, modify) plus necessary low-level utilities (CRC, inflate) and governance/introspection tools. The scope is well-matched to the server's purpose without bloat.
The surface covers the full lifecycle: create (create_zip), read (list_zip_entries, read_zip_entry, inspect_zip), update (modify_zip with add/replace/rename), delete (modify_zip remove), verification (verify_zip), security (sanitize_entry_paths, scan_zip_forward for forensics), and even low-level operations (compute_crc32, inflate_raw). No obvious gaps exist for a ZIP-focused server.