Skip to main content
Glama

fetch_paper

Retrieve academic papers by DOI, URL, or title, returning full-text Markdown with metadata and embedded figures for AI consumption.

Instructions

Fetch AI-friendly paper content. Returns a fixed FetchEnvelope-style object with top-level provenance, token_estimate_breakdown={abstract,body,refs}, and optional article/markdown/metadata payloads. The MCP tool also publishes an output schema for clients that support structured result validation. Tool JSON payloads include schema_version=1; error payloads retain status/reason and add machine-readable code, http_status, error_category, retry_after_seconds, provider, warnings, and source_trail. Defaults: modes=['article','markdown'], strategy.asset_profile omitted (provider default), strategy.allow_metadata_only_fallback=true, include_refs=null, max_tokens='full_text', prefer_cache=false, no_download=false, artifact_mode='markdown-assets', save_markdown=false, markdown_output_dir=null, markdown_filename=null. Set prefer_cache=true to resolve the query to a DOI, then try a matching local cached FetchEnvelope sidecar before running the full fetch waterfall. Use artifact_mode='none' to disable provider artifacts and assets while keeping MCP fetch-envelope cache sidecars. Use no_download=true to avoid writing provider payloads, PDFs, HTML, assets, and fetch-envelope sidecars. Set save_markdown=true to write the rendered Markdown full text to disk; successful saves return saved_markdown_path, while metadata-only or abstract-only results add a warning and download:markdown_skipped_no_fulltext. Use strategy.asset_profile='none', 'body', or 'all' to control local asset downloads; 'none' does not remove remote image links already present in rendered Markdown. With body/all profiles, key local figures may be returned as ImageContent alongside the JSON result; strategy.inline_image_budget can override the default caps of 3 figures, 2 MiB each, and 8 MiB total, and any resulting zero disables inline images. provider_hint and preferred_providers accept the runtime provider catalog (crossref, elsevier, springer, wiley, science, pnas, ieee, arxiv, copernicus, ams, mdpi, royalsocietypublishing, annualreviews, plos, oxfordacademic, acs, iop, aip, frontiers). Browser runtime providers are catalog-derived from ProviderSpec.requires_browser_runtime=True (wiley, science, pnas, mdpi, royalsocietypublishing, annualreviews, acs, iop, aip). Public article sources are catalog-derived from SOURCE_PROVIDER_MAP: acs->acs, aip_html->aip, aip_pdf->aip, ams_html->ams, ams_pdf->ams, annualreviews_html->annualreviews, annualreviews_pdf->annualreviews, arxiv_html->arxiv, arxiv_pdf->arxiv, copernicus_pdf->copernicus, copernicus_xml->copernicus, crossref_meta->crossref, elsevier_pdf->elsevier, elsevier_xml->elsevier, frontiers_pdf->frontiers, frontiers_xml->frontiers, ieee_html->ieee, ieee_pdf->ieee, iop_html->iop, iop_pdf->iop, mdpi_html->mdpi, mdpi_pdf->mdpi, oxfordacademic_html->oxfordacademic, oxfordacademic_pdf->oxfordacademic, plos_pdf->plos, plos_xml->plos, pnas->pnas, royalsocietypublishing_html->royalsocietypublishing, royalsocietypublishing_pdf->royalsocietypublishing, science->science, springer_html->springer, springer_pdf->springer, wiley_browser->wiley. elsevier keeps an official XML route and may fall back to the official Elsevier API PDF lane before degrading to metadata-only, publishing elsevier_xml on XML success and elsevier_pdf on PDF fallback success. springer uses provider-managed direct HTML and direct HTTP PDF fallback, publishing springer_html or springer_pdf. wiley keeps CDP browser HTML first, then CDP browser-seeded publisher PDF/ePDF fallback, and may still continue into the official Wiley TDM API PDF lane when WILEY_TDM_CLIENT_TOKEN is configured while publishing source wiley_browser on success. science, pnas, annualreviews, royalsocietypublishing, acs, iop, aip, and mdpi routes use provider-managed browser runtime HTML plus seeded-browser publisher PDF/ePDF repo-local workflows; AMS uses direct HTTP HTML with direct HTTP PDF fallback, publishes ams_html or ams_pdf, and does not request citation_xml_url / /doc/...xml; Annual Reviews publishes annualreviews_html or annualreviews_pdf; Royal Society Publishing publishes royalsocietypublishing_html or royalsocietypublishing_pdf and does not use citation_xml_url as an XML route; ACS publishes acs; IOP publishes iop_html or iop_pdf, rejects Radware/hCaptcha challenge pages, and does not implement unauthenticated TDM XML/PDF; AIP publishes aip_html or aip_pdf; MDPI publishes mdpi_html or mdpi_pdf and does not use an XML route. ieee uses landing metadata, the Xplore dynamic HTML endpoint, and direct HTTP PDF fallback while publishing ieee_html or ieee_pdf. arxiv uses ID-derived official HTML first, optional API/HTML metadata merge, and PDF fallback while publishing arxiv_html or arxiv_pdf. copernicus uses direct HTTP landing discovery, public NLM/JATS XML, and PDF fallback before metadata fallback while publishing copernicus_xml or copernicus_pdf; it does not need browser runtime or credentials. royalsocietypublishing uses CDP browser DOI HTML with CDP browser-seeded PDF fallback while publishing royalsocietypublishing_html or royalsocietypublishing_pdf. plos uses public JATS XML with direct HTTP PDF fallback while publishing plos_xml or plos_pdf. frontiers discovers canonical Frontiers article routes from landing HTML, then uses public JATS XML with direct HTTP PDF fallback while publishing frontiers_xml or frontiers_pdf. oxfordacademic uses direct HTTP article HTML with direct HTTP PDF fallback while publishing oxfordacademic_html or oxfordacademic_pdf. PDF fallback saves exported PDF images for body/all requests when artifact saving is enabled. On successful HTML/XML routes, asset_profile='none' disables local asset downloads but keeps rendered remote Markdown image links when the provider can resolve them. asset_profile='body' means provider-cleaned body figure/table/formula assets only, while asset_profile='all' additionally downloads supplementary files; supplementary files are saved as assets but are not emitted as ImageContent. Wiley/Science/PNAS/Annual Reviews/Royal Society Publishing/ACS/IOP/AIP/MDPI support body/all assets on successful CDP browser HTML routes and share the PDF/ePDF fallback image export behavior with Springer/IEEE/arXiv/Copernicus. Set download_dir to isolate task-local downloads; the MCP server can also surface scoped cache resources for that directory during the current session.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modesNo
queryYes
strategyNo
max_tokensNofull_text
no_downloadNo
download_dirNo
include_refsNo
prefer_cacheNo
artifact_modeNomarkdown-assets
save_markdownNo
markdown_filenameNo
markdown_output_dirNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
doiNo
codeNo
traceNo
reasonNo
sourceNo
statusNo
articleNo
qualityNo
markdownNo
metadataNo
providerNo
warningsNo
candidatesNo
http_statusNo
missing_envNo
content_kindNo
has_abstractNo
has_fulltextNo
source_trailNo
error_categoryNo
schema_versionNo
token_estimateNo
retry_after_secondsNo
saved_markdown_pathNo
token_estimate_breakdownNo
Behavior5/5

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

The description goes beyond annotations, detailing side effects such as caching, file saving, asset downloads, and error payload structure. Annotations already indicate non-read-only and side effects, but the description adds concrete behaviors like cache fallback and markdown saving.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely long and dense, containing detailed provider route information that could be summarized. While it front-loads the core purpose, the sheer volume of text reduces scannability and may overwhelm an AI agent.

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 complexity (12 parameters, many with conditional behavior) and the presence of an output schema, the description covers nearly all relevant aspects. It explains provider-specific fallbacks and interactions between parameters, leaving few gaps.

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%, so the description carries the full burden. It explains every parameter in prose, including defaults, provider-specific behaviors, and the meaning of values like 'full_text' for max_tokens. This compensates fully for the lack of schema descriptions.

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 'Fetch AI-friendly paper content' and mentions the return object structure. It distinguishes fetch_paper from sibling tools implicitly by focusing on fetching, but does not explicitly differentiate from resolve_paper or get_cached.

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 provides extensive detail on parameter behaviors and defaults, but lacks explicit guidance on when to use this tool versus siblings like resolve_paper or has_fulltext. Some usage context is given (e.g., 'Set prefer_cache=true to resolve the query to a DOI...'), but no overall when-to-use statement.

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/Dictation354/paper-fetch-skill'

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