Skip to main content
Glama
Sign In

Lune Research

by com.luneresearch
OverviewDiscussionsAdmin

Get paper citations

get_paper_citations
Read-onlyIdempotent

Use this when the user asks “what does this paper build on”, “what built on this”, traces influence chains, asks for follow-up work, or wants the lineage of an idea. direction=cited_by returns indexed papers that cite this one; direction=cites returns this paper's parsed references (which may or may not be in the corpus). Each edge carries contexts, the citing sentences with their section, which show HOW a work is used (baseline, method borrowed, result disputed). Page with limit / offset; the response reports total and has_more so you can walk a large citation set.

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_id": "<paper_id>"
    },
    "name": "get_paper_citations"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax citation edges to return per page (default 25, max 100).
offsetNoPagination offset; re-call with offset += limit while the response `has_more` is true. The response also reports `total`.
paper_idYesA corpus paper UUID, taken from a `search_papers` or `search_related_papers` result.
directionNo`cited_by`: indexed papers that cite this one (forward, follow-up work). `cites`: this paper's parsed references (back, what it built on).cited_by

Output Schema

NameRequiredDescriptionDefault
totalNoTotal visible citation edges in this direction (paging count).
has_moreNoTrue when more edges exist past this page; re-call with offset += limit.
citationsYes
directionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, open-world behavior, so safety is covered; the description adds genuinely non-obvious context: `cites` returns parsed references that may not be in the corpus, unlike the indexed `cited_by` results. It also explains that `contexts` carries citing sentences with section, and how to interpret them (baseline, method borrowed, result disputed), which is behavioral value beyond the annotations and output schema.

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

Conciseness4/5

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

Usage triggers are front-loaded, then direction semantics, then pagination, which is a sensible order with no filler sentences. The list of example phrasings is slightly verbose but each maps to a real query pattern.

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 a 4-parameter read-only tool with full schema coverage, an output schema, and rich annotations, the description covers selection, both directions, edge content, and pagination strategy. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, and the description's account of `direction` and `limit`/`offset` largely restates what the parameter descriptions already say. It adds a small amount of framing (forward vs. back, walking a large citation set) but nothing the schema doesn't already convey.

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 names a specific verb and resource (retrieving citation edges for a paper) and immediately disambiguates the two directions the tool can take, so an agent can tell exactly what it returns without opening the 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?

It gives explicit user-phrasing triggers ('what does this paper build on', 'what built on this', follow-up work, lineage of an idea) plus the condition that selects each direction, which is strong when-to-use guidance. It stops short of naming sibling tools or stating when not to use this instead of search_related_papers or verify_claims.

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

All Lune Research toolsInspect
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.

Resources