Skip to main content
Glama
AnonymousOnyx22

Paper Finder MCP

by AnonymousOnyx22
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Paper references

paper_references
Read-only

Retrieve the references a scholarly paper cites from a DOI or OpenAlex ID, with one-line abstracts, sorting, and paging to explore its bibliography and earlier source work.

Instructions

The papers that one paper cites, which is the other half of the citation graph that find_citing_papers covers. Every result carries a one line abstract, so you can judge a paper before you open it. Use it to read the bibliography of a paper, to find the source a result came from, or to work backwards from a paper to the earlier work it builds on. A showing line says which references are on this page and how many the paper lists in all, with the page to ask for next. Inputs: paper (required, a DOI like 10.1038/nature14539, a doi.org link, or an OpenAlex id like W2741809807), sort (optional, cited_by_count:desc for the most cited references first, or publication_year:asc for the oldest references first), page (optional, which page of results to show, 1 to 400, 1 by default), limit (optional, 1 to 25, default 8). Example prompt: 'what papers does DOI 10.1038/nature14539 cite?'

Input Schema

NameRequiredDescriptionDefault
pageNoWhich page of results to show, 1 to 400, 1 by default. Pass the page the showing line names to read the next page.
sortNoHow to order the references. cited_by_count:desc puts the most cited references first, publication_year:asc puts the oldest references first.
limitNoHow many results to return, 1 to 25.
paperYesA DOI like 10.1038/nature14539, a doi.org link, or an OpenAlex id like W2741809807.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. Beyond that, the description discloses meaningful behavior the annotations do not: every result carries a one-line abstract, and a 'showing line' reports which references are on the page, the total the paper lists, and the next page to request. It does not cover error behavior for invalid DOIs, which is the main remaining gap.

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

Conciseness3/5

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

The narrative portion is front-loaded and useful, but the trailing 'Inputs:' block and example prompt duplicate the JSON schema almost verbatim (limits, defaults, enum values), which is wasted space. Roughly a third of the text earns nothing beyond what structured fields already provide.

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 paginated read tool with no output schema, the description supplies what an agent needs: what each result contains (abstract), how pagination is surfaced (showing line with total and next page), and how to continue. Only failure modes and empty-result behavior are unaddressed.

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 all four parameters are already documented in the schema. The description's 'Inputs:' section restates the same ranges, defaults, and accepted identifier formats without adding new semantics. Baseline 3 applies since the schema, not the description, carries this dimension.

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?

States a specific verb and resource ('papers that one paper cites') and immediately defines itself against the sibling that covers the inverse direction ('the other half of the citation graph that find_citing_papers covers'). An agent can distinguish this from find_citing_papers without opening either schema.

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?

Gives three concrete usage scenarios (read a bibliography, trace a result's source, work backwards to earlier work) and names the sibling alternative plus the condition that separates the two. It lacks an explicit 'do not use this when...' exclusion, but the routing guidance is clear.

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

Deploy Server

Other Tools