zenodo-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, but there is slight overlap between search_records and the specialized search_by_* tools, and between recommend_dataset and find_training_datasets. However, detailed parameters and descriptions mitigate confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case, such as build_research_bundle, cite_record, or search_by_community. No mixing of conventions or irregular names.
Tool Count4/5
18 tools is on the higher end but appropriate for the broad domain of Zenodo record analysis and discovery. Each tool serves a distinct function; the count does not feel excessive.
Completeness3/5
The tool surface covers search, retrieval, citation, comparison, and analysis, but lacks write operations (create, update, delete). For a purely analytical server this might be acceptable, but it limits full lifecycle support.
Average 3.8/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It states the tool evaluates reusability and returns a dict, but does not disclose if it is read-only, requires authentication, or handles errors (e.g., missing record). No side effects mentioned.
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 description is well-structured with a clear purpose, bullet-pointed grading aspects, and parameter documentation. It is concise but could be slightly shorter without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input and return structure but lacks details on error handling, score calculation, or what constitutes good reusability. For a tool with minimal schema and no output schema, it omits some necessary context.
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 0%, so the description must compensate. It adds 'The Zenodo record ID' for record_id, providing context beyond the schema's title. This is sufficient for a single parameter.
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?
The description clearly states the tool evaluates and scores a Zenodo record's reusability, listing specific aspects graded (license quality, metadata completeness, etc.). It distinguishes from sibling tools like inspect_license which focus on a single aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives like generate_data_card or inspect_license. The description implies use for reusability evaluation but does not provide conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the return value structure (dict with abstract, authors, etc.) but does not disclose error handling, authentication needs, rate limits, or side effects. Adequate but not thorough.
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 description is well-structured with clear sections (Parameters, Returns) and front-loaded with the main purpose. It is concise at two short paragraphs, though the parameter description could be integrated into the first sentence.
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?
Given the tool's simplicity (one parameter, no output schema), the description provides sufficient context: it states the input and describes the output as a dict with key fields. It is mostly complete, though it lacks mention of potential errors.
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?
The input schema has 0% description coverage, leaving the parameter undocumented. The description compensates by stating the single parameter is the numeric Zenodo record ID, adding semantic meaning beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves complete metadata for a Zenodo record. The verb 'retrieve' and resource 'metadata' are specific. However, it does not explicitly differentiate from sibling tools like search_records or related_records, which also deal with record data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools such as search_records, latest_version, or cite_record might be more appropriate for specific tasks, but the description offers no criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'No files are written to disk by this tool,' which is a key behavioral detail not captured by annotations (none provided). It also mentions that the agent receives URLs and can use them as needed. This adds useful context about the tool's non-destructive, read-only nature. However, it does not address error handling or rate limits.
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 description is concise, consisting of three sentences plus a structured parameter and returns section. It front-loads the purpose and key behavioral detail. The use of a docstring-like format is clear but could be slightly more streamlined. Overall, it is well-organized and informative without unnecessary verbosity.
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?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description is sufficiently complete. It specifies the return format (list of dicts with fields: filename, size, type, checksum, download URL) and notes the non-destructive behavior. No critical information appears missing for standard usage.
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?
The input schema has one parameter, record_id, with no description (0% coverage). The description adds a brief explanation: 'record_id : int, The numeric Zenodo record ID.' This clarifies the parameter's meaning beyond the bare schema. However, it does not provide additional constraints or examples, so it only partially compensates for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all files in a Zenodo record with metadata and download URLs,' specifying the action (list) and the resource (files in a record). It distinguishes from sibling tools like get_record (which returns record metadata) and search_records (which searches records), though it does not explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings. For example, it does not mention that for full record metadata one should use get_record, or that list_files is specifically for retrieving file listings. There is no context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It explains the tool finds datasets, processes metadata, and scores on completeness, popularity, and documentation. However, it does not mention whether the tool is read-only, any destructive actions, or behavioral details like result ordering or error handling.
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?
The description is concise and well-structured, with a clear first sentence stating the purpose, a brief explanation of functionality, and a neatly formatted parameter list. Every sentence adds value without redundancy.
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?
The description is fairly complete for a recommendation tool with three simple parameters and an output schema. It mentions the return format (list of dict with matching reasons). However, it lacks edge-case handling or usage context relative to siblings.
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?
The input schema has 0% description coverage, so the description compensates well by explaining each parameter: query as a natural language prompt with example, page as result page, size as number of recommendations. This adds significant meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: providing ranked dataset recommendations based on a natural language request. It identifies the resource (datasets) and the action (recommend). While it is clear, it does not explicitly differentiate from siblings like find_training_datasets or search_records, missing a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparison with sibling tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only operation but does not disclose side effects, permissions, rate limits, or other behaviors beyond the basic comparison.
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?
Front-loaded with the main action, parameter list with descriptions, and return value details. No unnecessary words, every sentence is relevant.
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?
For a simple comparison tool with 2 parameters and no output schema, the description explains inputs and output fields thoroughly. Could mention constraints or error scenarios but adequate.
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?
The input schema has 0% description coverage (only titles), but the description lists both parameters with clear types and semantics, adding significant meaning over 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?
The description clearly states the action 'compare' and the resource 'metadata, stats, and sizes of two Zenodo records side-by-side'. It distinguishes from sibling tools like get_record or search_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like related_records or evaluate_reusability. No mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It describes the operation as exporting metadata, which implies read-only behavior, but does not explicitly state lack of side effects, permissions, or rate limits. Adequate but not thorough.
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 description is brief and well-structured, using a parameter list format. However, it could be more concise by integrating the parameter details into the description sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return format, but it merely says 'Formatted metadata string.' It lacks details on potential errors, pagination, or large records. Adequate for a simple tool but could be more complete.
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 provides no descriptions for parameters, but the description explains each parameter (record_id as Zenodo record ID, format with allowed values and default). This adds significant value beyond 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?
The description clearly states the tool exports record metadata in a structured format. The verb 'export' and resource 'record metadata' are specific, and it distinguishes itself from sibling tools like get_record and cite_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as get_record or cite_record. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains it extracts related identifiers and groups by type, but does not disclose behavioral traits such as recursion depth, authentication needs, or whether it only uses direct metadata links.
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?
The description is extremely concise: one sentence for purpose, then a parameter block and return type. No redundant information; every sentence adds 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?
Given the tool has one required parameter, no output schema, and no annotations, the description adequately covers purpose, parameter, and return type. It could elaborate on the grouping keys but it is fairly complete for its simplicity.
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 coverage is 0% (no descriptions in schema). The description adds 'The numeric Zenodo record ID' for the only parameter, which is helpful but minimal—does not elaborate on constraints (e.g., must be valid, positive). Baseline 3 due to low coverage.
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?
The description clearly states the tool finds records related to a given record, with a specific verb ('Find') and resource ('records related to the given record'). It distinguishes from sibling tools like search_records or get_record by focusing on relatedness extraction from record metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need related records but does not explicitly state when to use versus alternatives like search_records or cite_record. No when-not scenarios or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It mentions traversing relationships and returning a dictionary, but does not clarify if the tool is read-only or modifies state, nor does it address auth needs or side effects.
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 description is relatively concise with a front-loaded purpose sentence, a brief process paragraph, and a parameter section. A minor reduction in verbosity could improve it.
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?
Given one parameter and no output schema, the description covers the input and return structure (dict with linked items, citations, reproducibility score). However, it lacks detail on error handling and prerequisites.
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 0%, but the description provides a docstring for 'record_id' identifying it as a Zenodo record ID, adding necessary meaning beyond the schema's generic 'Record Id' title.
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?
The description clearly states the verb 'build' and resource 'research bundle', specifying it assembles related scientific items (paper, dataset, source code, citations). This differentiates it from sibling tools like 'cite_record' or 'compare_records'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating a reproducibility package but does not explicitly state when to use it versus alternatives, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description covers parameters and return type but lacks details on constraints, rate limits, or side effects. For a read operation, it's minimally adequate.
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?
Structured with sections for Parameters and Returns, but the parameter list is verbose. Could be shortened without losing clarity.
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 returns are sufficiently described as list of dicts. Input parameters are well-documented, making the tool usable for its intended purpose.
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?
Description adds examples for funder ('NSF', 'European Commission', 'NIH') and clarifies query as optional, going beyond the schema. Despite 0% schema coverage signal, it compensates well.
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?
Description clearly states 'Search for records funded by a specific organization' and distinguishes from siblings like search_by_community or search_by_license by focusing on the funder parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus other search tools. It's implied for funder-specific queries, but no exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it returns 'List of matching record summaries,' indicating a read operation, but does not explicitly declare it non-destructive or disclose any side effects, permissions, or pagination behavior beyond parameter defaults.
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 description is well-structured with a brief header followed by a parameter list in docstring format. It is concise and front-loaded, though the parameter section could be slightly more terse without losing clarity.
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?
Given the tool has 5 parameters (1 required) and an output schema exists, the description covers the essential information: purpose, parameter meanings, and return type. It lacks error scenarios or edge cases but is sufficient for basic use.
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?
The input schema has 0% description coverage, but the description provides clear documentation for all 5 parameters, including the required 'license' with examples, optional 'query', and defaults for 'sort', 'page', and 'size'. This adds significant value beyond the bare 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?
The description clearly states 'Find records under a specific license,' specifying the action (find) and resource (records) with a distinct filtering criterion (license). This differentiates it from sibling tools like 'search_records' (general search) and 'search_by_community'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the required 'license' parameter and provides examples, implying it should be used for license-based filtering. However, no guidance is given on when not to use this tool (e.g., for non-license queries) or explicit alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It explains the input and output but does not mention side effects, rate limits, authentication needs, or whether the tool is a read-only operation. Basic behavioral transparency.
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?
The description is concisely structured with a clear first sentence, followed by a well-organized parameter list and return type. Every section serves a purpose without unnecessary words, making it efficient for an agent to parse.
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?
Given 5 parameters and a specified output schema (list[dict]), the description covers all inputs and return format. However, it lacks details on the ranking or evaluation criteria, which would be helpful for understanding tool behavior. Since an output schema exists, the return type is adequately described.
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?
The description provides detailed parameter explanations beyond the schema, including examples for 'license_filter' (e.g., 'permissive (MIT, Apache, CC-BY, CC0)') and clarifies that 'modality' and size filters are optional. This adds meaning beyond the schema's type definitions, even though schema description coverage is 0%.
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?
The description clearly states the verb 'Find' and resource 'datasets' with a specific purpose 'suitable for training ML models'. It distinguishes from generic search tools like 'search_records' by specifying the ML training context, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding ML training datasets but does not explicitly state when to use this tool versus siblings like 'recommend_dataset' or 'search_records'. No exclusions or alternatives are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the output (structured data card) and extracted details, but does not mention potential side effects, authentication needs, or idempotency. The transparency is adequate but not detailed.
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 description is concise and front-loaded with the main purpose, followed by a bullet list of extracted attributes and parameter/return sections. The structure is clear, though the 'Parameters' and 'Returns' headers are slightly redundant given the schema. Overall efficient.
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?
Given the tool's simplicity (one integer parameter, no nested objects, no output schema), the description is complete enough. It explains the purpose, the input, and the output format. Slight lack of detail on the return dict structure is acceptable, as it's an AI-friendly summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring the description to compensate. The description provides a clear and sufficient description for the single parameter record_id ('The Zenodo record ID.'), fully covering its semantics. This exceeds the baseline expectation.
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?
The description clearly states it produces a concise, structured AI-friendly summary (data card) of a dataset, specifying verb (Produce), resource (data card of dataset), and extracted attributes (modality, file formats, etc.). This distinguishes it from sibling tools like get_record (full record) or evaluate_reusability (deeper analysis), earning a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a quick dataset summary, but lacks explicit guidance on when to use this tool versus alternatives such as evaluate_reusability or get_record. No exclusions or prerequisites are mentioned, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes the return value as a list of record summaries but does not mention that the operation is read-only, authentication requirements, rate limits, or error handling. The lack of explicit safety disclosure is a gap.
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 description is well-structured with a purpose sentence followed by a parameter list. It is relatively concise but includes some repetition (e.g., listing defaults that are already in schema). Could be slightly tighter.
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?
Given the presence of an output schema, the description adequately covers input parameters and return summary. However, it could add context about valid community IDs, pagination limits, or relationship to sibling tools. Overall, it is sufficiently complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description carries full responsibility. It provides clear explanations for all 5 parameters: community (string), query (optional), sort (with examples 'bestmatch' or 'mostrecent'), page, and size. This adds significant meaning beyond 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?
The description clearly states 'Search for records within a specific Zenodo community', specifying the verb (search), resource (records), and scope (within a community). This distinguishes it from sibling tools like search_records (general) and search_by_funder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when targeting a specific community but does not explicitly state when to use this tool versus alternatives like search_records or search_by_funder. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must disclose behavioral traits. It states it returns a list of record summaries with specific fields, but lacks details on authentication, rate limits, pagination behavior beyond defaults, or error handling. Partially transparent.
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?
Well-structured with clear title, parameter list, and return description. Each sentence adds value; no fluff. Front-loaded with purpose.
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?
Covers purpose, all 12 parameters, and return format. Lacks usage guidance and behavioral context, but for a search tool with no annotations, the description is largely complete. Missing minor details like alternative tool differentiation.
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?
Description adds parameter explanations that are completely missing in the input schema (coverage 0%). Provides meaning and acceptable values for each filter, e.g., resource_type lists possible types. Could be more specific for some string params (e.g., valid community IDs).
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?
Clear verb 'Search' and specific resource 'Zenodo records' with 'rich filtering'. Distinguishes from sibling specialized search tools (e.g., search_by_community) by being the general-purpose search with many filter options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like search_by_community or search_by_funder. The description implies it is the general search but does not mention when to prefer sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the return value structure (dict with latest version summary, list of all versions with dates and DOIs, and total count). There are no side effects or destructive actions, and the description accurately represents the read-only nature of the tool.
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 description is well-structured with clear 'Parameters' and 'Returns' sections, and it is informative without being overly verbose. Minor redundancy could be trimmed, but the structure aids comprehension.
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?
Given only one required parameter and no output schema, the description covers input, output, and the tool's behavior adequately. It does not mention error handling or edge cases, but for a simple retrieval tool, it is sufficiently complete.
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?
The input schema has 0% description coverage, but the description provides a clear explanation of 'record_id' beyond its type: 'Any version's record ID — the tool finds all versions automatically.' This adds semantic meaning that helps the agent use the parameter correctly.
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?
The description clearly states that the tool gets the latest version and full version timeline of a record, using a specific verb ('Get') and resource ('latest version and full version timeline'), which distinguishes it from siblings that focus on single records or searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the parameter 'record_id' and that it can be any version's ID, implying the tool finds all versions. However, it does not provide explicit guidance on when to use this tool vs alternatives like 'get_record', nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the return format but does not explicitly state read-only behavior or any side effects. For a read inspection tool, adding 'This operation does not modify any data' would improve transparency.
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?
The description is well-structured with a one-line purpose, followed by parameter descriptions and return type. It is concise with no redundant information, earning its place efficiently.
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?
Given no output schema, the description adequately explains the return as a dict of license properties. The two input modes are fully covered. For a simple inspection tool, this is complete and sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides clear, detailed semantics for both parameters: record_id as an integer Zenodo ID and license_id as an SPDX identifier with an example. It also clarifies that only one should be provided, adding valuable context beyond 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?
The description clearly states 'Analyze the properties of a license' with a specific verb and resource. It distinguishes from sibling 'search_by_license' by focusing on inspecting properties of a known license rather than searching for records by license.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two input modes (via record_id or license_id) but does not provide explicit guidance on when to use this tool versus alternatives like 'search_by_license'. Usage context is implied but no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return structure (dict with specific fields) and error behavior ('Raises an error if invalid or not found'), which is sufficient for a read-only resolution tool.
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?
The description is efficiently structured: one-line purpose, supported formats, parameter block, return block, error note. Every sentence adds value, and key info is front-loaded.
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?
Given no output schema, the description explains return fields (title, DOI, creators, etc.) and error conditions. For a single-parameter tool, this is nearly complete, but lacks mention of prerequisites like authentication.
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 0% (no property description), so the description adds essential meaning: 'doi : str, The DOI to resolve' and enumerates accepted formats. This compensates well for the schema gap.
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?
The description clearly states the action ('Resolve a DOI') and the resource ('Zenodo record metadata'), specifying supported input formats. It distinguishes from siblings like 'get_record' by focusing on DOI resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description details supported DOI formats (full DOIs, DOI URLs, Zenodo-specific) but does not explicitly contrast with sibling tools like 'get_record' or provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It describes output as a dict with citation text, style, and DOI, and notes parameter constraints. It does not mention error handling or idempotency, but the core behavior is transparent.
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 description is well-structured with sections for purpose, usage, parameters, and returns. It is relatively concise, though the 'Returns' section could be considered redundant since the output is simple. No wasted sentences.
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?
For a tool with 3 parameters and mutual exclusivity, the description covers the input constraints, output format, and style options. Lacks mention of validation or error cases, but overall sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; the description compensates fully by explaining each parameter (record_id, doi, style) with types and constraints, including the mutual exclusivity rule and a list of style options. This is far beyond what the schema provides.
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?
The description clearly states 'Generate a citation for a Zenodo record in a given style', specifying the verb (generate), resource (citation for a Zenodo record), and style parameter. It is distinct from sibling tools like get_record (retrieves record) or export_metadata (exports metadata).
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 advises 'Provide either record_id or doi (not both)', which clarifies mutual exclusivity. It also lists style options with a default. However, it does not guide when to use this tool versus alternatives, though the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Zenodo-mcp MCP server](https://glama.ai/mcp/servers/Agostynah/Zenodo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Agostynah/Zenodo-mcp)

Score Badge

Copy to your README.md:

[![Zenodo-mcp MCP server](https://glama.ai/mcp/servers/Agostynah/Zenodo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Agostynah/Zenodo-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Agostynah/Zenodo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server