Skip to main content
Glama
blazickjp

ArXiv MCP Server

by blazickjp

read_paper

Read-only

Retrieve the text content of a downloaded arXiv paper, returning a markdown chunk of up to 12,000 characters. Continue reading by providing the next start offset, or request the full remaining text.

Instructions

Read the text content of a paper that was previously downloaded via download_paper. Returns the paper in markdown format, bounded to roughly 12,000 characters by default so one call cannot return an unbounded paper body. When is_truncated is true, call again with start=next_start (see next_retrieval) to continue, or pass return_full_text=true for the entire remaining paper. Will fail with a clear error if the paper has not been downloaded yet — call download_paper first. Workflow: search_papers -> download_paper -> read_paper.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
startNoZero-based character offset for reading large papers in chunks; pass next_start from a prior truncated response to continue
paper_idYesThe arXiv ID of the paper to read
max_charsNoMaximum raw paper characters to return from start; omit for the bounded default (12,000 chars)
return_full_textNoSet true to opt out of the bounded default and return the entire remaining paper from start in one call

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.7.0
    • changedInput schema / properties / max_chars / description
      Previous value: -"Maximum raw paper characters to return from start; omit for full content"New value: +"Maximum raw paper characters to return from start; omit for the bounded default (12,000 chars)"
    • addedInput schema / properties / return_full_text
      Added value: +{
      +  "description": "Set true to opt out of the bounded default and return the entire remaining paper from start in one call",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / start / description
      Previous value: -"Zero-based character offset for reading large papers in chunks"New value: +"Zero-based character offset for reading large papers in chunks; pass next_start from a prior truncated response to continue"
  2. Changed3 schema fields changedv0.5.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / max_chars
      Added value: +{
      +  "description": "Maximum raw paper characters to return from start; omit for full content",
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / start
      Added value: +{
      +  "description": "Zero-based character offset for reading large papers in chunks",
      +  "minimum": 0,
      +  "type": "integer"
      +}
  3. Addedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond the readOnlyHint annotation: chunking at ~12,000 characters, continuation via is_truncated and next_start, the return_full_text opt-out, and the failure condition when the paper has not been downloaded. It also covers the typical workflow context, making the behavior predictable.

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 compact and every sentence contributes useful guidance: what the tool reads, how chunking works, how to continue or override truncation, the failure precondition, and the intended workflow. The critical behavior is front-loaded and there is no filler.

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?

Despite having no output schema, the description covers the important response behaviors (Markdown, truncation, continuation token) and the prerequisite download step. For a paginated reader tool with no output schema, this provides enough contextual information for an agent to call it 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 coverage is already 100%, but the description adds meaning beyond the schema by explaining the default 12,000 character bound, the fact that start should come from a prior truncated response, and that return_full_text=true retrieves the entire remaining paper. This is exactly the kind of cross-parameter context an agent needs.

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: read the text content of a previously downloaded paper and return it in markdown format. It also distinguishes this tool from download_paper by making the download prerequisite explicit, and the scope is specific enough to separate it from section or abstract readers.

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?

The description clearly tells the agent when the tool can be used: only after download_paper has been called, and it even provides the workflow search_papers -> download_paper -> read_paper. It does not explicitly contrast this tool with sibling alternatives such as read_paper_section or get_paper_outline, which is the only gap.

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