The Academic Paper Search MCP Server enables searching and retrieving academic paper information from multiple sources.
Key capabilities:
Search for academic papers using free-text queries with optional result limits
Search for papers by specific topic (up to 300 characters) with optional date range filtering
Fetch detailed information for specific papers using their identifiers (DOI or Semantic Scholar ID)
Access comprehensive metadata including title, authors, year, DOI, venue, open access status, PDF URLs, abstracts, and TL;DR summaries
Retrieve paper information from different sources (Semantic Scholar or Crossref)
Supports retrieving paper details using DOI identifiers through the fetch_paper_details function
Potentially compatible with OpenAI's API for models that support tool/function calling capabilities
Allows searching and retrieving academic paper information from the Semantic Scholar API
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., "@Academic Paper Search MCP Server search for recent papers about large language models in education"
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.
A Model Context Protocol (MCP) server that enables searching and retrieving academic paper information from multiple sources.
The server provides LLMs with:
Real-time academic paper search functionality
Access to paper metadata and abstracts
Ability to retrieve full-text content when available
Structured data responses following the MCP specification
While primarily designed for integration with Anthropic's Claude Desktop client, the MCP specification allows for potential compatibility with other AI models and clients that support tool/function calling capabilities (e.g. OpenAI's API).
Note: This software is under active development. Features and functionality are subject to change.
This server exposes the following tools:
search_papers: Search for academic papers across multiple sources
Parameters:
query (str): Search query text
limit (int, optional): Maximum number of results to return (default: 10)
Returns: Formatted string containing paper details
fetch_paper_details: Retrieve detailed information for a specific paper
Parameters:
paper_id (str): Paper identifier (DOI or Semantic Scholar ID)
source (str, optional): Data source ("crossref" or "semantic_scholar", default: "crossref")
Returns: Formatted string with comprehensive paper metadata including:
Title, authors, year, DOI
Venue, open access status, PDF URL (Semantic Scholar only)
Abstract and TL;DR summary (when available)
search_by_topic: Search for papers by topic with optional date range filter
Parameters:
topic (str): Search query text (limited to 300 characters)
year_start (int, optional): Start year for date range
year_end (int, optional): End year for date range
limit (int, optional): Maximum number of results to return (default: 10)
Returns: Formatted string containing search results including:
Paper titles, authors, and years
Abstracts and TL;DR summaries when available
Venue and open access information
Related MCP server: Research MCP
To install Academic Paper Search Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @afrise/academic-search-mcp-server --client claudenote this method is largely untested, as their server seems to be having trouble. you can follow the standalone instructions until smithery gets fixed.
Install dependencies:
uv add "mcp[cli]" httpxSet up required API keys in your environment or .env file:
# These are not actually implemented
SEMANTIC_SCHOLAR_API_KEY=your_key_here
CROSSREF_API_KEY=your_key_here # Optional but recommendedRun the server:
uv run server.pyAdd the server to your Claude Desktop configuration (claude_desktop_config.json):
{
"mcpServers": {
"academic-search": {
"command": "uv",
"args": ["run ", "/path/to/server/server.py"],
"env": {
"SEMANTIC_SCHOLAR_API_KEY": "your_key_here",
"CROSSREF_API_KEY": "your_key_here"
}
}
}
}Restart Claude Desktop
This server is built using:
Python MCP SDK
FastMCP for simplified server implementation
httpx for API requests
Semantic Scholar API
Crossref API
This project is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0). This license ensures that:
You can freely use, modify, and distribute this software
Any modifications must be open-sourced under the same license
Anyone providing network services using this software must make the source code available
Commercial use is allowed, but the software and any derivatives must remain free and open source
See the LICENSE file for the full license text.
Contributions are welcome! Here's how you can help:
Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
Please note:
Follow the existing code style and conventions
Add tests for any new functionality
Update documentation as needed
Ensure your changes respect the AGPL-3.0 license terms
By contributing to this project, you agree that your contributions will be licensed under the AGPL-3.0 license.
Get detailed information about a specific paper.
Args:
paper_id: Paper identifier (DOI for Crossref, paper ID for Semantic Scholar)
source: Source database ("semantic_scholar" or "crossref")
| Name | Required | Description | Default |
|---|---|---|---|
| paper_id | Yes | ||
| source | No | semantic_scholar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] detailed information,' which implies a read-only operation, but it doesn't disclose any behavioral traits such as authentication needs, rate limits, error handling, or what 'detailed information' includes. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
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 appropriately sized and front-loaded, starting with a clear purpose statement followed by a concise 'Args' section that lists parameters with brief explanations. Every sentence earns its place by providing essential information without unnecessary details, making it efficient and easy to parse.
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 tool's moderate complexity (2 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and parameters well, but it lacks information on behavioral aspects like what 'detailed information' entails, potential errors, or usage constraints. Without an output schema, the description should ideally hint at the return structure, but it doesn't, leaving some context gaps.
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 description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'paper_id' is a 'Paper identifier (DOI for Crossref, paper ID for Semantic Scholar)' and 'source' is a 'Source database' with options 'semantic_scholar' or 'crossref'. This clarifies the purpose and format of the parameters, compensating well for the lack of schema 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 clearly states the tool's purpose: 'Get detailed information about a specific paper.' This specifies the verb ('Get') and resource ('paper'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'search_by_topic' or 'search_papers', which likely return lists rather than details for a specific paper.
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 implies usage by specifying that it's for a 'specific paper' and lists the required 'paper_id' and optional 'source' parameters. This suggests it should be used when you have a known paper identifier, but it doesn't explicitly state when to use this tool versus the sibling search tools or provide any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for papers by topic with optional date range.
Note: Query length is limited to 300 characters. Longer queries will be automatically truncated.
Args:
topic (str): Search query (max 300 chars)
year_start (int, optional): Start year for date range
year_end (int, optional): End year for date range
limit (int, optional): Maximum number of results to return (default 10)
Returns:
str: Formatted search results or error message
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | Yes | ||
| year_end | No | ||
| year_start | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: the query length limit (300 characters with truncation) and the return type (formatted search results or error message). However, it lacks details on permissions, rate limits, error conditions beyond truncation, or pagination behavior, which are important for a search tool.
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 appropriately sized and well-structured. It starts with a clear purpose statement, adds a critical behavioral note (query length limit), and then lists parameters and returns in a formatted way. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.
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 tool's moderate complexity (4 parameters, no output schema, no annotations), the description is partially complete. It covers parameters and basic behavior but lacks output details (e.g., result format beyond 'formatted'), error handling specifics, and differentiation from siblings. For a search tool, this leaves gaps in guiding the agent effectively.
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 description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: 'topic' as the search query with a character limit, 'year_start' and 'year_end' for date range, and 'limit' for maximum results with a default. This compensates well for the schema's lack of descriptions, though it could note that year parameters are optional integers.
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 clearly states the tool's purpose: 'Search for papers by topic with optional date range.' It specifies the verb ('search'), resource ('papers'), and scope ('by topic with optional date range'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_papers' or 'fetch_paper_details,' which would be needed for a perfect score.
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 provides no guidance on when to use this tool versus alternatives like 'search_papers' or 'fetch_paper_details.' It mentions optional parameters like date range and limit, but doesn't explain scenarios where this tool is preferred over siblings or any prerequisites for usage. This leaves the agent without context for 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 papers across multiple sources.
args:
query: the search query
limit: the maximum number of results to return (default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions searching 'across multiple sources' but does not cover critical aspects such as authentication needs, rate limits, pagination, or what the response format looks like. This leaves significant gaps in understanding the tool's behavior.
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 brief and front-loaded with the main purpose, but the 'args' section is somewhat redundant as it repeats parameter names without adding new insights. It could be more structured to avoid duplication and enhance clarity.
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 complexity of a search tool with no annotations and no output schema, the description is incomplete. It lacks details on result format, error handling, source specifics, and behavioral traits, making it inadequate for full contextual understanding.
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 description adds meaningful context for both parameters: 'query' is explained as 'the search query,' and 'limit' as 'the maximum number of results to return (default 10).' Since schema description coverage is 0%, this compensates well by clarifying parameter purposes beyond the bare schema.
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 the tool 'Search for papers across multiple sources,' which provides a clear verb ('Search') and resource ('papers'). However, it does not differentiate from sibling tools like 'search_by_topic' or specify what 'multiple sources' entails, making it somewhat vague in distinguishing its unique 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?
No guidance is provided on when to use this tool versus alternatives like 'search_by_topic' or 'fetch_paper_details.' The description lacks context on scenarios, prerequisites, or exclusions, leaving usage decisions unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools 'search_by_topic' and 'search_papers' have significant overlap in purpose—both search for papers, with only minor differences in parameters. This creates ambiguity, as an agent might struggle to choose between them. The 'fetch_paper_details' tool is distinct, but the two search tools are not clearly differentiated.
The naming is mixed: 'fetch_paper_details' uses a verb_noun pattern, while 'search_by_topic' and 'search_papers' use verb_preposition_noun and verb_noun styles, respectively. This inconsistency makes the set less predictable, though the names are still readable and descriptive.
With only 3 tools, the server feels thin for an academic paper search domain. It lacks essential operations like filtering by author, journal, or citation count, and there's no update or delete functionality, which limits its utility for comprehensive paper management.
The tool surface is incomplete for academic paper search. It covers basic fetch and search operations but misses key features such as author-based searches, citation tracking, paper categorization, or integration with reference managers. This will likely cause agent failures in complex workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search 340M+ academic papers — citation graphs, semantic similarity, and AI literature reviews.
Find academic papers across major sources like arXiv, PubMed, bioRxiv, and more. Download PDFs whe…
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Academic paper search, scientific literature, citation analysis, arXiv & semantic related-work.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/afrise/academic-search-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
