Skip to main content
Glama

Search papers

search_papers
Read-only

Searches full-text, peer-reviewed papers from top-tier venues. Use for questions about academic papers, research topics, literature reviews, surveys, “what's been published on X”, named methods, or any claim that should be backed by a peer-reviewed citation. Returns each paper's metadata and the passages that matched. Hybrid semantic + lexical search over titles, abstracts, and full text. Phrase the query the way a researcher would describe the topic in prose, not a keyword bag. Triggering questions: “what's the latest on diffusion guidance”, “which papers compare against SimPO” (requirements beyond the topic are checked per paper: conditions, evidence first in contexts). paper_id is a handle for YOU to fetch full text via get_paper_fulltext; never show it to the user: cite papers by title, authors, and venue. rerank_score is the calibrated Cohere Rerank v3.5 relevance (0..1), null when the reranker did not run (a lone term, or a failure); score is uncalibrated: keep the hits' order. The top-level best_score and low_confidence derive from rerank_score: low_confidence marks weaker matches, so rephrase for stronger ones and still cite a hit that fits; with no reranked hit, best_score is null and low_confidence false, so judge each hit yourself. Each hit carries metadata, abstract, ids, and contexts spans to ground or quote from; detail: false returns concise hits with one snippet. Page with offset (re-call with offset += limit while has_more is true and conditions match page 1's; offset + limit <= 50). Order with sort_by (relevance / date / citations, within the ranked shortlist, not the corpus). Narrow with year_min / year_max / venues.

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

NameRequiredDescriptionDefault
yearNo
limitNo
queryYesFull natural-language research query; phrase it the way you would ask a human research assistant. On the paper corpus the server drops request wording ("find me papers on"), adds the standard names of what the query describes and a hypothetical abstract (HyDE), and expands an abbreviation only when the rest of the query fixes its meaning, so give context ("MPC for drone control", not "MPC"); a lone term is searched as typed, without expansion, HyDE or rerank. The richer the input, the better the recall. Good: "methods for retrieval-augmented generation that reduce hallucination on long-form QA". Less optimal: "RAG hallucination".
detailNotrue (default): include the full abstract, ids, and contexts[] matched spans for grounding. false: concise hits (title, authors, year, venue, citations, score, and a single grounding snippet) for token-saving triage. For the complete paper text call get_paper_fulltext.
offsetNoPagination offset over the ranked results. Re-call with offset += limit while the response `has_more` is true. offset + limit must stay <= 50.
venuesNoRestrict to these conference short names (e.g. ["NeurIPS", "ICML"]).
sort_byNoResult ordering within the ranked shortlist: `relevance` (default), `date` (newest first), or `citations` (most-cited first).relevance
year_maxNoOnly include papers published in this year or earlier.
year_minNoOnly include papers published in this year or later.
conferenceNoFilter by conference short name, e.g. "CCS", "NeurIPS".

Output Schema

NameRequiredDescriptionDefault
resultsYesThe ranked hits.
has_moreYesTrue when more results exist past this page; re-call with offset += limit.
best_scoreYesThe highest per-hit rerank_score (calibrated 0..1), or null when no hit was reranked (a lone-term query, or a reranker failure) or there were no results.
conditionsNoWhat the request requires of its papers beyond the topic (compares against a method, evaluates on a dataset, releases code), when the search checked it in the papers' own text: every hit meets each, with its evidence first among its contexts, and an empty first page means none of the top-ranked papers the check read does. Absent when nothing was checked, so the hits are unverified.
low_confidenceYesTrue when the best rerank_score fell below the relevance floor: these are weaker matches, so rephrase for stronger ones and still cite a hit that fits. False when a hit cleared the floor, and also when no hit was reranked or there were no results: best_score is then null, so there is no calibrated basis and you judge each hit's fit yourself.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare read-only, open-world, non-destructive, but the description adds substantial operational detail beyond them: query rewriting/HyDE behavior, the lone-term exception that skips expansion and rerank, the calibration difference between rerank_score and score, the meaning of low_confidence and null best_score, and the hard offset + limit <= 50 cap. It also warns that sort_by orders within the ranked shortlist rather than the corpus, which an agent could not guess from schema alone.

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?

Purpose and triggers are front-loaded, which is good, but the single dense paragraph then spends a large share of its length explaining return values (rerank_score, score, best_score, low_confidence) that the existing output schema already covers. That duplication bloats an otherwise efficient call-guidance block.

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 10-parameter tool with annotations and an output schema, this is close to complete — query construction, pagination, sorting semantics, and confidence signaling are all covered. The remaining holes are the unmentioned `year` param and the ambiguous relationship between `conference` and `venues`.

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 80%, so the baseline is 3, but the description meaningfully extends several params — how to phrase `query`, what `detail: false` returns, and that pagination continues only while `has_more` is true and `conditions` match page 1. It leaves gaps: the `year` parameter is never mentioned alongside `year_min`/`year_max`, and the overlap between `conference` and `venues` is unaddressed, so two of ten parameters get no clarifying treatment.

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 with scope: "Searches full-text, peer-reviewed papers from top-tier venues." It immediately characterizes the corpus (peer-reviewed, full text) and the retrieval mode (hybrid semantic + lexical over titles, abstracts, full text), which is enough to separate it from siblings like get_conference_papers or get_paper_fulltext.

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 concrete when-to-use triggers (literature reviews, "what's been published on X", claims needing peer-reviewed citations) plus sample phrasings, which is well above typical guidance. It also routes full-text needs to get_paper_fulltext. It stops short of explicit when-not-to-use and never mentions search_papers_many or search_related_papers, leaving the agent to infer the boundary between the three search siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.