Which integrations are available for this server?

Allows searching academic literature through the Semantic Scholar API, with tools for relevance search, batch metadata retrieval, and citation-graph recommendations.

How do I use Academic Search MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Academic Search MCP search for papers on transformer models from 2020 with at least 100 citations" 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.

Academic Search MCP

by ociupitu

Overview Schema Related Servers Score Discussions

Python

Remote

Academic Search MCP Server

A Model Context Protocol (MCP) server that lets Claude Code (or any MCP client) search academic literature through the Semantic Scholar API. It is built for research workflows: relevance search with filters, batch metadata retrieval, and citation-graph recommendations.

This is a modified fork of afrise/academic-search-mcp-server. The server was rewritten on top of the official semanticscholar Python library and extended with batch and recommendation tools, bounded retry on rate limits, and clearer error handling. See Changes from upstream below.

Tools

Tool	What it does
`search_papers`	Relevance search with optional filters: `year`, `fields_of_study`, `min_citation_count`, `venue`, `open_access_pdf`.
`search_by_topic`	Same as `search_papers`, with a `year_start`/`year_end` range (kept for backward compatibility).
`fetch_paper_details`	Full metadata for a single paper by Semantic Scholar ID, DOI, or arXiv ID.
`get_papers_batch`	Details for up to 500 papers in one request — far cheaper than looping `fetch_paper_details` under the 1 req/sec limit.
`recommend_papers`	Citation-graph recommendations from seed paper IDs (`positive_paper_ids`, optional `negative_paper_ids`). Surfaces structurally similar work that keyword search misses.

Each tool returns a formatted text block per paper: ID, title, authors, year, DOI, venue, citation count, fields of study, open-access status, PDF URL, abstract, and TL;DR when available.

Related MCP server: semantic-scholar-mcp

Requirements

Python 3.10+
uv (recommended) — or plain pip
A Semantic Scholar API key is optional (see below)

Install

git clone https://github.com/ociupitu/academic-search-mcp.git
cd academic-search-mcp
uv sync          # creates .venv and installs dependencies from uv.lock

Prefer pip? pip install -e . inside a virtual environment works too.

API key (optional)

The server reads SEMANTIC_SCHOLAR_API_KEY from the environment, but it is optional:

Without a key — requests go through Semantic Scholar's shared anonymous pool. It works, but you are more likely to hit HTTP 429 rate limiting during busy periods.
With a free key — you get your own quota. Register at https://www.semanticscholar.org/product/api and set the variable (the .mcp.json example below wires it in).

Either way the server keeps requests sequential and does a short bounded retry on a 429, then returns a readable Error: string rather than hanging or silently returning "no results".

Use with Claude Code

Add the server to your client's MCP config (for Claude Code, a .mcp.json in your project root). Point --directory at wherever you cloned this repo, and use an absolute path:

{
  "mcpServers": {
    "academic-search": {
      "type": "stdio",
      "command": "uv",
      "args": ["run", "--directory", "/absolute/path/to/academic-search-mcp", "server.py"],
      "env": {
        "SEMANTIC_SCHOLAR_API_KEY": "YOUR_API_KEY_HERE"
      }
    }
  }
}

Leave the env block out entirely to run keyless. Restart your MCP client after editing the config.

Changes from upstream

Rewritten on the official semanticscholar library instead of hand-rolled httpx calls.
Added get_papers_batch (batch details) and recommend_papers (citation-graph recommendations).
Added search filters: fields_of_study, min_citation_count, venue, open_access_pdf, and a flexible year range.
Fail-fast client (retry=False) plus a bounded in-server retry on 429, so a throttle recovers in seconds or returns a clean error instead of blocking for minutes.
Dropped the Crossref path; Semantic Scholar is the single source.

License

AGPL-3.0, inherited from the upstream project. See LICENSE. If you redistribute or run a modified version as a network service, the AGPL's source-availability terms apply.

Available Tools

5 tools

fetch_paper_detailsA

Get detailed information about a single paper.

Args:
    paper_id: a Semantic Scholar paper ID, or a DOI, arXiv ID, etc.

ParametersJSON Schema

Name	Required	Description	Default
`paper_id`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description should disclose behavioral traits. It only states it 'gets details' but omits safety info (e.g., read-only assumption), error handling, or any limitations. The description is minimal for a tool with no annotations.

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?

The description is extremely concise: a single sentence plus an arg clarification. Every word adds value; no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one param and no output schema, the description adequately covers the input but lacks any mention of return format or additional behavior. It meets minimum viability but has clear gaps.

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?

The description adds valuable context to the single parameter paper_id, specifying it can be a Semantic Scholar paper ID, DOI, arXiv ID, etc., which is not present in the input schema (0% schema coverage). This significantly aids correct invocation.

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 clearly states 'Get detailed information about a single paper' with a specific verb and resource, and implicitly distinguishes from sibling tools like get_papers_batch (multiple papers) and search procedures.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies use for fetching details of one paper but provides no explicit guidance on when to use this tool versus alternatives like get_papers_batch, search_papers, or recommend_papers. No when-not-to-use information.

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

get_papers_batchA

Fetch details for many papers in ONE request (up to 500).

Far more efficient than calling fetch_paper_details in a loop: a single
request returns all of them, which matters under the 1 request/second limit.

Args:
    paper_ids: Semantic Scholar paper IDs (or DOIs, arXiv IDs, etc.).

ParametersJSON Schema

Name	Required	Description	Default
`paper_ids`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided. Description mentions rate limit efficiency but does not disclose side effects or return behavior. Adequate for a read-only batch fetch, but could be more explicit about non-destructive nature.

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?

Three well-structured sentences plus an Args line. Front-loaded with purpose, efficient in word count, no fluff.

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?

Given one parameter and no output schema, the description covers the main usage, benefit, and parameter format. Could mention maximum batch size in the description, but it's already stated. Appropriate for its simplicity.

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 has 0% coverage, but description adds that paper_ids can be Semantic Scholar paper IDs, DOIs, arXiv IDs, etc. This significantly helps the agent understand acceptable inputs beyond the schema's plain array of strings.

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 clearly states it fetches details for many papers in one request, with a specific batch size limit (up to 500). It distinguishes from the sibling fetch_paper_details by emphasizing the batch aspect.

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?

Explicitly states it is more efficient than calling fetch_paper_details in a loop, especially under rate limits. Does not specify when not to use it, but context is clear.

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

recommend_papersA

Recommend papers similar to seed papers, via the citation graph.

Use this as a second discovery channel: keyword search finds papers that
share vocabulary, while recommendations surface structurally similar papers
in OTHER empirical domains that keyword search misses. Seed it with the
paper IDs of the best on-target hits from a search.

Args:
    positive_paper_ids: IDs the results should resemble (at least one required).
    negative_paper_ids: IDs to steer recommendations away from (optional).
    limit: maximum number of recommendations (default 10, capped at 100).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`negative_paper_ids`	No
`positive_paper_ids`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It explains it uses citation graph, specifies constraints like default limit and cap at 100. However, it does not explicitly state it is a read-only operation, though it is implied. Minor gap.

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?

Highly concise: three sentences total (purpose, usage, args), no unnecessary words. Front-loaded with key information. Every sentence earns 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?

For a 3-parameter tool with no output schema, it covers purpose, usage, and all parameters well. Missing description of return format (e.g., list of paper objects) but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description's Args section thoroughly explains each parameter: positive_paper_ids (required), negative_paper_ids (optional), and limit (default 10, capped at 100). This adds significant meaning beyond the schema.

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 clearly states it recommends papers similar to seed papers via the citation graph. It distinguishes itself from sibling tools by contrasting with keyword search, making its unique purpose evident.

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?

Explicitly advises using it as a second discovery channel after keyword search, and explains how to seed it with relevant paper IDs from search results. This provides clear when-to-use and how-to-use guidance.

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

search_by_topicA

Search papers by topic with an optional year range and filters.

Thin wrapper over search_papers that maps a year_start/year_end pair to the
API's year-range string. See search_papers for the filter semantics.

Args:
    topic: the search query string.
    year_start: start year (inclusive).
    year_end: end year (inclusive).
    limit: maximum number of results (default 10, capped at 100).
    fields_of_study: restrict to fields, e.g. ["Economics", "Business"].
    min_citation_count: drop papers with fewer citations than this.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`topic`	Yes
`year_end`	No
`year_start`	No
`fields_of_study`	No
`min_citation_count`	No

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that it maps year_start/year_end to a year-range string and mentions defaults and a cap for the limit parameter. However, it does not describe the return format, pagination, or whether the operation is read-only. The disclosure is adequate but not comprehensive.

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?

The description is concise and well-structured. The first sentence states the purpose, followed by a clarifying line about the wrapper, and then a clean Args list. Every sentence adds value without verbosity.

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?

Given the complexity (6 parameters, 1 required, no output schema), the description covers parameters thoroughly and references search_papers for filter details. It lacks an explanation of the return format, but for a search tool this is acceptable. The description is nearly complete for its purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates well. It explains every parameter: topic as the search query, year_start/year_end as inclusive range, limit with default and cap, fields_of_study as a list of fields, and min_citation_count as a threshold. This adds significant meaning beyond the schema.

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 clearly states the tool searches papers by topic with optional year range and filters. It explicitly distinguishes itself as a thin wrapper over search_papers, specifying the mapping of year_start/year_end to the API's year-range string. The verb 'search' and resource 'papers' are clearly identified.

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 provides clear context: it is a thin wrapper over search_papers and directs users to search_papers for filter semantics. This implies when to use this tool (when searching by topic with year range) versus search_papers (when needing more complex filters). However, it does not explicitly state when not to use it or list alternative sibling tools.

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

search_papersB

Relevance search for papers on Semantic Scholar.

Args:
    query: the search query string.
    limit: maximum number of results (default 10, capped at 100).
    year: a single year or range, e.g. "2018", "2015-2022", "2016-", "-2015".
    fields_of_study: restrict to fields, e.g. ["Economics", "Business"].
    min_citation_count: drop papers with fewer citations than this.
    venue: restrict to venues, e.g. ["Marketing Science"].
    open_access_pdf: if True, only return papers that have an open-access PDF.

ParametersJSON Schema

Name	Required	Description	Default
`year`	No
`limit`	No
`query`	Yes
`venue`	No
`fields_of_study`	No
`open_access_pdf`	No
`min_citation_count`	No

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided. Description only describes parameters, not behavioral traits like rate limits, authentication, or side effects. It implies a read-only search but does not state it.

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?

Concise block of text with a summary line and parameter list. Could be more structured (e.g., bullet points) but no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers parameter semantics well, but lacks usage guidelines, output format description, and behavioral context. Adequate but with clear gaps.

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?

With 0% schema description coverage, the description compensates well by explaining each parameter's purpose and format, e.g., year range examples. However, default values for some parameters like 'year' are not explicitly stated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states 'Relevance search for papers on Semantic Scholar', which is a clear verb+resource. However, it does not differentiate from sibling tools like 'search_by_topic'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. Sibling tools like 'fetch_paper_details' and 'search_by_topic' are not referenced.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation4/5

Tools have distinct purposes: single/batch fetch, search, and recommendation. The two search tools (search_by_topic, search_papers) have overlapping functionality, but the descriptions clarify that search_by_topic is a convenience wrapper with year range parameters, reducing ambiguity.

Naming Consistency5/5

All tools follow a verb_noun pattern in snake_case (e.g., fetch_paper_details, get_papers_batch, recommend_papers, search_papers). The slight deviation of search_by_topic (verb_preposition_noun) is minor and still predictable.

Tool Count5/5

Five tools cover the core operations of an academic search server: single/batch retrieval, two search variants, and recommendation. The scope is well-defined, and no tool feels redundant or missing for the stated purpose.

Completeness4/5

The tool set covers essential tasks: search, retrieve, and recommend. However, it lacks tools for fetching citations, references, or author details, which are common in academic search. This is a minor gap for a complete workflow.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Papertext
app.papertext.app
Academic literature search, retrieval, and private library management on top of OpenAlex.
Search Research & Data Knowledge & Memory
2
Academic Research Intelligence MCP A
io.github.FoundryNet
Academic paper search, scientific literature, citation analysis, arXiv & semantic related-work.
Research & Data Search
2
nobleblocks-mcp
com.nobleblocks
Search 340M+ academic papers — citation graphs, semantic similarity, and AI literature reviews.
Research & Data Search AI & Machine Learning
21
academic-research-mcp
com.themineworks
Scholarly search: OpenAlex, Crossref, arXiv, OpenCitations and PubMed in one endpoint.
Search Research & Data Open Data
11

Related MCP Servers

Semantic Scholar MCP Server
Search Research & Data Documentation Access
fegizii
A
license
A
quality
D
maintenance
Enables access to the Semantic Scholar Academic Graph API for searching and retrieving detailed information about academic papers, authors, citations, and references.
Updated a year ago (2025-07-02 16:13 UTC)
11
3
MIT
semantic-scholar-mcp
Research & Data Search
benhaotang
A
license
Not graded
quality
D
maintenance
Enables searching and retrieving academic paper metadata from Semantic Scholar, including paper details, citations, and author information.
Updated a year ago (2025-04-05 00:20 UTC)
21
MIT
Semantic Scholar MCP Server
Research & Data Search Open Data
HenryKautz
F
license
A
quality
D
maintenance
Enables searching and retrieving academic papers, authors, citations, and recommendations from Semantic Scholar via MCP.
Updated 7 months ago (2026-02-15 22:58 UTC)
9
semantic-scholar-mcp-server
Research & Data Search
SMABoundless
A
license
A
quality
C
maintenance
Provides tools to search, retrieve, and explore over 200M academic papers, authors, citations, and full-text snippets via the Semantic Scholar API.
Updated 2 months ago (2026-07-04 21:29 UTC)
16
81
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ociupitu/academic-search-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server