litreview-mcp

Search papers

search_papers

Read-only

Find scholarly papers by topic through title and abstract matching. Returns compact summaries for literature reviews; use exact phrases in quotes for precision.

Instructions

Search scholarly papers by topic, matching titles and abstracts. Returns compact summaries without abstracts; use get_paper for details. Put exact phrases in double quotes for much better precision, e.g. "growth mindset" teachers. With sort "citations" or "newest", results are the top 200 most relevant papers re-ranked, so a famous paper that matches the query poorly can be missed. Each search uses some of the server's daily budget, so prefer a few well-chosen queries.

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	Default
`sort`	No	Use "citations" to find seminal papers, "newest" for current research	relevance
`limit`	No	How many papers to return
`query`	Yes	Topic to search for
`to_year`	No	Only papers published in or before this year
`from_year`	No	Only papers published in or after this year
`open_access_only`	No	Only papers that are free to read

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well past readOnlyHint/openWorldHint: it discloses the result content (no abstracts), a re-ranking behavior that can silently omit famous papers under citations/newest sorts, and a shared daily budget that caps how often the tool can be used. The ranking caveat is a non-obvious failure mode an agent would otherwise not anticipate.

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 sentences, no filler, with the core capability front-loaded and each following sentence adding either routing, query syntax, ranking caveat, or budget constraint. Nothing repeats the schema or annotations.

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 6-parameter search tool with no output schema, the description supplies the return shape, the sibling handoff, query syntax, ranking semantics, and rate-limit context. An agent has everything needed to call it correctly and to interpret truncated or surprising results.

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 100%, so the baseline is 3, but the description adds real meaning: quoted-phrase syntax for the query string and an explanation of what the sort values actually do to the result set. limit, from_year, to_year, and open_access_only are left entirely to the schema, so it stops short of full coverage.

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+resource ("search scholarly papers") plus the matching scope (titles and abstracts) and what comes back (compact summaries without abstracts). It also names the sibling get_paper and the boundary between them, so an agent can route between the two without checking 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 Guidelines5/5

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

Gives explicit when-to-use for get_paper (details), actionable query tactics (exact phrases in double quotes), and when to pick each sort mode. It also includes a usage constraint (prefer a few well-chosen queries due to daily budget) that shapes how often the agent should call it.

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

Deploy Server