Paper Nexus

Search papers

search_papers

Read-onlyIdempotent

Find scientific papers by title and get their Paper Nexus ids, which recommend_papers takes. The query can also be a DOI or a link to a paper (doi.org, arXiv, PubMed, publisher pages). Returns up to limit matches, best first. Pass fields to get only the details of each paper you need.

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": {
      "query": "<query>"
    },
    "name": "search_papers"
  }
}

Input Schema

Name	Required	Description
`limit`	No
`query`	Yes	A paper title (or part of one), a DOI, or a link to a paper
`fields`	No	Only these fields of each paper, to keep the result short; the id always comes back. Leave it out for every field.

Output Schema

Name	Required	Description
`results`	Yes
`timed_out`	No
`too_broad`	No
`unread_link`	No
`closest_matches`	No	Nothing matched every word; these are the nearest titles

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add call-shaping detail — and it does: results are capped by limit, ordered best-match-first, and fields can be used to trim payloads. It omits what happens on zero matches or how loose the title matching is, but nothing contradicts the annotations.

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?

Three sentences, front-loaded with purpose and the downstream consumer, then query flexibility, then result shaping. Dense but every clause carries information; no filler or restated title.

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?

An output schema exists, so return values need not be described, and the description still covers the three dimensions an agent must decide on: acceptable query forms, result count/ordering, and field projection. Adequate for a 3-parameter search tool, with only edge-case behavior (empty results, partial-match strictness) left implicit.

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 67%, and the description compensates for the uncovered params: it explains that limit is an upper bound on returned matches rather than an exact count, that results are ranked best first, and that fields exists to shorten results (with the id always returned, per the schema). It adds ranking and result-shaping meaning beyond the bare types.

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 (find scientific papers), names the concrete return artifact (Paper Nexus ids), and explicitly links the output to the sibling that consumes it (recommend_papers). This distinguishes it from get_paper and the list_* siblings 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 Guidelines4/5

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

The description makes the usage contract clear: it is the entry point whose ids feed recommend_papers, and it accepts a title, DOI, or paper link. It does not explicitly say when to prefer get_paper (single known paper) over this search, so routing guidance is strong but not exhaustive.

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.