Paper Finder

Get a paper

get_paper

Read-onlyIdempotent

Use this when the user gives a DOI, PubMed id or arXiv id and wants the paper's abstract or a free full-text link, such as "get the abstract for DOI 10.1038/s41586-021-03819-2". Pass exactly one of doi, pmid or arxiv_id. Returns the title, authors, year, venue, the start of the abstract, the free full-text link and license when the index confirms them, and the index it came from. It does not say whether the paper was retracted or whether a reference is correct.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "doi": "10.1038/s41586-021-03819-2"
    },
    "name": "get_paper"
  }
}

Input Schema

Name	Required	Description
`doi`	No	DOI such as "10.1038/s41586-021-03819-2"; a doi.org link also works
`pmid`	No	PubMed id such as "31452104"
`arxiv_id`	No	arXiv id such as "2401.12345"; an arxiv.org link also works

Output Schema

Name	Required	Description
`asOf`	Yes	Date the indexes were read (UTC, YYYY-MM-DD); they are updated continuously
`note`	Yes
`as_of`	Yes	ISO 8601 time the data was published by its source or fetched from it. A cached answer keeps the time of its fetch.
`error`	No	Present when status is not ok: a stable code, what went wrong and what to do next.
`paper`	No
`notice`	Yes
`source`	Yes	Who the data comes from, to cite and to check it against.
`status`	Yes
`untrusted_source`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 23, 2026

addedInput schema / examples

Added value: +[
+  {
+    "doi": "10.1038/s41586-021-03819-2"
+  }
+]

addedOutput schema / properties / as_of

Added value: +{
+  "description": "ISO 8601 time the data was published by its source or fetched from it. A cached answer keeps the time of its fetch.",
+  "type": "string"
+}

addedOutput schema / properties / note
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / source / description

Previous value: -"The indexes the answer was read from"New value: +"Who the data comes from, to cite and to check it against."

addedOutput schema / properties / source / properties

Added value: +{
+  "name": {
+    "type": "string"
+  },
+  "url": {
+    "type": "string"
+  }
+}

addedOutput schema / properties / source / required
```
Added value: +[
+  "name",
+  "url"
+]
```

changedOutput schema / properties / source / type

Previous value: -"string"New value: +"object"

addedOutput schema / properties / untrusted_source
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "status",
-  "notice",
-  "source",
-  "asOf"
-]New value: +[
+  "status",
+  "notice",
+  "source",
+  "asOf",
+  "untrusted_source",
+  "note",
+  "as_of"
+]

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

First observedOct 3, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the description isn't carrying the safety load. It still adds real value: fields come back only "when the index confirms them," each result carries its source index, and it explicitly disclaims two things agents commonly over-assume (retraction status, citation correctness).

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?

Front-loaded with the invocation condition, then the parameter constraint, then return contents, then limitations. Every clause contributes distinct information; nothing restates the title or the annotation hints.

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?

Covers trigger, identifier exclusivity, expected payload, conditional field presence, provenance, and known blind spots. With an output schema present, the return-value sentence is more than required, and nothing an agent needs to call this correctly is missing.

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?

"Pass exactly one of doi, pmid or arxiv_id" supplies a mutual-exclusivity/one-of constraint the schema does not encode (zero required params, no oneOf). Beyond that, the per-parameter descriptions at 100% coverage already explain formats and link acceptance, so no further semantic detail is needed.

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 (fetch a paper) plus the exact resource and identifier types, and scopes the output to abstract or free full-text link. An agent can distinguish this from search_papers/search_arxiv immediately: this one takes a known identifier, they take queries.

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?

The trigger condition is explicit ("use this when the user gives a DOI, PubMed id or arXiv id") and reinforced with a concrete example utterance, plus a scope exclusion (no retraction status, no reference validation). It does not name the search siblings as the alternative for title/keyword lookups, which leaves that routing to inference.

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

All Paper Finder 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.