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
Scientific Research Papers MCP Server 📄
面向 AI 代理的科学文献锚定 MCP 服务器：统一搜索 arXiv、PubMed、OpenAlex、CrossRef 和 Semantic Scholar 上的 2.5 亿+ 篇学术论文。
🌐 在线文档与 Web 门户：https://papers.builditwithai.xyz
⚡ 快速入门
# 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
🤖 客户端设置
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"]
}
}
}🛠️ 工具与能力
工具名称 | 参数 | 描述 | 返回类型 |
|
| 跨 arXiv、PubMed、OpenAlex、CrossRef、Semantic Scholar 的统一多索引搜索。 |
|
|
| 检索论文元数据、摘要、作者、发表日期和开放获取 PDF 链接。 |
|
|
| 通过 CrossRef 获取完整参考文献列表和引用论文。 |
|
|
| 通过 OpenAlex 获取引用论文和引文图谱。 |
|
|
| 对落地页可访问性执行 HEAD 检查，并交叉核对撤稿数据库。 |
|
| （无） | 返回全部 5 个学术索引的实时状态和延迟指标。 |
|
|
| 从 GitHub 动态加载研究方法论技能。 |
|
| （无） | 列出所有可用的科学研究技能。 |
|
🔒 遥测与隐私
本包收集匿名的、非 PII 的诊断遥测数据（命令执行、延迟、错误代码），以提高工具可靠性。绝不会收集或存储任何研究查询、论文结果、个人数据、源代码或环境变量。
您可以随时通过设置以下任一环境变量来选择退出：
export DO_NOT_TRACK=1
# or
export MCP_TELEMETRY_OPT_OUT=1📄 许可证
MIT 许可证。详情请参阅 LICENSE。
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.
3 tool updates
v0.1.0- First observed
get_paper - First observed
list_sources - First observed
search_papers
TDQS
A3.9/5.0
Scored across 3 tools
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
ActivityActive
ResponsivenessResponsive
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.21114 PyPI2MIT
- 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