Loading ToolBench
Model Context Protocol server for querying and managing Zenodo repositories
Zenodo MCP server has well-structured tool definitions with consistent naming (verb_noun pattern), comprehensive descriptions (avg 180 chars), and complete input schemas with type declarations. All 11 tools follow the get_/list_/search_/create_ convention. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Parameter descriptions are solid but lack explicit constraints (enums, ranges, patterns). Error handling is absent from tool definitions. No tool annotations (readOnlyHint/destructiveHint) despite clear risk distinctions (10 READ_ONLY, 1 WRITE). Missing idempotency guidance for create_deposition.
Create a new empty deposition (draft upload) on Zenodo. Returns the deposition resource including its ID and bucket URL for file uploads. Requires authentication and ZENODO_ALLOW_WRITE=true.
Check the current authentication status with Zenodo and get guidance on how to connect with an API key.
Get details about a specific Zenodo community by its identifier. Returns the title, description, curation policy, and links.
Retrieve a single deposition (draft or published) owned by the authenticated user. Requires authentication via set_api_key or ZENODO_API_KEY environment variable.
Download and return the content of a file from a Zenodo record. Text files are returned as UTF-8 strings; binary files are returned as base64. Use max_bytes to limit the amount of data downloaded.
Get detailed information about a specific Zenodo record by its ID. Works without authentication for public records.
No output schemas documented. LLMs cannot predict response structure, breaking tool chaining. E.g., search_records returns results but LLM doesn't know if response includes 'record_id' vs 'id' vs 'zenodo_id', forcing guesswork for downstream get_record calls.
No tool annotations (readOnlyHint/destructiveHint). 10 tools are READ_ONLY, 1 is WRITE (create_deposition), but LLM has no signal. Agents cannot distinguish safe-to-retry reads from irreversible writes without explicit hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Search or list Zenodo communities. Returns community identifiers, titles, and descriptions.
List your own Zenodo depositions (drafts and published records). Requires authentication via set_api_key or ZENODO_API_KEY environment variable.
List all files attached to a Zenodo record, including their names, sizes, and checksums. Works without authentication for open-access records.
Search for records on Zenodo using a query string. Supports Elasticsearch query syntax. Works without authentication for public records.
Set a Zenodo personal access token for the current session. This allows authenticated access to private records and depositions. Create a token at https://zenodo.org/account/settings/applications/tokens/new/ with the desired scopes (deposit:write for uploads, deposit:actions for publishing).
create_deposition metadata parameter lacks schema. Accepts 'object' with no properties defined. LLM cannot know valid fields (title, upload_type, creators, etc.) or their types. Description lists examples but no formal constraint.
Pagination parameters (page, size) lack explicit ranges. Baseline rubric requires min/max for numeric params. E.g., size defaults to 10 but max is 100, LLM could pass 1000 and fail silently.
No error recovery guidance. Tool descriptions lack 'what to do if this fails' hints. E.g., get_record with invalid ID returns error but description doesn't suggest search_records as fallback.