Skip to main content
Glama

Extract Archive Member

extract_archive_member
Read-onlyIdempotent

List or extract a named member from a ZIP archive at a public URL, without downloading the whole archive when the origin honours HTTP Range (most do, including Internet Archive Wayback Machine captures). Call with just "url" to LIST members: name, compressed/uncompressed size, method (stored/deflate), CRC-32. Add "member" (the exact or case-insensitive name from that list) to EXTRACT it: text members come back as decoded text, binary members as base64, windowed by max_bytes/offset exactly like fetch_url. Reads only the end-of-central-directory record and the central directory (at the tail of the file) to list members, and only the one member's local header + payload to extract it — a multi-GB archive costs the same few requests as a tiny one. Refusals are explicit and named: member_not_found, encrypted_entry, unsupported_compression_method (only stored and deflate), decompressed_too_large (checked BEFORE decompressing against the declared size, and again DURING decompression independent of what was declared — a zip-bomb defence that cannot be defeated by a false declaration), zip64_not_supported (more than 65,535 entries or a 4GB+ central directory), too_large (Range not honoured and the archive exceeds this tool's read cap), invalid_archive (not a ZIP, or corrupt). Keyless; works on any ZIP at any public URL, not just an archived capture.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "https://web.archive.org/web/20170217024122id_/https://www.ucas.com/file/86461/download?token=iMCCLWdB"
    },
    "name": "extract_archive_member"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe absolute http(s) URL of a ZIP archive, e.g. an Internet Archive Wayback Machine capture of a .zip, an object-store URL, or any direct ZIP download link.
formatNoOnly used when extracting a member. auto (default) and raw both return decoded text for a textual member and base64 for binary; text forces a text decode (falls back to base64 with a warning if the member looks binary).
memberNoThe exact (or case-insensitive) name of the archive member to extract, as returned by a prior call without "member". Omit to list members instead.
offsetNoOnly used when extracting a member: byte offset into the DECOMPRESSED member where the window starts. Use next_offset from the previous call to page. Default 0.
max_bytesNoOnly used when extracting a member: size of the returned window. Default 100000. Maximum 1000000 for text, 512000 for base64 (binary).

Output Schema

NameRequiredDescriptionDefault
bodyNo
textNo
errorNo
budgetNo
memberNo
methodNo
offsetNo
statusNo
charsetNo
membersNo
messageNo
encodingNo
truncatedNo
url_finalNo
matched_byNo
next_offsetNo
member_countNo
sha256_memberNo
url_requestedNo
bytes_returnedNo
charset_sourceNo
crc32_declaredNo
crc32_verifiedNo
compressed_sizeNo
range_supportedNo
sha256_returnedNo
user_agent_usedNo
members_returnedNo
members_truncatedNo
uncompressed_sizeNo
archive_total_bytesNo
decode_replacementsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the readOnly/idempotent annotations: it discloses the HTTP Range strategy, the exact byte ranges read (EOCD, central directory, local header + payload), the cost profile for multi-GB archives, and a full named enumeration of refusal conditions including zip-bomb defenses. That is unusually rich behavioral context.

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?

One dense paragraph with the list-then-extract workflow front-loaded and the error taxonomy trailing, so an agent can stop reading early if it only needs the happy path. It is close to the upper bound of useful length, but nearly every clause carries 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?

An output schema exists so return shapes need not be explained, and the description still covers both modes, the paging mechanism, the compression methods supported, and every failure mode by name. Nothing an agent needs to select and invoke it correctly is absent.

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, but the description adds genuine meaning: member must be a name from a prior listing call (exact or case-insensitive), and max_bytes/offset window the DECOMPRESSED member like fetch_url. Only the format enum is left to the schema alone.

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 ("List or extract a named member from a ZIP archive at a public URL") and immediately distinguishes the two modes by which parameters are supplied. It also carves out scope against siblings by noting it works on any ZIP at any public URL, not just archived captures.

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?

Explicitly says to call with only "url" to list and to add "member" from that list to extract, establishing a clear ordered workflow. It references fetch_url as the analogue for windowing, but does not say when to prefer fetch_url over this tool for non-ZIP downloads — a minor gap given the sibling list is large.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.