scholar-search-mcp

当 AI 助手学会「读论文」：Scholar Search MCP 如何改变学术研究

凌晨两点，你正在为明天的组会准备材料，需要快速了解某个研究方向近三年的进展。传统的做法是打开 Semantic Scholar、输入关键词、一个个点开论文、复制摘要——重复、机械、效率低下。而如果你让 Claude 或 Cursor 中的 AI 助手直接帮你完成这一切呢？

Scholar Search MCP 正是为此而生。它是一个基于 Model Context Protocol（MCP）的学术论文搜索服务器，将 Semantic Scholar 和 arXiv 两大论文数据库整合为一个统一工具，让 AI 助手（如 Claude Code、Cursor）能够直接帮你搜索论文、查看引用关系、下载 LaTeX 源码，甚至构建作者关系图谱。它不是又一个需要你手动操作的网站，而是一个可以被 AI 程序调用的「学术研究 API 大礼包」。## 项目背景与核心价值

为什么需要专门的论文搜索 MCP？

当前主流的论文数据库（如 Semantic Scholar、arXiv、Google Scholar）各有优劣：Semantic Scholar 提供丰富的元数据（引用数、高影响力论文标记、作者 h-index），但不支持直接下载源码；arXiv 有海量预印本和 LaTeX 源码，但搜索体验较为基础。更重要的是，这些工具都是为人类设计的——AI 助手无法直接调用它们的网页界面。

Scholar Search MCP 解决了这个问题。它将两个数据源统一封装为 9 个标准化 MCP 工具函数，AI 助手只需调用工具名称即可完成复杂的学术研究任务，无需理解底层 API 的细节。

典型使用场景

一个具体的例子：当你需要写一篇综述论文时，可以让 AI 助手依次执行：

1. search_papers 搜索关键词，获取相关论文列表（Semantic Scholar + arXiv 并行搜索、自动去重）
2. get_paper_citations 获取某篇关键论文的引用列表
3. get_author_papers 查看特定作者的所有论文
4. download_arxiv_source 下载 arXiv 论文的 LaTeX 源码，直接分析其方法实现

整个过程 AI 助手自动完成，你只需描述研究目标。这将文献调研的时间从「小时级」压缩到「分钟级」。## 核心功能详解

1. 统一并行搜索（search_papers）

这是最核心的工具函数。当你输入一个查询时，search_papers 会同时向 Semantic Scholar 和 arXiv 发请求，两个数据源的搜索结果按标题归一化去重后合并返回。这意味着你无需在多个平台重复搜索，一条查询搞定两个数据库。

去重逻辑基于标题的归一化处理（大小写不敏感、空白符压缩），保证了即使同一篇论文在两个平台有细微标题差异也不会被重复列出。合并时优先保留 Semantic Scholar 的结果（因为其元数据更丰富，包含引用数、高影响力标记等）。

2. 论文详情与引用图（get_paper_details / citations / references）

获取单篇论文的详细信息，包括标题、摘要、作者列表、年份、发表venue、引用数、参考文献数、高影响力引用数等。特别实用的是 get_paper_citations 和 get_paper_references——前者找出「哪些论文引用了这篇」，后者找出「这篇引用了哪些」。两者结合就能构建出一篇论文的完整引用图谱，对于追踪研究脉络极为高效。

3. 作者信息与论文列表（get_author_info / get_author_papers）

通过作者 ID 查询其个人主页、所属机构、h-index、论文总数等字段，还能批量获取该作者的所有论文列表。这在追踪某个研究团队的工作时特别有用——比如你想了解斯坦福 NLP 实验室近期在做什么，只需找到负责人的作者 ID即可。

4. 相似论文推荐（get_paper_recommendations）

给定一篇论文，返回语义相似的高相关论文推荐。这是基于 Semantic Scholar 内部的协同过滤/语义相似度算法实现的，类似于「你可能也喜欢」的功能，对于发现新工作、扩大研究视野很有帮助。

5. 批量获取与 arXiv 源码下载（batch_get_papers / download_arxiv_source）

• batch_get_papers：一次最多获取 500 篇论文的详情，适合大规模文献调研
• download_arxiv_source：下载 arXiv 论文的 LaTeX 源码压缩包（tar.gz），自动解压到指定目录，并做了路径遍历安全防护——这是代码安全方面值得称赞的细节

6. 灵活的配置与缓存

• 环境变量 SEMANTIC_SCHOLAR_API_KEY：可选，提供后可突破公共速率限制（无 key 每秒 1 请求，有 key 每秒 10 请求）
• SCHOLAR_SEARCH_ENABLE_SEMANTIC_SCHOLAR / SCHOLAR_SEARCH_ENABLE_ARXIV：分别开关两个数据源
• SCHOLAR_SEARCH_CACHE_TTL_SECONDS：缓存有效期，默认 24 小时，避免重复查询浪费 API 配额
• SCHOLAR_ARXIV_SOURCE_DIR：arXiv 源码下载目录## 技术架构与代码分析

整体架构

Scholar Search MCP 采用异步 MCP Server架构，核心依赖极简：mcp（MCP 协议实现）、httpx（异步 HTTP 客户端）、diskcache（本地缓存）。整个项目没有引入重型 ML 依赖，是真正轻量的「AI 工具的工具」。

核心代码约 800 行（server.py），结构清晰：

scholar_search_mcp/
├── __init__.py      # 版本号 + 导出 main
├── __main__.py      # 入口点
└── server.py        # 全部逻辑（约800行）

三大核心客户端

1. SemanticScholarClient：封装 Semantic Scholar Graph API，支持论文搜索、详情、引用、参考文献、作者信息、推荐、批量获取。内置指数退避重试（最多 6 次 429），保证稳定性。
2. ArxivClient：封装 arXiv Atom Feed API，解析 XML 返回与 Semantic Scholar 兼容的数据格式。错误条目（arXiv API 返回的 error entry）会被静默跳过。
3. 合并层（_merge_parallel_search_results）：两路并行的搜索结果通过标题归一化进行去重合并，保留两边的元数据优势。

安全防护：路径遍历攻击防御

download_arxiv_source 函数中使用 _safe_extract_tar_gz 提取压缩包时，代码显式检查了 dest_path.relative_to(dest)——如果提取后的文件路径逃脱了目标目录（通过 ../../etc/passwd 等方式），Python 会抛出 ValueError，整个操作中止。这在 Python 3.11.4+ 或 3.12+ 还额外启用了 filter="data" 机制，进一步减少解压风险。这是代码中非常值得关注的安全实践。

数据兼容性设计

作者做了大量工作确保 Semantic Scholar 和 arXiv 返回的数据格式兼容：

• 两个数据源的论文 dict 使用相同的 key（paperId、title、abstract、authors、year 等）
• 缺失字段用 None 填充，合并时按优先级填充
• source 和 sources 字段记录数据来源，保证可溯源

代码质量评估

维度	评价
类型注解	完整，所有函数签名均有类型标注
错误处理	异步异常捕获、HTTP 状态码处理、XML 解析容错
缓存策略	diskcache 持久化缓存，避免重复 API 调用
测试覆盖	未提供测试文件，但核心逻辑有注释说明预期行为
文档质量	README 结构清晰，安装步骤详细，环境变量说明完整

代码质量评分：85/100。主要扣分项为缺少自动化测试和部分边缘情况的单元验证，但整体代码可读性极佳，异步并发设计合理，注释充分。## 部署与使用

安装方式

项目通过 pyproject.toml 打包，支持两种安装方式：

# 方式1：pip 安装（推荐）
pip install scholar-search-mcp

# 方式2：源码安装
git clone https://github.com/Silung/scholar-search-mcp
cd scholar-search-mcp
pip install -e .

安装后配置 Claude Desktop 或 Cursor 的 MCP 设置，填入服务器命令即可。arXiv 搜索无需 API key，完全免费使用；Semantic Scholar 搜索无需 key 也能用（速率受限），有 key 体验更佳。

环境变量配置

变量	默认值	说明
SEMANTIC_SCHOLAR_API_KEY	空	突破速率限制（可选）
SCHOLAR_SEARCH_ENABLE_SEMANTIC_SCHOLAR	true	开关 Semantic Scholar
SCHOLAR_SEARCH_ENABLE_ARXIV	true	开关 arXiv
SCHOLAR_SEARCH_CACHE_TTL_SECONDS	86400	缓存有效期（秒）
SCHOLAR_SEARCH_CACHE_DIR	系统临时目录	缓存存储路径
SCHOLAR_ARXIV_SOURCE_DIR	临时目录	arXiv 源码下载目录

硬件与依赖要求

• Python：3.10~3.12
• 硬件：无 GPU 要求，普通笔记本即可运行
• 磁盘：约 100MB（含缓存）
• 网络：需要访问 api.semanticscholar.org 和 export.arxiv.org## 局限与使用建议

当前局限

1. 无 Web UI：纯 CLI 工具，调试依赖 MCP Inspector 或 Claude Desktop 的日志，对新手不够直观
2. API 速率限制：无 Semantic Scholar key 时每秒仅 1 请求，大规模搜索可能需要等待
3. arXiv 源码非全量：并非所有 arXiv 论文都有提交的 LaTeX 源码，下载失败需降级到 PDF
4. 中文论文支持弱：Semantic Scholar 和 arXiv 均以英文论文为主，中文论文覆盖率低

使用建议

• 学术写作场景下，优先使用 search_papers 获取候选列表，再用 get_paper_citations 追踪高影响力工作
• 研究陌生领域时，用 get_paper_recommendations 发现核心论文，再逐层展开引用图
• 需要复现方法时，使用 download_arxiv_source 获取 LaTeX 源码，直接分析算法实现细节
• 配置 API key 突破速率限制，大幅提升批量调研效率## 行业意义与趋势

Scholar Search MCP 代表了 MCP 生态在垂直领域工具方向的典型实践。自 Anthropic 推出 MCP 协议以来，社区已陆续构建了文件系统、数据库、Git 版本控制等多种 MCP 服务器，而学术论文搜索是其中一个高频刚需的场景。

核心价值在于将人类的研究工作流转化为 AI 可编程的原子操作。过去 AI 助手无法访问实时学术数据，现在通过 MCP 的工具调用机制，AI 可以自主执行多步骤研究任务。这种「AI 驱动的研究自动化」正是 AI Agent 落地的关键一步。

从增长角度看，该项目 Star 数在 217 左右（持续增长中），属于 MCP 生态中较为活跃的工具类项目。随着 AI Agent 应用的普及，将会有更多类似的「垂直领域 MCP 服务器」出现，形成一个可组合的工具生态。

本分析基于 GitHub 仓库 v0.1.3 版本，代码分析基于 server.py（约 800 行 Python 代码）。 项目作者头像：

图注：Scholar Search MCP 通过 MCP 协议将两个主流学术数据库（Semantic Scholar + arXiv）封装为 AI 助手可调用的标准化工具集，实现从论文检索到源码获取的完整研究工作流自动化。