Skip to main content
Glama
Sign In
EcuDataMCP

EcuDataMCP

by DweskZ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Leer un archivo dentro de un ZIP remoto

read_zip_member
Read-only

Reads one CSV, TSV, TXT, XLSX, XLS, XLSB, or ODS member from a remote ZIP as a table, fetching only that member's bytes via HTTP Range. Use list_zip_contents first for member names.

Instructions

Read one CSV/TSV/TXT or XLSX/XLS/XLSB/ODS file inside a remote ZIP as a table, fetching only that file's bytes via HTTP Range. Get member names from list_zip_contents first. Max 5 MB compressed per member. Detects the header below a report's title block.

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": {
      "url": "<url>",
      "member": "<member>"
    },
    "name": "read_zip_member"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesDirect URL to a .zip file (the same URL given to list_zip_contents).
rowsNoData rows to return (default 50, max 500).
formatNotext summary (default) or json structured result.text
memberYesMember path inside the zip, as listed by list_zip_contents.
offsetNoData rows to skip before returning, for pagination.
skip_rowsNoRows above the column header; -1 (default) detects them, 0 keeps row 1.

Output Schema

NameRequiredDescriptionDefault
filasNo
sourceNo
columnasNo
metadatosYes
url_fuenteNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.15.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds real context beyond them: only the member's bytes are fetched via HTTP Range, a 5 MB compressed cap per member applies, and header detection under title blocks is attempted automatically. It doesn't state error behavior for unsupported formats or ranges, keeping it short of a 5.

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

Conciseness5/5

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

Three tight sentences, front-loaded with the action and format support, then prerequisite, then limits. No filler; every clause carries operational value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values need no explanation, and the main risks (size cap, header detection, prerequisite lookup) are all disclosed. Minor gaps remain around failure modes for unsupported member types or oversized members.

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% with per-parameter descriptions, so the baseline is already met; the description still adds meaning by tying url to the same value given to list_zip_contents and by explaining that header detection is what skip_rows controls. rows/offset pagination semantics are only implied, not restated.

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 ("Read one CSV/TSV/TXT or XLSX/XLS/XLSB/ODS file inside a remote ZIP as a table") plus the mechanism (HTTP Range byte fetch), which distinguishes it from list_zip_contents and from read_pdf.

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 directs the agent to call list_zip_contents first to obtain member names, which is the key prerequisite for correct invocation. It lacks explicit when-not guidance (e.g., when to prefer read_pdf or downloading the whole zip), but the sequencing guidance is clear.

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

Deploy Server

Other Tools