Skip to main content
Glama
zipnative-mcp

zipnative-mcp

Merge archives (no recompression)

merge_zip
Idempotent

Merge 1–32 ZIP archives into one without recompressing, copying selected entries intact with CRC checks and name-conflict handling.

Instructions

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

Input Schema

NameRequiredDescriptionDefault
orderNo'canonical' (default): entries sorted by raw name bytes, as create_zip writes them; 'insertion': the sources' order, then each source's central-directory order.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.
verifyNoDecompress each entry once to check its CRC and size before copying it (secure by default: a corrupt entry is refused with ZIP_CRC_MISMATCH / ZIP_SIZE_MISMATCH instead of being propagated). false trusts the sources — their bytes travel as they are.
commentNoArchive comment of the result (UTF-8, ≤ 65535 bytes). Default none — the sources' comments are not merged.
sourcesYesThe archives to merge, in order (1–32; total ≤ 1073741824 bytes, inline payloads ≤ 134217728 bytes in all). Each is zipBase64 XOR zipPath, with an optional filter selecting the entries taken from it (directories are kept unless the filter excludes them).
onConflictNoTwo entries with the same name: 'error' (default) — the engine refuses the second with ZIP_DUPLICATE_ENTRY_NAME; 'first' / 'last' — keep the first / last occurrence across the sources in order, the others are reported in summary.dropped.error
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).
includeSha256NoAdd `summary.sha256` of the produced bytes.

Output Schema

NameRequiredDescriptionDefault
modeYes
summaryYesmerge_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. Addedv1.0.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover safety/idempotency; the description adds substantial behavior: O(bytes copied) cost model, CRC/size pre-verification with verify default true, the exact ZIP_* refusal codes, refusal of unsupported-method and encrypted entries, and collision resolution semantics. It also discloses the non-overwriting file output and sandbox constraints — far beyond the annotation surface.

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

Conciseness4/5

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

Front-loaded with the defining property (no recompression), then progressively narrows to errors, collisions, ordering and output. It is dense and clause-heavy in the middle, but nearly every sentence carries decision-relevant information.

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 10-parameter, nested-object mutation tool with an output schema, the description covers the cost model, failure modes and their codes, ordering, conflict policy and output-size ceilings. Nothing an agent needs 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 earns credit by explaining outcomes rather than formats — onConflict 'first'/'last' populating summary.dropped, the canonical-vs-insertion ordering, and the XOR exclusivity of zipBase64/zipPath. It does not document the limits sub-object (deferring to describe_engine), which the schema already covers.

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?

States a specific verb+resource ('Merge 1–32 archives into one WITHOUT recompressing') and immediately names the mechanism (addFromReader byte transplant). It distinguishes itself from siblings by referencing create_zip (ordering parity) and canonicalize_zip (full canonical form).

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?

Gives clear operating context (already-compressed sources, filters, onConflict choices) and points to canonicalize_zip as the follow-up when full canonical form is wanted. It stops short of an explicit 'use this instead of create_zip when...' rule, so the create-vs-merge decision is inferred from naming rather than stated.

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