Skip to main content
Glama
Nizoka

zipnative-mcp

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

create_zip
Idempotent

Creates ZIP archives from text, base64, or file entries with configurable compression and timestamps. Supports deterministic reproducible output, streaming, and resource limits for safe programmatic use.

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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
orderNo'canonical' (default): entries sorted by raw UTF-8 name bytes (reproducible). 'insertion': call order preserved (EPUB / JAR mimetype-first layouts).canonical
limitsNoOverride 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.
strictNoEscalate the first engine diagnostic (prepended data, duplicate name, name mismatch, …) to a ZIP_STRICT_DIAGNOSTIC error instead of reporting it.
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) 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.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

TableJSON Schema
NameRequiredDescriptionDefault
modeYes
summaryYescreate_zip summary.
filePathNoSandboxed absolute path (file mode).
sizeBytesYes
diagnosticsYesNon-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.
diagnosticCountsNoNumber of diagnostics received per code (counts every occurrence, including de-duplicated ones).
diagnosticsTruncatedNoPresent (true) when more than 200 distinct diagnostics were dropped from `diagnostics`.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

This is a remarkably transparent description. It discloses default reproducibility semantics (canonical order, DOS-epoch timestamps), how to opt out (defaultDate:'now'), the exact meaning of summary.deterministic (true only with compression.deterministic:true), the behavior of Zip64 (emitted on overflow), output mode constraints (≤50 MiB base64, streamed file never overwritten), and conformance to ISO/IEC 21320-1. Annotations provide idempotentHint=true, and the description adds nuance that idempotency is runtime-specific unless deterministic:true is set — not a contradiction but a valuable clarification. It far exceeds the annotation coverage.

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

Conciseness2/5

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

The description is a single dense paragraph with many clauses separated by semicolons and parentheses. While every sentence adds information, it is not front-loaded and is far longer than needed. The title already conveys the determinism point, yet the description repeats it. For a tool with 12 parameters and a rich schema, some verbosity is justified, but this reads more like a spec dump than a concise guide. It would benefit from bullet points or a breakdown by concern.

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?

For a tool of this complexity (12 parameters, nested objects, multiple output modes, determinism controls, security limits), the description is exceptionally complete. It covers output formats and limits, sandbox behavior, worker parallelism, diagnostics (ZIP_TIMESTAMP_NOT_PINNED, ZIP_STRICT_DIAGNOSTIC), Zip64 conditions, and conformance validation. The output schema exists and the description complements it without redundancy. Nothing an agent needs to invoke this 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?

The schema has 100% description coverage with detailed explanations for every parameter, so the baseline is 3. The description adds value beyond the schema by explaining cross-cutting behavior: how order relates to EPUB/JAR, when Zip64 triggers, the meaning of summary.deterministic, and the worker-pool byte-identity guarantee. It doesn't simply repeat parameter docs but gives operational context, justifying a 4.

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

Purpose5/5

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

The description opens with a clear verb and resource: 'Write a ZIP from inline entries...' It lists the content sources (dataBase64, text, sourcePath, directory) and distinguishes itself from the sibling tools by being the only creation tool in a list dominated by inspection, extraction, and modification. The title also clarifies reproducibility, making the tool's core purpose unambiguous.

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?

The description explicitly states what the tool does and covers when to use it, but it does not name alternatives or exclude scenarios. It mentions that 'parallel' is 'only worth it for many large entries' and that 'stream:true' is for bounded memory, which gives usage hints. However, it doesn't say 'use this instead of X' — that is left implicit given the sibling list. The lack of explicit exclusions keeps it from a 5.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Nizoka/zipnative-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server