Skip to main content
Glama
Nizoka

zipnative-mcp

Scan forward (truncated / unseekable streams — NOT authoritative)

scan_zip_forward
Read-onlyIdempotent

Scans ZIP archives by reading local file headers in stream order, enabling inspection of truncated or incomplete files with bounded memory. Returns entry inventory and optional payload verification for forensic analysis.

Instructions

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 (tolerateTruncation:true returns the partial inventory + error). data 'none' skips payloads, 'verify' decompresses to check CRCs, 'include' returns them (inline caps). stoppedAt tells you whether a central directory was reached. Names are NOT sanitized — sanitizedPath shows what the extraction gate would use.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo'none' (default): skip payloads (a data-descriptor entry still costs a full decompress-and-discard); 'verify': decompress every kept entry so CRC and sizes are checked; 'include': also return the content as base64 (inline caps apply).none
fieldsNoDot-path projection applied after verbosity (e.g. ['entryCount', 'entries.name']); array segments map over elements; unmatched paths are reported in _meta.unmatchedFields.
filterNoSelect entries by name. `names` (exact, case-sensitive), `prefix` (path prefix) and `glob` (patterns: `*` within a segment, `**` across segments, `?` one character; a pattern without `/` matches at any depth, a trailing `/` matches a whole subtree) are ANDed when several are given; `includeDirectories` (default false) keeps explicit directory entries.
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.
zipPathNoRelative path of an archive inside the ZIPNATIVE_MCP_OUTPUT_DIR sandbox (no absolute paths, no '..'; container extensions only: .zip .jar .docx .epub …). Exclusive with zipBase64. Lets a create/modify → verify/extract chain avoid re-sending the bytes.
verbosityNo'summary' returns only the scalar verdict fields (drops arrays and payloads) — the token-frugal form.full
zipBase64NoThe archive bytes as base64 (exactly once; a data: URI prefix is tolerated). Exclusive with zipPath. Decoded size ≤ 128 MiB.
maxEntriesNoStop after this many local headers (bounded work on an unbounded stream). Default 10000, clamped to the operator ceiling ZIPNATIVE_MCP_MAX_ENTRIES; an explicit value above the ceiling is refused (LIMIT_CEILING_EXCEEDED).
tolerateTruncationNotrue: a truncated / corrupt stream ends the scan with `stoppedAt:"error"` and the partial inventory (forensics) instead of failing the call.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
namesNosummary only: the kept entry names.
trustNoConstant reminder: nothing here was cross-checked against a central directory.
entriesNo
keptCountNo
stoppedAtNo'central-directory' is the normal end of a complete archive; 'eof' means the stream ended before any central directory (truncated or CD-less); 'max-entries' means more local headers remained.
truncatedNotrue when the stream ended without reaching a central directory.
entryCountNoLocal headers seen (before the filter).
inputBytesNo
maxEntriesNoThe header budget in force (after clamping to the operator ceiling).
diagnosticsNoNon-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.
bytesDeliveredNoBytes handed to the forward reader.
diagnosticCountNosummary only: number of distinct diagnostics.
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.9/5.0
Behavior5/5

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

Transparently discloses non-authoritative behavior ('result is NOT authoritative'), the risk of hostile archives, and concrete behaviors like tolerateTruncation returning partial inventory and strict mode escalating diagnostics. No contradiction with the readOnly/idempotent annotations.

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?

The description is dense and well-structured, front-loading the core purpose and caveats before parameter details. It is slightly verbose but every sentence carries necessary qualification for a security-sensitive 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?

Covers the primary use case, limitations, security bounds, and relationship to sibling tools. It also references output fields like stoppedAt and sanitizedPath, making the behavior understandable without needing to inspect the output schema.

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

Parameters5/5

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

Although the schema already has 100% coverage, the description adds valuable semantic context, such as explaining data modes ('none' skips payloads, 'verify' decompresses for CRC checks, 'include' returns base64) and that tolerateTruncation yields a partial inventory.

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 ('Walk') and resource ('LOCAL headers') in stream order, and explicitly identifies itself as a central-directory-less reader. It clearly distinguishes from sibling tools like inspect_zip and list_zip_entries.

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?

Provides explicit when-to-use guidance: 'The only tool that works on a truncated archive or a stream cut mid-way' and 'Prefer those tools whenever the whole archive is available; use this one for forensics.' This leaves no ambiguity about the intended context.

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