Skip to main content
Glama
zipnative-mcp

zipnative-mcp

Create archive (reproducible; deterministic:true for cross-runtime identical bytes)

create_zip
Idempotent

Create ZIP archives from inline text, base64 payloads, or sandbox files, with reproducible output, compression controls, and streaming for large entries.

Instructions

Write a ZIP from inline entries (dataBase64 | text | sourcePath in the sandbox, or directory:true). Reproducible by default: canonical order (raw UTF-8 name bytes), DOS-epoch timestamps, UTF-8 names, constant attributes — defaultDate:'now' or per-entry date opts out (ZIP_TIMESTAMP_NOT_PINNED diagnostic). compression {method store|deflate, level 0–9, deterministic:true = pinned pure-TS encoder ⇒ identical bytes on every runtime} at archive or entry level; order:'insertion' for EPUB / JAR (mimetype first, stored); comment, per-entry comment / unixMode / externalAttributes / raw extraFields. stream:true on a sourcePath feeds the file through addStream (data-descriptor layout, bounded memory). parallel compresses with the worker pool — byte-identical output. Zip64 is emitted exactly when a field overflows. Output base64 (≤ 50 MiB) or a sandbox file (streamed, never overwritten); summary.deterministic is true ONLY with compression.deterministic:true (cross-runtime identity); a default call is reproducible on the same runtime (deflateTier 'node-zlib') and reports false; sha256 (includeSha256, base64 and file modes) is the proof. Every archive it writes is ISO/IEC 21320-1 conformant (CI-validated).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "entries": "<entries>"
    },
    "name": "create_zip"
  }
}

Input Schema

NameRequiredDescriptionDefault
orderNo'canonical' (default): entries sorted by raw UTF-8 name bytes (reproducible). 'insertion': call order preserved (EPUB / JAR mimetype-first layouts).canonical
limitsNoPer-call override of zipnative's security bounds (CWE-400/409); absent keys keep the engine defaults (describe_engine.defaultLimits). A value above its operator ceiling is LIMIT_CEILING_EXCEEDED. Raise only for trusted input.
strictNoTurn the first engine diagnostic into a ZIP_STRICT_DIAGNOSTIC error.
commentNoArchive comment (UTF-8, ≤ 65535 bytes).
entriesYesThe entries to write (0–100000; an empty array writes a valid empty archive). Each takes exactly one of dataBase64 / text / sourcePath, or directory: true.
parallelNoCompress with the worker pool (zipnative/worker). Byte-identical to the sequential writer; only worth it for many large entries. `workers` 0 keeps everything on the calling thread.
chunkSizeNofile mode: output chunk size for the streaming assembler (default 64 KiB). Never changes the bytes.
outputModeNo'base64' (default): inline embedded resource (≤ 50 MiB; the bytes appear in both its data: uri and its blob). 'file': written into the sandbox (never overwrites; ≤ ZIPNATIVE_MCP_MAX_FILE_OUTPUT_BYTES, default 4 GiB) and returned as a resource_link — far fewer tokens.base64
outputPathNoRelative path inside the sandbox (only when outputMode='file'); must end in a container extension (.zip recommended).
compressionNoCompression settings. `method` 'deflate' (default) or 'store'; `level` 0–9 (default 6); `deterministic: true` pins the pure-TS encoder so the bytes are identical on every runtime (slower).
defaultDateNoTimestamp for entries that set no `date`: an ISO-8601 instant (1980-01-01 … 2107-12-31, 2-second DOS granularity) or 'now' (wall clock — emits the ZIP_TIMESTAMP_NOT_PINNED diagnostic and makes the bytes non-reproducible). Omitted: the DOS epoch 1980-01-01T00:00:00 (reproducible).
includeSha256NoAdd `summary.sha256` of the produced bytes (determinism proofs).

Output Schema

NameRequiredDescriptionDefault
modeYes
summaryYescreate_zip summary.
filePathNoSandboxed absolute path (file mode).
sizeBytesYes
diagnosticsYesNon-fatal engine concerns (de-duplicated by code + entry, ≤ 200; codes in describe_engine.diagnosticCodes). Empty for a clean archive.
diagnosticCountsNoOccurrences per code, duplicates included.
diagnosticsTruncatedNotrue when rows beyond 200 were dropped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed18 schema fields changedv1.0.1
    • changedInput schema / properties / entries / items / properties / stream / description
      Previous value: -"With sourcePath: feed the file through addStream (bounded memory, data-descriptor layout; entries > 4 GiB refused). The archive is then assembled by streaming."New value: +"With sourcePath: feed the file through addStream (bounded memory, data-descriptor layout). The archive is then assembled by streaming. An entry that crosses 4 GiB is refused with ZIP_UNSUPPORTED_ZIP64_STREAMING unless zip64: true."
    • addedInput schema / properties / entries / items / properties / zip64
      Added value: +{
      +  "default": false,
      +  "description": "stream: true only (zipnative 1.1.0 AddEntryOptions.zip64): write this streamed entry in the Zip64 streaming layout (APPNOTE 4.3.9.2: version 45, a Zip64 extra in the local header, a 24-byte data descriptor) so it may exceed 4 GiB. An opted-in entry below 4 GiB still carries the Zip64 records, which some streaming readers (Java's ZipInputStream) cannot read — opt in only for entries that may cross 4 GiB. The archive in a file is bounded by ZIPNATIVE_MCP_MAX_FILE_OUTPUT_BYTES (default 4 GiB); compression.deterministic caps a streamed entry at 2 GiB.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / limits / description
      Previous value: -"Override zipnative's named security bounds for this call (CWE-400 / CWE-409 guards). Every key is optional; absent keys keep the engine defaults (maxEntries 100000, maxEntryUncompressedSize 1 GiB, maxTotalUncompressedSize 8 GiB, maxCompressionRatio 1024, maxNameBytes 4096, maxExtraFieldBytes 65535, maxCommentBytes 65535, maxCentralDirectoryBytes 256 MiB). Values above the operator ceilings (ZIPNATIVE_MCP_MAX_UNCOMPRESSED_BYTES, ZIPNATIVE_MCP_MAX_ENTRIES) are refused with LIMIT_CEILING_EXCEEDED. Raise a bound for trusted input only."New value: +"Per-call override of zipnative's security bounds (CWE-400/409); absent keys keep the engine defaults (describe_engine.defaultLimits). A value above its operator ceiling is LIMIT_CEILING_EXCEEDED. Raise only for trusted input."
    • changedInput schema / properties / limits / properties / maxCentralDirectoryBytes / description
      Previous value: -"Maximum central-directory size in bytes."New value: +"Bytes."
    • changedInput schema / properties / limits / properties / maxCommentBytes / description
      Previous value: -"Maximum comment length in bytes."New value: +"Bytes."
    • changedInput schema / properties / limits / properties / maxCompressionRatio / description
      Previous value: -"Maximum declared uncompressed/compressed ratio for entries >= 1 KiB compressed (zip-bomb guard)."New value: +"Declared ratio (entries ≥ 1 KiB compressed)."
    • changedInput schema / properties / limits / properties / maxEntries / description
      Previous value: -"Maximum central-directory entry count."New value: +"Entries."
    • addedInput schema / properties / limits / properties / maxEntryCompressedSize
      Added value: +{
      +  "description": "Bytes, one compressed payload fetched by the byte-range reader (access range).",
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • changedInput schema / properties / limits / properties / maxEntryUncompressedSize / description
      Previous value: -"Maximum decompressed size of one entry, bytes."New value: +"Bytes, one entry decompressed."
    • changedInput schema / properties / limits / properties / maxExtraFieldBytes / description
      Previous value: -"Maximum extra-field block length in bytes."New value: +"Bytes."
    • changedInput schema / properties / limits / properties / maxNameBytes / description
      Previous value: -"Maximum entry-name length in bytes."New value: +"Bytes."
    • changedInput schema / properties / limits / properties / maxTotalUncompressedSize / description
      Previous value: -"Maximum total decompressed size across an extraction, bytes."New value: +"Bytes, all entries decompressed."
    • changedInput schema / properties / outputMode / description
      Previous value: -"'base64' (default) returns the bytes inline as an embedded resource (≤ 50 MiB). 'file' writes them inside ZIPNATIVE_MCP_OUTPUT_DIR (never overwrites; ≤ 4 GiB, streamed) and returns a resource_link."New value: +"'base64' (default): inline embedded resource (≤ 50 MiB; the bytes appear in both its data: uri and its blob). 'file': written into the sandbox (never overwrites; ≤ ZIPNATIVE_MCP_MAX_FILE_OUTPUT_BYTES, default 4 GiB) and returned as a resource_link — far fewer tokens."
    • changedInput schema / properties / strict / description
      Previous value: -"Escalate the first engine diagnostic (prepended data, duplicate name, name mismatch, …) to a ZIP_STRICT_DIAGNOSTIC error instead of reporting it."New value: +"Turn the first engine diagnostic into a ZIP_STRICT_DIAGNOSTIC error."
    • changedOutput schema / description
      Previous value: -"Result of an archive-producing tool. base64 mode: the archive arrives as an embedded `resource` content block (not duplicated here); file mode: `filePath` + a resource_link."New value: +"Archive result: base64 mode = an embedded `resource` block (not repeated here); file mode = `filePath` + a resource_link."
    • changedOutput schema / properties / diagnosticCounts / description
      Previous value: -"Number of diagnostics received per code (counts every occurrence, including de-duplicated ones)."New value: +"Occurrences per code, duplicates included."
    • changedOutput schema / properties / diagnostics / description
      Previous value: -"Non-fatal conformance concerns the engine raised while parsing or writing (de-duplicated by code + entry, at most 200). Empty for a clean archive. Codes: ZIP_PREPENDED_DATA, ZIP_MULTIPLE_EOCD, ZIP_NAME_MISMATCH, ZIP_UNICODE_PATH_CONFLICT, ZIP_INVALID_UTF8_NAME, ZIP_DUPLICATE_NAME, ZIP_EXTRA_FIELD_MALFORMED, ZIP_ZIP64_EXTRA_IGNORED, ZIP_TIMESTAMP_NOT_PINNED, ZIP_NONDETERMINISTIC_CODEC, ZIP_DEAD_BYTES_RATIO."New value: +"Non-fatal engine concerns (de-duplicated by code + entry, ≤ 200; codes in describe_engine.diagnosticCodes). Empty for a clean archive."
    • changedOutput schema / properties / diagnosticsTruncated / description
      Previous value: -"Present (true) when more than 200 distinct diagnostics were dropped from `diagnostics`."New value: +"true when rows beyond 200 were dropped."
  2. First observedv1.0.0

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare write/idempotent/non-destructive; the description adds the parts that actually matter: default output is reproducible but not cross-runtime identical, summary.deterministic is true ONLY with compression.deterministic:true, sha256 is the proof, file mode never overwrites, base64 capped at 50 MiB. It also discloses diagnostics and ISO/IEC 21320-1 conformance, which no structured field conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is correctly front-loaded in sentence one, but the rest is a single dense run-on paragraph of ~200 words mixing reproducibility, streaming, Zip64, compression, parallelism, output modes and conformance. Most clauses carry information an agent needs, though several duplicate the schema descriptions, and the absence of any breaks makes scanning harder than it should be for a 12-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return-value explanation is properly omitted; annotations cover the safety profile; schema descriptions are complete. The description closes the remaining gaps an agent would otherwise hit — token cost of base64 vs file mode, size ceilings, and the determinism contract — so nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description still adds synthesis the schema does not state in one place — the interaction between defaultDate:'now' and the ZIP_TIMESTAMP_NOT_PINNED diagnostic, and why a default call reports deterministic:false while 'insertion' ordering exists for EPUB/JAR layouts. Some of it restates schema text nearly verbatim (compression.deterministic), capping it below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb+resource ('Write a ZIP from inline entries') and enumerates the four mutually exclusive input modes, so an agent immediately knows what the tool produces. It stops short of naming the sibling it is not — modify_zip (edit existing) and canonicalize_zip (rewrite for reproducibility) — so the boundary with those tools must be inferred.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Rich conditional guidance for option choice: 'order:"insertion" for EPUB / JAR (mimetype first, stored)', 'stream:true on a sourcePath', 'parallel ... only worth it for many large entries', and 'opt in only for entries that may cross 4 GiB' (that last caveat lives in the schema). What is missing is explicit tool-routing ('use modify_zip instead when the archive already exists').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.