zenodo-mcp-server

List Zenodo record files

zenodo_list_files

Read-onlyIdempotent

Page through a Zenodo deposit's file manifest (key, size, MIME type, MD5, download URL, previewability), optionally filtered by a substring of the file key, or list the members inside one of its .zip files by setting archive_key. Restricted and embargoed files return the access status and embargo date with no entries. Read a small text file or ZIP member with zenodo_read_file.

Input Schema

Name	Required	Description
`id`	Yes	The deposit: a record id (22705923), a Zenodo DOI (10.5281/zenodo.22705923), another DOI registered to a Zenodo record, or a zenodo.org/records or doi.org URL. A concept id lists the latest version’s files.
`limit`	No	Entries per page, at most 200 per call; larger values return 200.
`offset`	No	Entries to skip before this page.
`archive_key`	No	Exact file key of a .zip in this record (from the manifest) to list its members instead of the manifest. Omit to list the manifest.
`key_contains`	No	Case-insensitive substring filter on file keys (manifest) or member paths (archive), applied before paging.

Output Schema

Name	Required	Description
`cap`	No	Page size applied (at most 200).
`kind`	No	manifest: the record’s files; archive: members of the .zip named by archive_key.
`error`	No	Present when the call failed. Absent on success.
`limit`	No	Page size applied: limit, or 200 when limit asked for more.
`recid`	No	Record id whose files are listed (the latest version for a concept id).
`shown`	No	Entries returned on this page.
`notice`	No	File access notes, empty-filter guidance, listing caps, the 200-per-call limit cap, or paging guidance.
`offset`	No	Entries skipped before this page.
`archive`	No	The archive being listed (archive kind); absent when files are restricted.
`entries`	No	Manifest files on this page (manifest kind); empty when files are restricted.
`matched`	No	Entries matching the filter, before paging.
`members`	No	Archive members on this page (archive kind); empty when files are restricted.
`has_more`	No	True when more matching entries follow this page.
`truncated`	No	True when more matching entries follow this page.
`file_count`	No	Total files in the record (manifest kind); absent when files are restricted or embargoed.
`totalCount`	No	Entries matching the filter, before paging.
`next_offset`	No	Offset of the next page, when has_more.
`total_bytes`	No	Total size of the record’s files in bytes (manifest kind); absent when files are restricted or embargoed.
`files_access`	No	File access: public or restricted; absent when Zenodo does not report it.
`key_contains`	No	The key filter applied, when set.
`access_status`	No	Record access status: open, restricted, embargoed, or metadata-only.
`embargo_until`	No	Embargo end date, when an embargo is active.
`files_enabled`	No	False for a metadata-only deposit.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 18, 2026

changedInput schema / properties / limit / description

Previous value: -"Entries per page (1–200)."New value: +"Entries per page, at most 200 per call; larger values return 200."

changedInput schema / properties / limit / maximum
```
Previous value: -200New value: +10000
```

changedOutput schema / properties / cap / description

Previous value: -"Page size applied."New value: +"Page size applied (at most 200)."

changedOutput schema / properties / limit / description

Previous value: -"Page size applied."New value: +"Page size applied: limit, or 200 when limit asked for more."

changedOutput schema / properties / notice / description

Previous value: -"File access notes, empty-filter guidance, listing caps, or paging guidance."New value: +"File access notes, empty-filter guidance, listing caps, the 200-per-call limit cap, or paging guidance."

First observedOct 9, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered; the description adds real behavioral context the schema cannot: restricted and embargoed files return access status and embargo date with no entries, and the per-call entry cap. It stops short of describing pagination termination or error behavior.

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?

A single dense, front-loaded paragraph where the listing scope, optional filter, archive mode, and the sibling redirect each carry weight. The parenthetical field list is slightly list-heavy but justified for a manifest 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?

With an output schema present, return values need not be re-explained, yet the description still covers paging, filtering, archive mode, and embargo/restricted handling. Nothing an agent needs 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.

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3; the description restates the substring filter and archive_key semantics that the schema already documents in more detail. It adds no syntax or edge-case guidance beyond what the parameter descriptions provide.

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?

Names a specific verb (page through/list) and resource (a Zenodo deposit's file manifest), enumerates the returned fields, and covers both operating modes (manifest vs. archive member listing). An agent can distinguish it from zenodo_get_record and zenodo_read_file without opening any schema.

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 routes the reader case elsewhere ('Read a small text file or ZIP member with zenodo_read_file') and states that omitting archive_key lists the manifest, giving clear mode-selection guidance. It does not discuss when to prefer zenodo_list_versions or get_record, so it falls short of full when/when-not coverage.

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

All zenodo-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.