A
licenseA
qualityD
maintenanceMCP server enabling AI agents to search and retrieve scientific papers, citations, and author profiles from Crossref, OpenAlex, and Semantic Scholar with no API keys required.
5
3
MIT
papers-mcp
by surendranb
This server provides scientific grounding by enabling search, discovery, and retrieval of research papers across multiple scholarly sources (arXiv, OpenAlex, Crossref, PubMed, and Semantic Scholar). Key capabilities:
Search papers (
search_papers): Aggregate search with filters for year range, source, open-access only, sorting, and result limit. Returns a unified schema including title, authors, abstract, DOI, citation count, open-access status, and retraction flag.Resolve paper details (
get_paper): Retrieve full metadata, references (even for paywalled journals), and citations by DOI, arXiv ID, PMID, OpenAlex ID, or S2 ID. Optional liveness and retraction verification.List sources (
list_sources): View available scholarly sources, their coverage, requirements, and rate limits.Methodology guide (
get_research_method): Access recommended research methodology, including tool tiers, interpretation rules, source quirks, and verification steps.Graceful degradation: Failing or rate-limited sources are skipped and reported.
Optional Semantic Scholar API key lifts rate limits; anonymous telemetry (opt-out) collects usage events, never storing queries or content.
Retrieve metadata, references, and citations from ACM publications even when the full text is paywalled.
Aggregated search for open-access preprints across computer science, physics, mathematics, and more.
Retrieve metadata, references, and citations from Elsevier publications even when the full text is paywalled.
Retrieve metadata, references, and citations from IEEE publications even when the full text is paywalled.
Search biomedical citations and access free full-text from PubMed/PMC.
Search a large corpus of scholarly papers with citation graph and TLDRs.
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., "@papers-mcpsearch for papers about CRISPR gene editing"
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.
Scientific Research Papers MCP Server 📄
Scientific literature grounding MCP server for AI agents: unified search across 250M+ scholarly papers on arXiv, PubMed, OpenAlex, CrossRef, and Semantic Scholar.
🌐 Live Documentation & Web Portal: https://papers.builditwithai.xyz
⚡ Quickstart
# 1-Line Universal Installer (Auto-configures Claude Desktop, Cursor, Claude Code, Antigravity, VS Code, Zed, Windsurf)
curl -fsSL "https://papers.builditwithai.xyz/install" | bash
# Or run directly via your preferred runtime:
uvx find-research-papers-mcp
npx -y find-research-papers-mcpRelated MCP server: Academic Paper MCP HTTP/SSE Server
🤖 Client Setup
A. Claude Code (CLI)
claude mcp add papers -- uvx find-research-papers-mcpB. Cursor & Google Antigravity (mcp.json)
{
"mcpServers": {
"papers": {
"command": "uvx",
"args": ["find-research-papers-mcp"]
}
}
}C. Claude Desktop (claude_desktop_config.json)
{
"mcpServers": {
"papers": {
"command": "uvx",
"args": ["find-research-papers-mcp"]
}
}
}D. VS Code (Cline / Roo Code / Continue)
{
"mcpServers": {
"papers": {
"command": "npx",
"args": ["-y", "find-research-papers-mcp"]
}
}
}🛠️ Tools & Capabilities
Tool Name | Parameters | Description | Return Type |
|
| Unified multi-index search across arXiv, PubMed, OpenAlex, CrossRef, Semantic Scholar. |
|
|
| Retrieves paper metadata, abstract, authors, publication date, and open-access PDF link. |
|
|
| Fetches complete bibliography and referenced papers via CrossRef. |
|
|
| Fetches citing papers and citation graph via OpenAlex. |
|
|
| HEAD-checks landing page accessibility and cross-checks retraction databases. |
|
| (none) | Returns live status and latency metrics for all 5 scholarly indexes. |
|
|
| Dynamically loads research methodology skills from GitHub. |
|
| (none) | Lists all available scientific research skills. |
|
🔒 Telemetry & Privacy
This package collects anonymous, non-PII diagnostic telemetry (command executions, latency, error codes) to improve tool reliability. No research queries, paper results, personal data, source code, or environment variables are ever collected or stored.
You can opt out anytime by setting either of the following environment variables:
export DO_NOT_TRACK=1
# or
export MCP_TELEMETRY_OPT_OUT=1📄 License
MIT License. See LICENSE for details.
Available Tools
3 toolsget_paperGet paper details, references and citationsA
Resolve one paper by identifier and return its metadata plus references (papers it cites) and citations (papers citing it) — works even for paywalled papers
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id_type | No | auto | |
| identifier | Yes | ||
| include_citations | No | ||
| include_references | No |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions working for paywalled papers (useful) and the return contents, but does not disclose error behavior, rate limits, or authentication needs. It implies a read-only operation but does not state side effects.
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 a single well-structured sentence that is front-loaded with the core purpose and includes a useful qualifier (paywalled). No wasted words.
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?
While the description clarifies the main return values and a notable capability, the tool has 4 parameters with no schema descriptions and no output schema. Missing details about id_type, how citations/references are formatted, and error handling make the description incomplete for fully understanding the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'references' and 'citations' but does not map them to the include_references and include_citations parameters, nor does it explain the id_type parameter or identifier formats. The schema has titles and defaults, but the description adds little meaning beyond hinting at the main identifier.
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 verb 'Resolve' and the resource 'one paper by identifier', listing the return contents (metadata, references, citations). This distinguishes it from siblings like search_papers (which discovers papers) and list_sources (which lists sources).
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 implies usage when you have a specific paper identifier and need its details and citation network. It highlights that it works for paywalled papers, which is a practical consideration, but it does not explicitly contrast with search_papers or list_sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sourcesList paper sourcesA
List every scholarly source the server can search, with coverage, key requirements, and rate limits
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.5/5.0
Behavior4/5
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 explicitly mentions that the output includes coverage, key requirements, and rate limits, which gives the agent useful context about limitations and prerequisites. It does not contradict any annotations since none exist.
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 a single, front-loaded sentence that states the action and key output details. Every word contributes value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with an output schema present, the description is complete. It clearly indicates what the tool returns (sources with coverage, requirements, and rate limits) and differentiates from sibling tools. No additional context is necessary for a task of this 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?
The tool has zero parameters, so the schema is trivially complete. Per the rubric, zero params warrant a baseline score of 4. The description adds no parameter-specific meaning, but none is needed.
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's purpose with a specific verb ('List'), resource ('scholarly sources'), and scope ('the server can search'). It also specifies the included details (coverage, key requirements, rate limits), which distinguishes it from sibling tools like search_papers and get_paper.
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 for when to use the tool: to discover the scholarly sources available for searching. It implies usage before searching or to understand source capabilities. It doesn't explicitly name alternatives or exclusions, but the listing nature is self-evident and distinguishable from the search and get siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_papersSearch research papersC
Search scholarly literature across multiple sources (arXiv, OpenAlex, Crossref, Semantic Scholar, PubMed)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | relevance | |
| limit | No | ||
| query | Yes | ||
| sources | No | ||
| year_to | No | ||
| year_from | No | ||
| open_access_only | No |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden, but it only states that the tool searches across multiple sources. It does not reveal rate limits, authentication needs, result aggregation behavior, or whether it is read-only.
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 description is a single, efficient sentence with no wasted words. It lists specific sources, making it moderately informative while staying concise, though it could have spent more space on parameter semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is insufficient. It provides no information about return format, query syntax, filtering behavior, or how to effectively use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters beyond the vague hint of 'multiple sources.' No details are given for sort, limit, year_from, year_to, open_access_only, or how the sources parameter works.
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 uses a specific verb ('Search') and resource ('scholarly literature') and names five concrete sources (arXiv, OpenAlex, Crossref, Semantic Scholar, PubMed), clearly distinguishing this search tool from sibling tools like get_paper and list_sources.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, scenarios, or prerequisites, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
v0.1.0- First observed
get_paper - First observed
list_sources - First observed
search_papers
TDQS
A3.9/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: search_papers discovers papers, get_paper retrieves a specific paper's details by identifier, and list_sources provides source configuration. There is no overlap or ambiguity between them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using lowercase snake_case: search_papers, get_paper, list_sources. The pattern is uniform and predictable.
Tool Count5/5
Three tools is exactly appropriate for a focused scholarly search server. It covers the core operations (search, retrieval) plus a useful supporting tool (list_sources) without unnecessary bloat.
Completeness5/5
The tool set provides a complete lifecycle for scholarly paper discovery: search across sources, retrieve detailed metadata with references/citations, and discover what sources are available. There are no obvious missing operations for the stated purpose.
Maintenance
ActivityMaintained
ResponsivenessResponsive
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Scholarly search: OpenAlex, Crossref, arXiv, OpenCitations and PubMed in one endpoint.
Read-only MCP over an agentic SLR workspace with per-claim citation verification
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA MCP server for academic literature retrieval, aggregating multiple data sources like arXiv, Crossref, OpenAlex, PubMed, and Semantic Scholar to provide search, details, citations, trends, and recommendations.4MIT
- AlicenseAqualityAmaintenanceA FastMCP server for the scholarly citation landscape that enables LLMs to search, cross-reference, and retrieve prior art across papers, patents, books, and standards via multiple APIs.222MIT
- AlicenseAqualityCmaintenanceUnified MCP server for scientific literature search and extraction, integrating databases like Scopus, OpenAlex, Semantic Scholar, and Unpaywall to enable AI agents to discover papers, track citations, and analyze content.27MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/surendranb/find-research-papers-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server