Which integrations are available for this server?

Automatically retrieves full abstracts from arXiv API for papers with arXiv IDs when getting paper details. Allows searching Google Scholar for academic papers with filters like year, deduplication, and retry logic.

How do I use scholar-search?

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., "@scholar-search Search for recent papers on transfer learning published since 2020" 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.

scholar-search

by MuliMuri

Overview Schema Related Servers Score Discussions

Python

Remote

Scholar Search MCP

基于 Python MCP (Model Context Protocol) 的谷歌学术搜索工具，供 CherryStudio 等 AI 客户端调用。

功能

Tool	说明
`search_papers`	谷歌学术论文搜索，支持年份过滤、自动精确去重、SSL 断连重试
`get_paper_detail`	获取单篇论文详细信息，自动从外部源（arxiv API / meta 标签）获取完整摘要
`analyze_relevance`	TF-IDF + 余弦相似度相关性排序，关键词提取，方向聚类摘要
`generate_relevance_chart`	Matplotlib 多角度图表（柱状图 / K-Means 聚类 / 关键词）+ 本地 HTTP 服务端

Related MCP server: google-scholar-search-mcp

环境要求

Python >= 3.10
conda 环境 MCP（或任意虚拟环境）
谷歌学术需 HTTP 代理（Clash / V2Ray 等）

安装

conda activate MCP
pip install -r requirements.txt
# 或
pip install -e .

环境变量

变量	默认值	说明
`SCHOLAR_PROXY`	`http://localhost:7890`	代理地址，优先级最高
`HTTP_PROXY` / `HTTPS_PROXY`	-	标准代理环境变量（备选）
`SCHOLAR_NO_PROXY`	-	设为 `1`/`true`/`yes` 禁用代理
`SCHOLAR_TIMEOUT`	`30`	单次 HTTP 请求超时（秒）
`SCHOLAR_RETRIES`	`3`	搜索失败最大重试次数
`SCHOLAR_CHART_PORT`	`8765`	图表 HTTP 服务端端口

代理配置

三层优先级，从高到低：

SCHOLAR_PROXY  >  HTTP_PROXY / HTTPS_PROXY  >  默认 http://localhost:7890

摘要说明

Google Scholar 搜索结果页只提供摘要片段，多结果页面中不包含完整摘要。

工具	摘要行为
`search_papers`	返回 Google Scholar 片段（适合快速浏览，速度优先）
`get_paper_detail`	自动从外部源获取完整摘要：arxiv 走结构化 API，其他走页面 meta 标签；失败时回退到 Google Scholar 片段

CherryStudio 接入

1. MCP 配置

{
  "scholar-search": {
    "command": "C:/Users/mulim/.conda/envs/MCP/python.exe",
    "args": ["C:/Users/mulim/Desktop/Project/scholar_search/server.py"],
    "env": {
      "SCHOLAR_PROXY": "http://localhost:7890",
      "SCHOLAR_CHART_PORT": "8765"
    }
  }
}

路径需替换为实际路径。macOS/Linux 用户去掉盘符，使用 Unix 路径风格。

2. 在对话中使用

CherryStudio 对话时，直接描述你的研究需求即可，AI 会自动调用工具链：

示例：

"搜索 2020 年后关于 graph neural network for recommendation system 的论文，取前 10 篇，做相关性分析并生成图表"

典型调用链：

search_papers → analyze_relevance → generate_relevance_chart → 浏览器打开 http://localhost:8765

3. 图表查看

generate_relevance_chart 会启动本地 HTTP 服务并返回链接：

http://localhost:8765/

包含三个图表：

相关性柱状图 /bar.png
K-Means 聚类散点图 /cluster.png
关键词重要性图 /keywords.png

在浏览器中打开后不会自动刷新，重新调用工具即可更新数据。

开发

# 运行测试（默认跳过网络 mock 测试，~7s）
pytest

# 包含网络 mock 测试（~40s）
pytest tests/ --ignore=

# 带 coverage.xml 输出
pytest --cov=scholar_search --cov=server --cov-report=term-missing --cov-report=xml

# Lint 检查 (PEP 8, max-line=127)
flake8 --max-line-length=127 .

# 启动调试
python server.py

项目结构

scholar_search/
├── server.py              # MCP Server 入口 (FastMCP, 4 个 Tool)
├── scholar_search/        # 核心包
│   ├── config.py          # 代理 / 超时 / 重试 / 端口配置
│   ├── search.py          # requests + bs4 直连解析，外部源完整摘要（arxiv API / meta 标签）
│   ├── analysis.py        # TF-IDF + 余弦相似度 + 方向聚类
│   └── viz.py             # Matplotlib 多图表 + HTTP 服务端
├── tests/                 # pytest (137 tests, 100% 覆盖)
│   ├── test_config.py
│   ├── test_search.py
│   ├── test_analysis.py
│   ├── test_viz.py
│   └── test_server.py
├── requirements.txt
├── pyproject.toml
├── CLAUDE.md
└── .gitignore

License

MIT

Available Tools

4 tools

analyze_relevanceA

分析一组论文与研究主题的相关性，返回排序结果和分析摘要.

典型用法：先调用 search_papers 获取论文列表，再将返回的 JSON 传入此方法。

Args: topic: 研究主题描述（英文 1-3 句话），如 "using graph neural networks for collaborative filtering recommendation systems" papers_json: search_papers 返回的 JSON 字符串，需包含 papers 数组

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes
`papers_json`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/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 the input must be from search_papers and returns sorted results with a summary, but lacks details on side effects, error handling, or internal behavior (e.g., AI usage). The output schema exists but is not described.

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 front-loaded: the first sentence states the purpose, followed by typical usage and parameter details. No extraneous 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?

Given the tool has two parameters and an output schema exists, the description adequately covers the workflow and parameter expectations. It does not detail return structure (handled by output schema) or error conditions, but is reasonably complete for the complexity.

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 schema has 0% description coverage, but the description adds significant meaning: topic should be 1-3 English sentences with an example, and papers_json must be the JSON from search_papers containing a papers array. This compensates well for the bare 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 analyzes relevance of papers to a research topic and returns sorted results with a summary. It distinguishes itself from siblings like search_papers (retrieval) and get_paper_detail (individual paper) by specifying the workflow and output.

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 an explicit usage guideline: first call search_papers, then pass its JSON to this method. It clearly indicates the typical use case but does not explicitly mention when not to use it or alternative sibling tools.

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

generate_relevance_chartA

生成多角度论文相关性分析图表，启动本地 HTTP 服务端返回链接.

生成 3 张图表：相关性柱状图、K-Means 聚类散点图、TF-IDF 关键词分析。图表通过本地 HTTP 服务端 (http://localhost:8765) 提供，在浏览器中打开。返回 message 字段含 markdown 链接和原始 URL，客户端可渲染或复制。

典型用法：先调用 analyze_relevance 获取排序结果，再将其 JSON 传入此方法。

Args: topic: 研究主题描述（图表标题） papers_json: analyze_relevance 返回的 JSON 字符串，需包含 ranked_papers 数组

ParametersJSON Schema

Name	Required	Description	Default
`topic`	No
`papers_json`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Without annotations, the description carries full burden. It discloses that a local HTTP server is started, the link is returned, and the message field contains markdown and raw URL. It does not mention potential side effects or error handling, but the core behavior is transparent.

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 structured with clear sections: main purpose, what charts are generated, server details, return format, and usage. It is slightly verbose but front-loaded with the key information.

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 2 parameters and output schema (not shown but present), the description covers input format, output behavior, and prerequisite call to analyze_relevance. Missing details about error cases or server availability, but sufficient for typical use.

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?

The input schema has no descriptions (0% coverage). The description fully compensates by explaining that 'topic' is the research topic description (chart title) and 'papers_json' must be the JSON string from analyze_relevance containing a 'ranked_papers' array.

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 generates multi-angle relevance analysis charts, launches a local HTTP server, and returns a link. It details three specific chart types (relevance bar chart, K-Means clustering scatter plot, TF-IDF keyword analysis), which distinguishes it from siblings like analyze_relevance or search_papers.

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 explicitly advises to first call analyze_relevance and then pass its JSON output to this tool. It provides a typical usage pattern but does not explicitly state when not to use it or mention alternative tools for other scenarios.

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

get_paper_detailA

获取单篇论文的详细信息，自动从外部源获取完整摘要.

Args: title: 论文标题（精确匹配效果更好） url: 论文 URL（Google Scholar URL 仅限 engine=google 时使用，与 title 二选一） engine: 搜索引擎 — "bing"(默认, 免代理), "google"(需代理), "auto"(Bing优先, 失败切Google)

ParametersJSON Schema

Name	Required	Default
`url`	No
`title`	No
`engine`	No	bing

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It mentions automatic external source fetching, which is key. However, it does not discuss error handling, network failures, or rate limits, leaving some gaps in transparency.

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: a brief statement of purpose followed by a structured argument list. Every sentence adds value, and no extra information is present.

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 tool's simplicity (3 optional parameters, output schema present), the description covers core functionality and parameter usage. It lacks details on error handling and edge cases, but overall is complete enough for an agent to use effectively.

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 input schema has 0% description coverage, but the description compensates by explaining each parameter's purpose, format expectations, and constraints (e.g., 'title and URL are mutually exclusive', engine choices with default). 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 gets detailed info of a single paper and automatically fetches the full abstract from an external source. This distinguishes it from sibling tools like search_papers (which returns multiple results) and analyze_relevance (which performs analysis).

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 guidance on when to use each parameter (title exact match better, URL restricted to specific engine, engine options with default and fallback). It implies usage for single-paper details but does not explicitly contrast with siblings.

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

search_papersA

搜索学术论文，支持双搜索引擎.

单次请求最多返回 30 条结果，已内置请求间隔和限流重试。

Args: query: 搜索关键词，英文效果最佳，如 "graph neural network recommendation" num_results: 返回论文数量，1-30，默认 10 year_low: 发表年份下限，如 2020 year_high: 发表年份上限，如 2024 engine: 搜索引擎 — "bing"(默认, 免代理), "google"(需代理), "auto"(Bing优先, 失败自动切Google)

ParametersJSON Schema

Name	Required	Default
`query`	Yes
`engine`	No	bing
`year_low`	No
`year_high`	No
`num_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Discloses rate limiting and retry behavior. Does not mention auth requirements, side effects, or behavior when no results found. Basic transparency is present 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise, with purpose stated first, followed by constraints and parameter details. No redundancy. Could be slightly shorter, but effective structure.

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?

Covers all parameters, rate limiting, and engine behavior. Output schema exists, so return value explanation is unnecessary. Does not mention input validation or edge cases, but overall sufficient.

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 description explains all 5 parameters in detail: query (with example), num_results (range and default), year_low/high (meaning), engine (options). Adds significant value beyond the raw 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?

Description clearly states '搜索学术论文' (search academic papers) with specific verb and resource. It distinguishes from sibling tools such as analyze_relevance, get_paper_detail, etc., which have different purposes.

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?

Provides clear guidance on engine choices: bing (no proxy), google (needs proxy), auto (failover). Also mentions built-in rate limiting. However, does not explicitly state when to use this tool versus siblings, though siblings serve different functions.

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.

4 tool updatesv0.0.4Jul 11, 2026
- First observedanalyze_relevance
- First observedgenerate_relevance_chart
- First observedget_paper_detail
- First observedsearch_papers

Install Server

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

TDQS

A4.5/5.0

Disambiguation5/5

Each tool has a distinct role in the pipeline: search, analyze relevance, generate charts, and get paper details. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., search_papers, analyze_relevance).

Tool Count5/5

Four tools are well-scoped for a scholar search server, covering the essential workflow without excess.

Completeness5/5

The set covers the full pipeline from search to analysis to visualization and detail retrieval, with no obvious gaps.

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

PapersFlow
io.github.papersflow-ai
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Research & Data Search Documentation Access
214
paper-mcp B
io.github.MCPServings
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Research & Data Open Data
21
Books & Papers MCP Server A
io.github.jmrplens
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Education & Learning Tools Research & Data Search
418
adamamer20-paper-search-mcp-openai BOAuth
ai.smithery
Search and download academic papers from arXiv, PubMed, bioRxiv, medRxiv, Google Scholar, Semantic…
Search Research & Data Open Data
214

Related MCP Servers

CiteNexus MCP
Research & Data Education & Learning Tools
akougkas
A
license
Not graded
quality
D
maintenance
Enables AI agents to access academic citations, fetch metadata, and generate BibTeX entries directly from Google Scholar via MCP tools.
Updated 6 months ago (2026-03-11 14:15 UTC)
1
MIT
google-scholar-search-mcp
Research & Data Search
LWaetzig
A
license
Not graded
quality
C
maintenance
An MCP server for searching Google Scholar, enabling paper search, author lookup, citation tracking, and BibTeX export for AI assistants and automation workflows.
Updated 4 months ago (2026-05-10 15:20 UTC)
2
MIT
google-scholar-mcp
Research & Data Search
dihannahdi
A
license
A
quality
D
maintenance
Enables AI assistants to search and analyze Google Scholar publications, authors, citations, and download papers.
Updated 8 months ago (2026-01-17 07:39 UTC)
11
2
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
-

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/MuliMuri/scholar_search'

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