zipnative-mcp

Overview Schema Source Related Servers Discussions Admin

Inflate raw DEFLATE (bounded)

inflate_raw

Idempotent

Decompress a raw DEFLATE (RFC 1951) stream with a mandatory output bound that guards against zip bombs while keeping memory constant. Use it on payloads from read_zip_entry raw mode or bare deflate data.

Instructions

Decompress a raw DEFLATE (RFC 1951) stream — e.g. the payload from read_zip_entry mode:'raw' — with a MANDATORY maxOutput bound through zipnative's resumable inflater (constant memory, exact bytesConsumed, trailing bytes reported as leftover; ZIP_INFLATE_OUTPUT_OVERFLOW past the bound). method 'store' is a bounded pass-through; a numeric method id selects a registered codec (none beyond 0 / 8 in this server → ZIP_UNSUPPORTED_METHOD). Output base64 (≤ 50 MiB) or a sandbox file. Use it only for a raw payload or a bare deflate stream; to read an entry's content prefer read_zip_entry mode:'data'.

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": {
      "maxOutput": "<maxOutput>"
    },
    "name": "inflate_raw"
  }
}

Input Schema

Name	Required	Description	Default
`method`	No	'deflate' (default, method 8), 'store' (method 0, bounded pass-through) or a numeric method id for a registered codec.	deflate
`maxOutput`	Yes	Mandatory output bound in bytes: decompression stops with ZIP_INFLATE_OUTPUT_OVERFLOW beyond it (zip-bomb guard). Inline results are further capped at 52428800 bytes, file results at the file cap (ZIPNATIVE_MCP_MAX_FILE_OUTPUT_BYTES, default 4294967296).
`dataBase64`	No	The compressed stream as base64 (e.g. the payload from read_zip_entry mode:"raw"). Exclusive with sourcePath.
`outputMode`	No	'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
`outputPath`	No	Relative path inside the sandbox (only when outputMode='file'); the inflated bytes are raw data, so it must end in .bin, .dat, .raw, .txt, .json, .xml, .md, .csv, .html, .tar or .zip.
`sourcePath`	No	Relative path of a file inside the sandbox holding the compressed stream (streamed). Exclusive with dataBase64.
`allowTrailing`	No	Accept bytes after the end of the deflate stream silently (they are always reported as `leftover`).

Output Schema

Name	Required	Description
`mode`	Yes
`summary`	Yes	inflate_raw summary (the produced bytes are application/octet-stream, not an archive).
`filePath`	No	Sandboxed absolute path (file mode).
`sizeBytes`	Yes
`diagnostics`	Yes	Non-fatal engine concerns (de-duplicated by code + entry, ≤ 200; codes in describe_engine.diagnosticCodes). Empty for a clean archive.
`diagnosticCounts`	No	Occurrences per code, duplicates included.
`diagnosticsTruncated`	No	true when rows beyond 200 were dropped.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.0.1Oct 27, 2026

changedInput schema / properties / maxOutput / description

Previous value: -"Mandatory output bound in bytes: decompression stops with ZIP_INFLATE_OUTPUT_OVERFLOW beyond it (zip-bomb guard). Inline results are further capped at 52428800 bytes, file results at 4294967296."New value: +"Mandatory output bound in bytes: decompression stops with ZIP_INFLATE_OUTPUT_OVERFLOW beyond it (zip-bomb guard). Inline results are further capped at 52428800 bytes, file results at the file cap (ZIPNATIVE_MCP_MAX_FILE_OUTPUT_BYTES, default 4294967296)."

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 / outputPath / description

Previous value: -"Relative path inside the sandbox (only when outputMode='file'); must end in a container extension (.zip recommended)."New value: +"Relative path inside the sandbox (only when outputMode='file'); the inflated bytes are raw data, so it must end in .bin, .dat, .raw, .txt, .json, .xml, .md, .csv, .html, .tar or .zip."

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

First observedv1.0.0Sep 8, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, so the description carries real weight — and it does: mandatory bound enforcement, constant memory, resumable inflater, exact bytesConsumed, trailing bytes surfaced as `leftover`, ZIP_INFLATE_OUTPUT_OVERFLOW on the bound, and 50 MiB inline / file-cap limits. Minor gap: it doesn't say why readOnlyHint is false (a sandbox file can be written), leaving a small inconsistency for the agent to infer from outputMode='file'.

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?

One dense sentence packed with semicolon clauses; front-loaded with the verb, but the parenthetical chains (constant memory, bytesConsumed, leftover, error codes, size caps, method semantics) read as a wall. Information earns its place, but the structure is closer to a spec fragment than to prose an agent can scan.

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 7-parameter bounded-decompression tool with full schema coverage and an output schema, the description covers what the schema cannot: safety bound rationale (zip-bomb guard), error codes, memory profile, and sibling routing. Nothing material is missing for correct invocation.

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 baseline is 3; the description adds value beyond it by explaining that method 'store' is a bounded pass-through (not the schema's 'bounded pass-through' phrase — it adds the bound semantics), linking dataBase64/sourcePath to read_zip_entry mode:'raw', and stating the ≤50 MiB vs. file-cap split. It doesn't restate the exclusivity rules, but those are already in the schema.

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 and resource ('Decompress a raw DEFLATE (RFC 1951) stream') and disambiguates from siblings by naming the exact companion tool and mode (`read_zip_entry mode:'raw'`). An agent can distinguish this from read_zip_entry without opening either schema.

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

Usage Guidelines5/5

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

Gives an explicit positive condition ('only for a raw payload or a bare deflate stream') and an explicit exclusion with the preferred alternative ('to read an entry's content prefer read_zip_entry mode:'data''). The error mapping for unsupported methods (ZIP_UNSUPPORTED_METHOD) also tells the agent when the call isn't the right tool.

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

Deploy Server