zenodo-mcp-server

List Zenodo record versions

zenodo_list_versions

Read-onlyIdempotent

List every version of a Zenodo deposit's version series, newest first, with each version's record id, DOI, version label, publication date, file totals, and usage counts. Accepts any identifier zenodo_get_record accepts; a concept DOI and any single version's DOI list the same series. Use it to find the version a paper cited or the current release. A miss (an unknown id, a deleted record with its removal tombstone, restricted metadata, or a DOI not registered on Zenodo) returns found: false with guidance instead of an error.

Input Schema

Name	Required	Description
`id`	Yes	Any version or concept identifier of the deposit: a record id (22705923), a Zenodo DOI (10.5281/zenodo.22705923) or concept DOI (10.5281/zenodo.591564), another DOI registered to a Zenodo record, or a zenodo.org/records or doi.org URL.
`page`	No	Result page, starting at 1. Zenodo pages through only the first 10,000 versions, so the last reachable page is 10,000 ÷ size rounded up (400 at size 25).
`size`	No	Versions per page, at most 25 per call; larger values return 25.

Output Schema

Name	Required	Description
`cap`	No	Page size applied (at most 25).
`page`	No	Page returned.
`size`	No	Page size applied: size, or 25 when size asked for more.
`error`	No	Present when the call failed. Absent on success.
`found`	No	True when the version series resolved.
`shown`	No	Versions returned on this page.
`notice`	No	Guidance on paging, the 25-per-call size cap, or a page past the end.
`guidance`	No	What to do next. Present when not found.
`has_more`	No	True when another page of versions follows.
`versions`	No	Versions on this page, newest first; empty when not found.
`miss_kind`	No	Why nothing resolved. Present when not found.
`next_page`	No	The next page number, when has_more.
`tombstone`	No	Removal tombstone. Present when miss_kind is deleted.
`truncated`	No	True when more versions follow this page.
`input_kind`	No	How id was parsed: record_id (digits), zenodo_doi (10.5281/zenodo.N or zenodo.N), external_doi (another DOI), or url (a zenodo.org or doi.org link).
`totalCount`	No	Number of versions in the series.
`concept_doi`	No	Concept DOI of the series, when minted; absent when not found or on a page past the end.
`latest_recid`	No	Record id of the newest version. Present when found, unless Zenodo cannot name it for a page past the end.
`concept_recid`	No	Concept record id naming the whole series; absent when not found or on a page past the end.
`total_versions`	No	Number of versions in the series. Present when found.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 18, 2026

changedInput schema / properties / page / description

Previous value: -"Result page, starting at 1. page × size may not exceed 10,000."New value: +"Result page, starting at 1. Zenodo pages through only the first 10,000 versions, so the last reachable page is 10,000 ÷ size rounded up (400 at size 25)."

changedInput schema / properties / size / description

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

changedInput schema / properties / size / maximum
```
Previous value: -25New value: +10000
```

changedOutput schema / properties / cap / description

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

changedOutput schema / properties / error / properties / data / properties / reason / description

Previous value: -"Machine-readable failure mode. Declared by this tool: `invalid_identifier`: id matches no accepted form, or is a GitHub-badge latestdoi id or a non-zenodo.org host. `result_window_exceeded`: page × size exceeds 10,000. `record_unavailable`: Zenodo could not serve this record or its versions page: HTTP 500 after one retry, HTTP 500 while resolving a non-Zenodo DOI, or no complete record response within the time budget (its gateway cuts off near 30 s, which deposits with about 10,000 or more files hit). `upstream_timeout`: The versions page got no complete response within its time budget. `rate_limited`: Zenodo answered HTTP 429, or this server's shared Zenodo request budget is spent for the current window. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_identifier`: id matches no accepted form, or is a GitHub-badge latestdoi id or a non-zenodo.org host. `result_window_exceeded`: The page starts past the first 10,000 versions: (page − 1) × size is 10,000 or more, counting a size above 25 as 25. `record_unavailable`: Zenodo could not serve this record or its versions page: HTTP 500 after one retry, HTTP 500 while resolving a non-Zenodo DOI, or no complete record response within the time budget (its gateway cuts off near 30 s, which deposits with about 10,000 or more files hit). `upstream_timeout`: The versions page got no complete response within its time budget. `rate_limited`: Zenodo answered HTTP 429, or this server's shared Zenodo request budget is spent for the current window. Other values are possible when a failure originates below the handler."

changedOutput schema / properties / notice / description

Previous value: -"Guidance on paging or a page past the end."New value: +"Guidance on paging, the 25-per-call size cap, or a page past the end."

changedOutput schema / properties / size / description

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

First observedOct 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, open-world safety. The description adds substantial behavioral context beyond them: newest-first ordering, the fields returned per version, the concept-DOI/version-DOI equivalence, and notably the soft-fail contract (found: false with guidance instead of an error) for unknown, deleted, or restricted ids.

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, each load-bearing: scope and returned fields first, then identifier equivalence, then the lookup/soft-fail behavior. No filler and the most decision-relevant facts are front-loaded.

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?

Even though an output schema exists, the description complements it with ordering, identifier semantics, and failure behavior. For a three-parameter read tool with rich structured metadata, 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.

Parameters4/5

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

With 100% schema coverage the baseline is 3, but the description adds real meaning: 'Accepts any identifier zenodo_get_record accepts' and the point that a concept DOI and any single version's DOI resolve to the same series clarify the semantics of the id parameter. Pagination syntax is left to the schema.

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 (list) and resource (every version of a Zenodo deposit's version series) with scope and ordering. It implicitly distinguishes itself from zenodo_get_record by describing the series-wide result rather than a single record.

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 clear context for use ('find the version a paper cited or the current release') and ties its identifier acceptance to zenodo_get_record, which signals the relationship between siblings. It does not explicitly state when not to use it, so it stops short of a 5.

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.