Skip to main content
Glama
musharna

data-aggregator-mcp

by musharna
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

fetch

Download research dataset files to local disk and return their paths, with optional glob selection, size limits, and checksum verification where available.

Instructions

Download a resource's files to local disk and return the PATHS (never the file contents). Fetchable backends: Zenodo (md5-verified); SRA via ENA FASTQ (md5-verified); GEO supplementary files (unverified); DataCite sub-repos — Figshare/Dataverse/OSF (md5-verified), OpenNeuro (snapshot manifest, unverified), Dryad is manifest-only (resolve lists files, fetch fails loud), Mendeley + other DataCite repos fail loud; PubMed/OpenAIRE open-access full text (EuropePMC XML / Unpaywall PDF, unverified); HuggingFace Hub (unverified); DataONE Member-Node objects (md5/SHA-256-verified); OmicsDI — PRIDE (unverified) + MetaboLights (sha-256-verified) only, MassIVE/jPOST/iProX/PeptideAtlas/Panorama Public/GNPS/Metabolomics Workbench fail loud; DANDI dandisets (302→S3, sha-256-verified); CZ CELLxGENE H5AD/RDS assets (unverified); OpenML ARFF (md5-verified); RCSB PDB .cif/.pdb structure files (unverified); UniProtKB FASTA (unverified); BioStudies study files (unverified); GBIF Darwin Core Archives (unverified); data.gov dataset distributions (unverified). Fails loud if selected files exceed max_bytes unless force=true. Verifies md5/SHA-256 where the source publishes one; files marked unverified get no integrity check. Writes a .dataresource.json sidecar.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesSource-prefixed id or bare Zenodo id
destNoDestination dir (default managed cache)
filesNoGlob over file names (default all)
forceNoOverride max_bytes
extractNoUnpack downloaded zip/tar archives into the destination (default false). Path-traversal-guarded; counts against max_bytes.
max_bytesNoByte ceiling before failing loud

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
bytesNo
pathsNo
resumedNo
skippedNo
unverifiedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.54.1
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed1 schema field changedv0.45.3
    • addedOutput schema / properties / unverified
      Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "title": "Unverified",
+  "type": "array"
+}
  3. Changed1 schema field changedv0.16.0
    • addedOutput schema / properties / resumed
      Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "title": "Resumed",
+  "type": "array"
+}
  4. First observedv0.11.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: per-source md5/SHA-256 verification vs unverified status, the fail-loud behavior on max_bytes (unless force), the path-traversal-guarded extract behavior, and the .dataresource.json sidecar write. With readOnlyHint=false and idempotentHint=false declared, this explains the mutation profile in depth.

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 core purpose and mutation semantics are front-loaded in the first two sentences, and the backend enumeration is information-dense rather than filler. The long run-on source list is harder to scan than a structured list would be, costing a point.

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 values need not be described, and the description covers every remaining agent-relevant concern: supported sources, integrity verification, failure modes, sidecar output, and archive extraction. Nothing needed 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, but the description adds real meaning: force is framed as overriding max_bytes specifically, extract 'counts against max_bytes', and the return contract (paths, not contents) contextualizes id/files/dest. It stops short of clarifying dest-vs-files interaction.

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?

Opens with a specific verb+resource+output contract: 'Download a resource's files to local disk and return the PATHS (never the file contents).' That single clause tells an agent exactly what it gets back and distinguishes it from a contents-returning read.

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 detailed context on which backends are fetchable and which 'fail loud', and explicitly routes listing to the sibling ('Dryad is manifest-only (resolve lists files, fetch fails loud)'). It does not, however, state a general when-to-use-fetch vs search/operate condition.

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