Paper Nexus

List references

list_references

Read-onlyIdempotent

What a paper builds on: the papers it cites that are in Paper Nexus, most cited first, newest first or earliest first, optionally within a span of years. Pass a Paper Nexus id or papernex.us/paper/ link, or a DOI, arXiv id, PMID, PMCID or OpenAlex id. Paper Nexus stores up to 600 references a paper; for a paper with more it holds an arbitrary 600, and complete is false. Page through with offset; next_offset is null on the last page. Pass fields to get only the details of each paper you need. With filters, only the references that pass them are listed, in the same order. Most cited first ranks by citations alone, so it is led by widely cited papers this one may cite in passing. For the references closest to its own work, call recommend_papers with it as the origin and filters.cited_by set to it instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "paper": "<paper>"
    },
    "name": "list_references"
  }
}

Input Schema

Name	Required	Description	Default
`sort`	No		most_cited
`limit`	No
`paper`	Yes	A Paper Nexus id or papernex.us/paper/<id> link, or a DOI, arXiv id, PMID, PMCID or OpenAlex id
`fields`	No	Only these fields of each paper, to keep the result short; the id always comes back. Leave it out for every field.
`offset`	No
`filters`	No	Only list references that pass every filter given here, as recommend_papers' filters do; the years are year_from and year_to. Every stored reference is checked. filter_summary says how many were checked and passed.
`year_to`	No
`year_from`	No

Output Schema

Name	Required	Description
`sort`	No
`total`	No	References that are papers in Paper Nexus, within year_from and year_to when given; null when the stored list may be cut
`offset`	No
`filters`	No	The filters applied, as understood
`results`	Yes
`complete`	No
`paper_id`	Yes
`identifiers`	No	When papers were named by DOI, arXiv id, PMID, PMCID or OpenAlex id: read_as maps each to its Paper Nexus id, and unresolved lists those no Paper Nexus paper has, which were left out
`next_offset`	No
`filter_summary`	No
`reference_count`	No	References the paper has, in Paper Nexus or not; null when not known

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 12, 2026

TDQS

A4.5/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description still adds real behavioural context: a 600-reference storage cap with complete=false beyond it, offset paging with next_offset null on the last page, and that every stored reference is checked with filter_summary reporting checked/passed counts. It does not, however, describe the shape of the response beyond next_offset.

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?

Four dense sentences, all front-loaded with the core definition first, then inputs, then limits, then the alternative. The only redundancy is restating the accepted id formats that the paper parameter schema already documents, and even that is short.

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?

For an 8-parameter tool with a nested filter object, an output schema and annotations, this covers what an agent still needs to know: storage ceiling, pagination, filter evaluation semantics and the ranking caveat. Nothing material is missing before calling it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 38% and limit, year_from, year_to and sort carry little or no inline documentation, so the description has to compensate. It adds the accepted identifier formats, explains offset pagination, explains what most_cited ranking actually means, and clarifies that the years in filters are year_from/year_to. It still leaves limit's 1-50 bounds and the sort default unstated.

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 in concrete terms: 'What a paper builds on: the papers it cites that are in Paper Nexus', plus the ordering and the optional year span. It also names the sibling it is not (recommend_papers) so an agent can separate it from list_citing_papers and search_papers without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use and when-not-to-use guidance: use this for a paper's references, and call recommend_papers with the paper as origin and filters.cited_by set to it for the closest work. It also warns that 'most cited first' surfaces widely cited papers the source may only cite in passing, which steers sort choice.

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

All Paper Nexus tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.