arxiv-mcp-server

Arxiv Read Paper

arxiv_read_paper

Read-only

Fetch the full text of an arXiv paper. Tries arxiv.org/html first, falls back to ar5iv.labs.arxiv.org, and falls back again to text extracted from the PDF when neither has an HTML render — check the source field to know which one answered. Page through long papers with start and max_characters, or pass max_characters null to get the entire body in one call.

Input Schema

TableJSON Schema

Name	Required	Description
`start`	No	Character offset into the cleaned body to begin reading from. Defaults to 0. Use with max_characters to page through long papers — e.g., start=100000 with max_characters=100000 returns chars 100,000–199,999. The total length is reported as body_characters in the response.
`paper_id`	Yes	arXiv paper ID (e.g., "2401.12345" or "2401.12345v2").
`max_characters`	No	Maximum characters of paper body to return, counted after boilerplate stripping. Defaults to 100,000; pass null to return the entire body in one call. Whole-paper reads can exceed a client tool-result size cap — math-heavy bodies run 300KB-1MB+ — so prefer the default plus start-based paging unless the full text is needed. When truncated, a notice and the total character count are included.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`start`	No	Character offset of the first character in content within the cleaned body.
`title`	No	Paper title (from metadata, not parsed from HTML).
`source`	No	Which upstream artifact the body was read from. arxiv_html and ar5iv are HTML renders; pdf_text is text extracted from the PDF, where prose is reliable but math, tables, and heading structure are flattened.
`content`	No	Paper body for the requested slice — cleaned HTML when source is arxiv_html or ar5iv, plain text when source is pdf_text. Empty when start is past body_characters.
`pdf_url`	No	Direct PDF download URL.
`paper_id`	No	arXiv paper ID.
`truncated`	No	True when more body content exists past this slice (start + content.length < body_characters).
`abstract_url`	No	arXiv abstract page URL for attribution.
`body_characters`	No	Character count of the full cleaned body. Use with start and max_characters to page. Typically 3-4× smaller than total_characters for math-heavy HTML papers.
`total_characters`	No	Character count of the body before cleaning — the unprocessed HTML body for arxiv_html and ar5iv, and equal to body_characters for pdf_text, which needs no cleaning.

TDQS

A4.5/5.0

Behavior5/5

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

The readOnlyHint annotation already marks the operation as read-only; the description adds material context: the multi-source fallback order, the source field to identify which source answered, and the paging/truncation behavior. These details go well beyond what the annotation provides.

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 sentences, front-loaded with the core purpose, then fallback behavior, then paging. Every sentence earns its place, and there is no filler or repetition.

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?

With an output schema present and a readOnlyHint annotation, the description covers all essential behaviors: fallback sources, source field, and paging vs. whole-body options. Remaining details like parameter bounds are in the schema, so nothing critical is missing for correct invocation.

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 description coverage is 100%, so the baseline is 3. The description restates the paging semantics and the null option, but adds little beyond what the schema's start and max_characters descriptions already say.

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 opens with 'Fetch the full text of an arXiv paper,' naming a specific verb and resource. It clearly distinguishes itself from siblings by focusing on full-text retrieval with a concrete fallback chain, so an agent can tell it apart from search or metadata tools.

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?

It clearly frames its role—full-text fetching—and gives concrete guidance on paging with start and max_characters, and on requesting the entire body via max_characters=null. It does not explicitly contrast with sibling tools, but the purpose statement plus sibling names make the context clear enough.

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

All arxiv-mcp-server tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct operation: searching, retrieving metadata by ID, reading full text, and listing categories. There is no overlap between these actions, and even search vs. get_metadata is clearly differentiated by known vs. unknown IDs.

Naming Consistency5/5

All tools follow a consistent 'arxiv_' prefix with verb-first names in snake_case: arxiv_get_metadata, arxiv_list_categories, arxiv_read_paper, arxiv_search. The pattern is uniform and predictable.

Tool Count5/5

Four tools is a compact set that fully covers the core arXiv workflows without excess. Each tool earns its place, and the count is well within the ideal 3–15 range.

Completeness5/5

The tool surface covers the essential lifecycle for arXiv: discovery (search), metadata retrieval (get_metadata), content access (read_paper), and category discovery (list_categories). Since arXiv is a read-only service, no update/delete operations are needed, making the set complete.

Arxiv Read Paper

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources