Skip to main content
Glama
czwziy

scholar-toolkit-mcp

by czwziy

read_zenodo_paper

Retrieve and extract text content from a Zenodo paper using its identifier for further analysis or processing.

Instructions

Read and extract text content from a Zenodo paper.

Args: paper_id: Zenodo paper identifier. save_path: Directory where the PDF is/will be saved (default: './downloads'). Returns: str: Extracted text content.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paper_idYes
save_pathNo./downloads

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior2/5

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

No annotations exist, so description must fully disclose behavior. 'save_path' notes where PDF is/will be saved, implying possible download side effect, but this is not explicitly stated. No mention of caching, re-extraction, or permission requirements.

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?

Concise docstring format with Args/Returns. No superfluous text, but could be slightly more compact without losing clarity.

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 2 simple parameters and output described as a string, description is adequate but fails to disclose potential download side effect or handling of existing PDFs. Output schema exists but is not shown; description mentions return type.

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%, description partially compensates: 'paper_id: Zenodo paper identifier' is vague; 'save_path: Directory where the PDF is/will be saved' adds meaning about saving a PDF. Lacks clarity on paper_id format or examples.

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 'Read and extract text content from a Zenodo paper', with a specific verb ('Read and extract'), target resource ('Zenodo paper'), and distinguishes from sibling read_*_paper tools by source.

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 alternatives like download_zenodo. Usage is implied ('read and extract text'), but no when-to-use or when-not-to-use conditions are provided.

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

Install Server

Other Tools

Latest Blog Posts

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/czwziy/paper-toolkit-mcp'

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