This server lets you discover, retrieve, analyze, and organize academic papers through search, citation graphs, and a personal knowledge base.
Search for papers across multiple academic sources with filters (year, venue, citations, fields of study, open access) and ranking intents.
Get paper details including citations and references using identifiers like DOI, arXiv ID, or Semantic Scholar ID.
Find related papers with Semantic Scholar's recommendation engine.
Search for authors to find researcher profiles.
Read papers by downloading PDFs and extracting text, with optional page limits.
Search OpenReview for conference papers such as ICLR, NeurIPS, and ICML.
Build citation graphs from seed papers, expanding citations and references with topic and citation filters.
Manage a knowledge base: save, list, search, organize papers into collections, and attach notes.
Discover a research field by collecting surveys, foundational papers, and recent advances.
Check server status for version, available sources, and knowledge-base collections.
Search papers and download PDFs from arXiv.
Search papers from DBLP computer science bibliography.
Search papers from INSPIRE-HEP high-energy physics literature.
Search papers from PubMed biomedical database.
Search papers and use API from Semantic Scholar with optional API key for higher rate limits.
Download PDFs from SSRN preprint server.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@scholar-mcp search papers on transformer architectures"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Scholar MCP turns a research question into a connected body of evidence. It recovers papers from vague descriptions, reaches the work one hop beyond search, opens the primary text, maps the lineage, and carries the selected field into a library that grows with every session.
Natural-language discovery · Related-work discovery · Primary evidence · Field maps · Zotero · Obsidian · Notion connectors
One continuous agent flow: search_papers → build_paper_graph → paper_info + read_paper → paper_library → library connectors.
Related MCP server: Crossref Academic MCP Server
Agents call typed MCP tools over stdio or Streamable HTTP. Scholar returns concise text and structured data, while a persistent SQLite library drives FTS5 search, PDF attachments, JSONL snapshots, and Obsidian, Zotero, and Notion connectors.
Claude Code:
claude mcp add scholar -- uvx scholar-mcpClaude Desktop or any stdio MCP client:
{
"mcpServers": {
"scholar": {
"command": "uvx",
"args": ["scholar-mcp"]
}
}
}The direct server exposes the compact core profile. Python 3.10+ and uv are required. Optional source keys unlock deeper coverage and higher throughput.
The repository also ships a research plugin with citation graphs, a local paper library, and the Deep Research skill:
# Codex
codex plugin marketplace add Liyux3/scholar-mcp
codex plugin add scholar-mcp@scholar-mcp
# Claude Code
claude plugin marketplace add Liyux3/scholar-mcp
claude plugin install scholar-mcp@scholar-mcpThe same plugin directory follows the Agent Plugins standard for Cursor, Pi, and compatible harnesses. OpenCode can launch uvx scholar-mcp as a local MCP; Pi can use pi-mcp-adapter.
Release artifacts also include the PyPI package, multi-architecture GHCR image, and macOS MCPB bundles. See the complete distribution matrix.
Profile | Tool | Responsibility |
Core |
| Multi-source retrieval, filters, reranking, and citation discovery |
Core |
| Paper detail, citations, and references through one selective call |
Core |
| Related work through semantic and citation connections |
Core |
| Author profiles, affiliations, paper counts, and h-index |
Core |
| Temporarily fetch and read a complete paper in one call |
Core |
| Persist a PDF and index it in a collection |
Research |
| Bounded citation graph with PageRank, bridges, nodes, edges, and Mermaid |
Research |
| Collections, FTS search, notes, tags, PDFs, and Markdown vault export |
scholar://status reports source availability and the actual reranker used without occupying the tool surface. Tool responses retain concise YAML text and also expose structured MCP data.
The bundled Deep Research skill turns search, paper inspection, graph traversal, and selected library writes into a living field map.
Channel | Sources | Query form and role |
Semantic | OpenAlex semantic, arxiv.gg, optional Exa | Full natural-language question |
Full text | Semantic Scholar snippet search | Matching passages from open-access papers |
Broad metadata | OpenAlex, Semantic Scholar, Crossref, optional Scopus | Identity, coverage, citations, and filters |
Preprints and conferences | arXiv, OpenReview | Recent work and conference records |
Biomedical | PubMed, Europe PMC | Medicine, biology, and full-text repositories |
Domain and repository | DBLP, INSPIRE-HEP, DOAJ, CORE, OpenAIRE, HAL | CS, physics, open journals, and repositories |
Web fallback | Google Scholar | Best effort; blocking is reported as degradation |
Keyword APIs receive measured source-specific query budgets. Semantic endpoints keep the original question. Every source contributes independently to one canonical evidence pool.
Results are canonicalized across DOI, arXiv, Semantic Scholar, OpenAlex, PubMed, and OpenReview identities. Duplicate records contribute complementary metadata and independent source evidence instead of appearing several times.
DashScope qwen3-rerank is the primary reranker when configured; FlashRank is the local fallback. The normal response shows only source coverage, the actual reranker, and actionable degradation. debug=true adds per-source yield, latency, provenance, and internal ranking diagnostics.
Scholar leads the Exa research-paper baseline by 10 points at R@5 and 6 points at R@20 on matched LitSearch.
System | R@5 | R@10 | R@20 | MRR |
Scholar | 0.62 | 0.68 | 0.70 | 0.442 |
Exa | 0.52 | 0.58 | 0.64 | 0.435 |
BM25 | 0.46 | 0.46 | 0.56 | 0.335 |
Scholar recovered nine R@5 hits that Exa missed; Exa recovered four that Scholar missed.
The comparison uses the same first 50 LitSearch inline-ACL queries, ground-truth titles, title matcher, and top-20 cutoff. Exa ran with category research paper. Scholar used its standard retrieval pipeline with Qwen reranking. BM25 follows the official LitSearch title+abstract implementation: lowercase tokenization, English stopword removal, Porter stemming, and BM25Okapi over the 64K-paper corpus. The Scholar/Exa run was collected on 12 May 2026; BM25 was reproduced on 25 August 2026. The frozen summary is in docs/benchmarks/litsearch-inline-acl-50.json, with raw BM25 results and their hash manifest.
Rendered from a live local collection, the graph reveals foundations, bridges, and the papers that move a field forward. Stable identities and parallel citation traversal keep the map connected as it grows.
The paper library uses one persistent SQLite authority with WAL transactions and FTS5 search. Existing JSONL collections migrate automatically and remain available as compatibility snapshots. Stable identifiers, notes, tags, PDF paths, connector IDs, and sync revisions stay attached to the same canonical record.
Default data layout:
~/.scholar-mcp/
├── papers/ persistent PDFs
├── kb/
│ ├── library.sqlite3 authority + FTS5 + sync state
│ └── *.jsonl compatibility snapshots
└── vault/ Markdown projections and wikilinks# No login: write directly into an Obsidian vault
scholar-mcp library export obsidian --collection rag --path /path/to/vault
# Dry-run by default; add --apply for external writes
scholar-mcp library sync zotero --collection rag
scholar-mcp library publish notion --collection ragObsidian is a live Markdown projection. Zotero manages bibliographic items, collections, tags, and notes. Notion receives a one-way reading-list view. External connectors keep their IDs, versions, and content hashes in SQLite, so unchanged papers do not publish twice.
read_paper uses a temporary PDF and reads pages 1-10 by default, which usually reaches the conclusion of an AI conference paper. It returns page-aware Markdown, structured tables when their geometry is reliable, and caption selectors for figures and visual table fallbacks. Pass visual="Figure 3" or another returned selector to receive one focused page crop alongside its text. Pass pages="11-20" to continue into references or appendices. The PDF is removed after extraction. download_paper streams into a staging file, atomically publishes a validated PDF, reuses a valid local copy, and indexes its metadata in the selected collection.
The shared resolution chain covers:
Native open-access records and canonical archives such as arXiv and Europe PMC
Registered repository resolvers: CORE, OpenAIRE, HAL, Zenodo, and DOAJ
bioRxiv, medRxiv, SSRN, ChemRxiv, and other preprint servers
Unpaywall and an optional institutional proxy
an explicit local fallback when enabled
scholar-mcp sources prints the live registry-derived capability matrix. Zenodo participates in PDF resolution but stays out of default discovery because its broad publication records add more candidate noise than retrieval value.
All credentials are optional and remain in the MCP process environment.
Variable | Purpose |
| Shared data root; default |
| SQLite library and JSONL snapshot directory |
| Obsidian projection root; no authentication required |
| Semantic Scholar search, snippets, graph, and rate limits |
| OpenAlex search, semantic search, and graph calls |
| OpenAlex polite pool and Unpaywall |
| Qwen reranker |
| Optional Scopus metadata source |
| Optional CORE repository source |
| Optional Exa research-paper source |
| OpenReview API |
| Initial source fan-out budget; default 8 seconds |
| Persistent PDF directory; default |
| Use |
| Zotero Web API or authorized local API connector |
| Optional Zotero library type and endpoint override |
| Notion one-way publisher |
Errors returned to the model redact request URLs and credentials.
git clone https://github.com/Liyux3/scholar-mcp.git
cd scholar-mcp
uv sync --extra dev
uv run pytestUnit tests are the default. Live API tests are marked integration and run separately with uv run pytest -m integration; pytest reports them as deselected during the deterministic unit run because the marker filter intentionally leaves network-dependent cases out of that invocation.
Connector and feature contributions follow CONTRIBUTING.md. Report security issues through the private process in SECURITY.md; citation metadata is available in CITATION.cff.
Local and Docker clients use stdio by default. Set SCHOLAR_MCP_TRANSPORT=http for Streamable HTTP; the default endpoint is /mcp.
Apache License 2.0
Resolve one paper to an open-access PDF and save it to disk, optionally indexing it into a library collection.
Writes a file under save_dir (default: the configured papers directory); a repeat call for the same paper overwrites the same path. Use read_paper instead when you only need the text once. Resolution tries the canonical archive (arXiv, Europe PMC), repository resolvers, preprint servers and Unpaywall in order; a paywalled paper with no open copy returns a clear failure and writes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| paper_id | Yes | Paper identifier (S2 ID, DOI, ArXiv:ID, etc.) | |
| save_dir | No | Directory to save PDF (default: configured download directory) | |
| collection | No | Knowledge-base collection to index the PDF in. Empty disables indexing. | downloads |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent, non-destructive write behavior, and the description adds valuable details beyond them: repeat calls overwrite the same path, resolution tries specific sources in order, and a failed resolution writes nothing. There is no contradiction with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the primary purpose, then adds necessary behavioral and alternative-tool context. Every sentence contributes useful information without filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key operational details: resolution order, file persistence and overwrite semantics, indexing option, failure behavior, and the alternative read_paper. With the output schema and annotations also present, an agent has enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description mostly restates defaults and indexing behavior rather than adding new parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: resolving one paper to an open-access PDF and saving it to disk. It also distinguishes itself from read_paper by noting the alternative is for text-only needs, making the tool's purpose and scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names read_paper as the alternative and states the condition for choosing it: when only the text is needed once. It also clarifies that paywalled papers with no open copy fail cleanly, helping an agent decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for one known paper, optionally with the papers that cite it and the papers it references.
Use this when you already have an identifier; use search_papers to find one first, and recommend_papers for related work that is not a direct citation. Read-only, one upstream lookup per requested section. An unresolvable identifier returns a not-found message rather than an error. Citation and reference lists are ordered by influence and cut at limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max citations/references to return (default 20) | |
| include | No | Comma-separated: "detail", "citations", "references" (default: "detail") | detail |
| paper_id | Yes | Paper identifier (S2 ID, DOI, ArXiv:ID, OpenAlex W-ID, etc.) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, and the description adds valuable behavior: "one upstream lookup per requested section," "unresolvable identifier returns a not-found message rather than an error," and lists "ordered by influence and cut at limit." This gives the agent concrete expectations beyond safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core purpose appears in the first sentence, usage routing in the second, and behavioral notes in short, scannable sentences. Every sentence adds information; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema, full parameter schema descriptions, and strong annotations, the description covers all necessary selection and invocation context: when to use it, alternatives, error behavior, list ordering, and truncation. No critical operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds useful semantic context by explaining that citation and reference lists are "ordered by influence and cut at limit," clarifying how the limit parameter behaves and how include sections are returned. It does not need to restate schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: "Get metadata for one known paper, optionally with the papers that cite it and the papers it references." This clearly distinguishes it from search-oriented tools by emphasizing a known identifier, and the title reinforces the citation-neighborhood scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: "Use this when you already have an identifier," and names alternatives: "use search_papers to find one first, and recommend_papers for related work that is not a direct citation." This provides clear routing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a paper's PDF into a temporary file and return page-aware Markdown text plus selectors for its figures and tables.
Use this to read; use download_paper to keep the PDF. Nothing persists after the call. Resolution follows the same open-access chain as download_paper, so paywalled papers without an open copy fail cleanly. Pass a selector from a previous response as visual to get one figure or table with its surrounding text.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | One-indexed page range. The default usually reaches the conclusion of an AI conference paper. Use ranges such as "11-20" for appendices. At most 20 pages can be read per call. | 1-10 |
| visual | No | Optional selector returned by this tool, such as "Figure 3", "Table 2", or "page 5". Returns one focused visual with its text. | |
| paper_id | Yes | Paper identifier (S2 ID, DOI, ArXiv:ID, etc.) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses temporary file behavior, non-persistence of data, the open-access resolution chain, clean failure for paywalled papers, and the focused visual return behavior. This is substantial behavioral context that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no filler. The core purpose is front-loaded, usage guidance follows, and the visual workflow is placed at the end. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema is present and annotations cover safety traits, the description covers what remains important: temporary persistence, failure behavior, sibling differentiation, and how to chain selectors into a visual call. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters well. The description adds workflow-level meaning for pages (default reaches conclusion, max 20 pages) and visual (pass a selector from a previous response), which goes beyond the schema's per-parameter text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: fetch a paper's PDF into a temporary file and return page-aware Markdown text with figure and table selectors. It clearly differentiates itself from download_paper by noting that download_paper is the alternative for keeping the PDF.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use this to read; use download_paper to keep the PDF.' It also explains when the tool fails cleanly for paywalled papers and how to use a previous response selector as the visual parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find related papers by a chosen citation-graph relation.
Use this when you hold one paper and want its neighbourhood. Use search_papers for a topic and paper_info for a paper's direct citation lists. Read-only; results come from embedding and citation data, so very new or uncited papers return few or no neighbours.
"Related" is several different questions, and which one you want depends on what you are doing:
similar embedding neighbours (SPECTER2). Same topic, possibly
different vocabulary. Good default.
peers what is cited alongside this paper. Its intellectual
cohort, which is usually what "related work" means.
kin what cites the same works this paper does. Shared method
rather than shared topic, so this is the relation that
crosses field boundaries: two papers can be coupled
without sharing any vocabulary.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (default 10) | |
| paper_id | Yes | Paper identifier (S2 ID, DOI, ArXiv:ID, OpenAlex ID, etc.) | |
| relation | No | similar | peers | kin | similar |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds genuine behavioral context beyond those flags: results come from embedding and citation data, so 'very new or uncited papers return few or no neighbours.' It also explains the meaningful behavioral differences among the three relation types, which is not visible from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every section earns its place: a one-sentence purpose, explicit routing to alternatives, a data-source caveat, and a structured explanation of the three relation types. It is front-loaded with the core purpose and usage guidance before diving into parameter semantics, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three relation modes and an output schema, the description is complete. It covers when to use the tool, how to choose between relations, data limitations, and the meaning of each parameter. Because an output schema is present, the absence of return-format details does not hurt completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. However, the description goes well beyond the schema by explaining what each relation value means semantically: similar, peers, and kin each get a clear definition with practical implications. This is especially valuable because the schema merely lists 'similar | peers | kin' with no per-enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Find related papers by a chosen citation-graph relation.' It clearly distinguishes this tool from siblings by explicitly naming search_papers and paper_info as the alternatives for different needs, so an agent can immediately tell what recommend_papers is and is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: 'Use this when you hold one paper and want its neighbourhood.' It also names alternatives and their conditions: 'Use search_papers for a topic and paper_info for a paper's direct citation lists.' This leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for researchers by name and return profiles with affiliations, paper counts, h-index and identifiers.
Use this for people, not papers: use search_papers for papers and paper_info for a paper's own author list. Read-only. Name matching is fuzzy, so common names return many candidates; add an affiliation or field word to the query and keep limit small to disambiguate.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (1-1000, default 5) | |
| query | Yes | Author name to search for |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond annotations: fuzzy name matching, common names returning many candidates, and the resulting need for disambiguation. This is meaningful behavioral disclosure that helps the agent set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences each earn their place: purpose, routing guidance, and behavioral/usage tip. There is no filler or redundancy, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the strong annotations, complete parameter schema, output schema presence, and explicit sibling comparisons, the description covers purpose, usage, behavior, and parameter semantics thoroughly. Nothing material is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both query and limit are already documented. The description goes further by explaining that the query supports affiliation or field words and that matching is fuzzy, which adds semantic value beyond the bare schema. The guidance to keep limit small also clarifies how the limit parameter relates to the fuzzy matching behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Search for researchers by name' and enumerates the returned fields (affiliations, paper counts, h-index, identifiers). It also differentiates itself from the sibling tools search_papers and paper_info, making its purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this for people, not papers,' and names the alternatives for each different case: search_papers for papers and paper_info for a paper's own author list. It also gives concrete disambiguation advice: add an affiliation or field word and keep limit small.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for academic papers across many sources (OpenAlex, Semantic Scholar, arXiv, PubMed, OpenReview, Crossref and more), merge duplicates across DOI/arXiv/S2/OpenAlex identities, and rerank for relevance.
Use this to find papers from a topic, a question, or a half-remembered title. Use paper_info when you already hold an identifier, recommend_papers to expand from one known paper, and search_authors for people. Read-only. Each call fans out to live APIs under a time budget; sources that time out are reported as degraded coverage instead of failing the call. Put years, venues and filters in the parameters, not in the query text.
| 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 | Search query (e.g., "attention is all you need", "CRISPR gene editing") | |
| 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"). 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful behavioral detail: fan-out to live APIs under a time budget, degraded coverage reporting for timed-out sources, and duplicate merging across identities. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-sentence but every sentence earns its place: core function, usage routing, behavioral caveats, and a parameter-usage hint. It is organized and front-loaded without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, sibling alternatives, failure-mode behavior, and parameter usage in a compact form. With an output schema present, return-value details are not needed. No critical information for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented. The description adds general guidance about where filters belong and the reranking behavior, which is helpful but does not need to re-explain individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Search for academic papers across many sources') and lists concrete sources, duplicate merging, and reranking. It also distinguishes itself from siblings by routing paper_info to identifier lookups, recommend_papers to expansion, and search_authors to people.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('find papers from a topic, a question, or a half-remembered title') and gives alternatives for other cases. It adds practical advice to put years, venues, and filters in parameters rather than the query text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.8.3build_paper_graphdiscover_fielddownload_paperknowledge_basepaper_info4 fields changedOutput schema / additionalPropertiesAdded value: +trueOutput schema / propertiesRemoved value: -{
- "result": {
- "type": "string"
- }
-}Output schema / requiredRemoved value: -[
- "result"
-]Output schema / x-fastmcp-wrap-resultRemoved value: -trueread_paper9 fields changedInput schema / properties / extract_textRemoved value: -{
- "default": true,
- "description": "If True, extract and return text. If False, just download PDF.",
- "type": "boolean"
-}Input schema / properties / max_pagesRemoved value: -{
- "default": 0,
- "description": "Maximum pages to extract (0 = all pages)",
- "type": "integer"
-}Input schema / properties / pagesAdded value: +{
+ "default": "1-10",
+ "description": "One-indexed page range. The default usually reaches the conclusion\nof an AI conference paper. Use ranges such as \"11-20\" for appendices.\nAt most 20 pages can be read per call.",
+ "type": "string"
+}Input schema / properties / save_dirRemoved value: -{
- "default": "",
- "description": "Directory to save PDF (default: configured download directory)",
- "type": "string"
-}Input schema / properties / visualAdded value: +{
+ "default": "",
+ "description": "Optional selector returned by this tool, such as \"Figure 3\",\n\"Table 2\", or \"page 5\". Returns one focused visual with its text.",
+ "type": "string"
+}Output schema / additionalPropertiesAdded value: +trueOutput schema / propertiesRemoved value: -{
- "result": {
- "type": "string"
- }
-}Output schema / requiredRemoved value: -[
- "result"
-]Output schema / x-fastmcp-wrap-resultRemoved value: -truerecommend_papers6 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum recommendations (1-500, default 10)"New value: +"Maximum results (default 10)"Input schema / properties / relationAdded value: +{
+ "default": "similar",
+ "description": "similar | peers | kin",
+ "type": "string"
+}Output schema / additionalPropertiesAdded value: +trueOutput schema / propertiesRemoved value: -{
- "result": {
- "type": "string"
- }
-}Output schema / requiredRemoved value: -[
- "result"
-]Output schema / x-fastmcp-wrap-resultRemoved value: -truescholar_statussearch_authors4 fields changedOutput schema / additionalPropertiesAdded value: +trueOutput schema / propertiesRemoved value: -{
- "result": {
- "type": "string"
- }
-}Output schema / requiredRemoved value: -[
- "result"
-]Output schema / x-fastmcp-wrap-resultRemoved value: -truesearch_openreviewsearch_papers11 fields changedInput schema / properties / debugAdded value: +{
+ "default": false,
+ "description": "Include per-source latency, provenance, and internal ranking diagnostics.",
+ "type": "boolean"
+}Input schema / properties / intent / defaultPrevious value: -""New value: +"balanced"Input schema / properties / intent / descriptionPrevious 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."Input schema / properties / intent / enumAdded value: +[
+ "balanced",
+ "foundational",
+ "recent",
+ "survey",
+ "method",
+ "dataset"
+]Input schema / properties / sort / defaultPrevious value: -""New value: +"relevance"Input schema / properties / sort / descriptionPrevious 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."Input schema / properties / sort / enumAdded value: +[
+ "relevance",
+ "citations",
+ "date"
+]Output schema / additionalPropertiesAdded value: +trueOutput schema / propertiesRemoved value: -{
- "result": {
- "type": "string"
- }
-}Output schema / requiredRemoved value: -[
- "result"
-]Output schema / x-fastmcp-wrap-resultRemoved value: -truev0.6.0build_paper_graphdiscover_fieldknowledge_basepaper_inforead_paperrecommend_papersscholar_statussearch_authorssearch_openreviewsearch_papersScored across 6 tools
Each tool targets a clearly distinct task: finding papers, looking up a known paper, exploring related work, finding authors, downloading PDFs, and reading PDFs. The descriptions explicitly cross-reference when to use one tool instead of another, eliminating ambiguity.
Most tools follow a clear verb_noun pattern: search_papers, search_authors, download_paper, read_paper, recommend_papers. The outlier is paper_info, which uses noun_info instead of a verb like get_paper_info, creating a minor inconsistency.
Six tools is a well-scoped size for an academic search and reading server. Each tool covers a necessary part of the workflow without redundancy or bloat.
The tool set covers the full scholarly research loop: discovering papers, retrieving metadata, finding related work, identifying authors, and accessing full text by downloading or reading. No obvious dead ends or missing core operations for the stated purpose.
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Multi-engine scholarly research server for search, traversal, full text, and reading lists.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Liyux3/scholar-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
