Scholar MCP

Overview Schema Source Related Servers Discussions Admin

Search academic papers

search_papers

Read-onlyIdempotent

Find papers that answer a research question or match a remembered idea by searching multiple sources, merging duplicates, following citations, and ranking results for relevance.

Instructions

Discover papers that answer a research question or match a remembered idea.

Searches multiple sources, merges duplicates, follows citation connections, and ranks for relevance. Natural-language queries work without extra parameters. Use paper_info when you already have a paper identifier. For cross-language discovery, formulate the query in the language of the target literature, usually English for computer science and AI research.

Input Schema

Name	Required	Description	Default
`sort`	No	Hard final order. Use relevance normally; citations and date replace the reranker's ordering.	relevance
`year`	No	Filter by year or range (e.g., "2023", "2020-2024")
`debug`	No	Include per-source latency, provenance, and internal ranking diagnostics.
`limit`	No	Maximum results to return (1-100, default 10)
`query`	Yes	Describe what you want to find. Titles, distinctive phrases, and natural-language questions all work.
`venue`	No	Filter by venue (e.g., "NeurIPS", "Nature")
`intent`	No	Soft relevance focus used by reranking and expansion. Use balanced normally; alternatives are foundational, recent, survey, method, and dataset.	balanced
`paper_types`	No	Comma-separated types, e.g. JournalArticle,Conference,Review,Book,Dataset. CourtDecision selects case law; ClinicalTrialRegistration selects study registrations. Default: all types.
`min_citations`	No	Minimum citation count filter (default 0)
`fields_of_study`	No	Comma-separated fields (e.g., "Computer Science,Mathematics")
`open_access_only`	No	Only return papers with free PDF access

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.9.0Nov 3, 2026

changedInput schema / properties / paper_types / description

Previous value: -"Comma-separated types (e.g., \"JournalArticle,Conference,Review,Book,Dataset\"). Default: all types."New value: +"Comma-separated types, e.g. JournalArticle,Conference,Review,Book,Dataset.\nCourtDecision selects case law; ClinicalTrialRegistration selects study registrations.\nDefault: all types."

changedInput schema / properties / query / description

Previous value: -"Search query (e.g., \"attention is all you need\", \"CRISPR gene editing\")"New value: +"Describe what you want to find. Titles, distinctive phrases,\nand natural-language questions all work."

Changed11 schema fields changedv0.8.3Sep 5, 2026

addedInput schema / properties / debug

Added value: +{
+  "default": false,
+  "description": "Include per-source latency, provenance, and internal ranking diagnostics.",
+  "type": "boolean"
+}

changedInput schema / properties / intent / default
```
Previous value: -""New value: +"balanced"
```

changedInput schema / properties / intent / description

Previous value: -"Ranking preference. \"foundational\" for seminal papers, \"recent\" for latest work, \"survey\" for reviews, \"method\" for specific techniques. Default: balanced relevance."New value: +"Soft relevance focus used by reranking and expansion. Use\nbalanced normally; alternatives are foundational, recent, survey,\nmethod, and dataset."

addedInput schema / properties / intent / enum

Added value: +[
+  "balanced",
+  "foundational",
+  "recent",
+  "survey",
+  "method",
+  "dataset"
+]

changedInput schema / properties / sort / default
```
Previous value: -""New value: +"relevance"
```

changedInput schema / properties / sort / description

Previous value: -"Sort results by \"citations\" (most cited first) or \"date\" (newest first). Default: relevance."New value: +"Hard final order. Use relevance normally; citations and date\nreplace the reranker's ordering."

addedInput schema / properties / sort / enum

Added value: +[
+  "relevance",
+  "citations",
+  "date"
+]

addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "type": "string"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```
removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```

First observedv0.6.0May 30, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is covered. The description adds genuinely non-obvious behavior beyond that: it federates multiple sources, merges duplicates, follows citation connections to expand results, and reranks — meaning returned papers may not literally match the query. It also notes natural-language queries work with no extra parameters, which is real operational context.

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?

The core capability is front-loaded in the first two sentences, and each subsequent sentence carries a distinct routing or phrasing instruction. The language note is slightly tangential but short enough to earn its place.

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?

With an output schema present, return values need no explanation, and all 11 parameters are fully documented in the schema. The description covers purpose, alternatives, and query formulation, leaving only sibling routing to recommend_papers/search_authors unaddressed — a minor gap for a search tool of this complexity.

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%, including enum explanations for sort and intent, so the schema carries the parameter burden and baseline 3 applies. The description adds only the implication that 'query' alone is sufficient for natural-language search and a note on query language, which is modest but real added meaning.

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 states a specific verb and resource ('Discover papers') plus the two query modes it serves ('answer a research question or match a remembered idea'). It also names the sibling it is not — 'Use paper_info when you already have a paper identifier' — so an agent can route between the two without opening either 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 when-to-use (open-ended discovery, remembered-idea lookup) and one explicit when-not (already have an identifier → paper_info), plus a practical tip to phrase queries in the target literature's language. It stops short of addressing recommend_papers or search_authors, which are plausible adjacent choices for a discovery task.

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

Deploy Server