mcp-scholar

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
There is significant overlap between adaptive_search and scholar_search, both performing Google Scholar searches with similar parameters, which creates ambiguity. Additionally, summarize_papers appears to combine searching and summarization, potentially overlapping with the search tools, though its summarization aspect provides some distinction.
Naming Consistency4/5
Most tools follow a clear noun_verb or verb_noun pattern (e.g., adaptive_search, paper_detail, summarize_papers), with consistent snake_case throughout. The only minor deviation is health_check, which fits the pattern but stands out as a utility tool rather than a core scholarly function.
Tool Count4/5
With 7 tools, the count is reasonable for a scholarly search server, covering key operations like searching, retrieving details, and summarizing. However, the overlap between some tools suggests the set could be streamlined without losing functionality, making it slightly over-scoped.
Completeness4/5
The toolset covers core scholarly functions well, including searching, retrieving paper details, references, and scholar profiles, with summarization as an advanced feature. A minor gap is the lack of tools for managing saved papers or citations, but the existing tools support most common workflows without dead ends.
Average 3.4/5 across 7 of 7 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it retrieves details but doesn't mention whether this is a read-only operation, requires authentication, has rate limits, or what happens with invalid paper IDs. For a tool with zero annotation coverage, this represents significant gaps in behavioral context.
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 appropriately brief with clear sections for Args and Returns. However, the Chinese text '获取论文详细信息' could be more specific, and the structure while clean doesn't fully compensate for content gaps. It's efficient but could be more informative within its concise format.
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?
For a tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what '论文详细信息' (paper details) includes, the return format beyond 'Dict', error conditions, or how this differs from sibling tools. The minimal information provided doesn't adequately support tool invocation.
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 schema provides no parameter documentation. The description only states 'paper_id: 论文ID' (paper ID), which adds minimal semantic value beyond the parameter name. It doesn't explain format requirements, valid ranges, or examples of paper IDs, leaving the single parameter inadequately documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取论文详细信息' (Get paper details), which provides a basic verb+resource combination. However, it doesn't differentiate from sibling tools like 'paper_references' or 'profile_papers' that might also retrieve paper-related information. The purpose is clear but lacks specificity about what distinguishes this tool from alternatives.
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?
No guidance is provided about when to use this tool versus alternatives like 'paper_references' or 'profile_papers'. The description only states what the tool does without indicating appropriate contexts, prerequisites, or exclusions. This leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the tool returns service status information, which implies a read-only, non-destructive operation, but doesn't explicitly confirm this or describe other traits like error handling, response format details, or any side effects. For a tool with zero annotation coverage, this is a significant gap in behavioral context.
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 appropriately sized and front-loaded: it starts with the purpose in the first sentence and follows with return information. There's no wasted text, and every sentence earns its place. However, it could be slightly more structured by separating the return statement more clearly, but it remains efficient overall.
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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It states the purpose and return type, which is adequate for a simple health check tool. However, it lacks details on what '服务状态信息' (service status information) entails, such as possible values or error cases, making it somewhat incomplete for full contextual understanding.
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 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics beyond what the schema provides. According to the rules, 0 parameters baseline is 4, as there's nothing to compensate for, and the description doesn't contradict or add unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: '健康检查端点，用于验证服务是否正常运行' (health check endpoint to verify if the service is running normally). It uses a specific verb ('验证' - verify) and resource ('服务' - service), making the purpose unambiguous. However, it doesn't differentiate from sibling tools, which are all unrelated to health checks, so it doesn't need sibling differentiation but doesn't explicitly state this uniqueness.
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 doesn't mention any context, prerequisites, or exclusions for usage. Since sibling tools are unrelated (e.g., adaptive_search, paper_detail), there's no explicit comparison or when-not-to-use advice, leaving usage unclear beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions the tool retrieves papers and describes parameters, but lacks critical behavioral details: it doesn't specify data source limitations (e.g., Google Scholar scraping constraints), rate limits, authentication needs, error handling, or what the returned 'Dict: 论文列表' (paper list dictionary) contains structurally. For a tool with no annotations, this leaves significant gaps in understanding its operational behavior.
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 well-structured with clear sections for Args and Returns, making it easy to parse. It's appropriately sized with no redundant information. However, the front-loaded purpose statement ('获取学者的论文') is very brief and could be more informative, slightly reducing efficiency in immediate understanding.
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?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is partially complete. It excels in parameter documentation but lacks output details (only states 'Dict: 论文列表' without structure), behavioral context, and differentiation from siblings. For a tool with no annotations or output schema, more comprehensive coverage would be needed for full contextual understanding, leaving it at a minimum viable level.
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 description adds substantial value beyond the input schema, which has 0% schema description coverage. It clearly explains all three parameters: 'profile_url' as a Google Scholar profile URL, 'count' as the number of results with a default of 5, and 'sort_by' with four explicit options and their meanings. This fully compensates for the schema's lack of descriptions, providing complete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取' meaning 'get' or 'retrieve') and resource ('学者的论文' meaning 'scholar's papers'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'scholar_search' or 'paper_detail', which likely have overlapping domains. The title is null, so the description carries the full burden of purpose communication.
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. With sibling tools like 'scholar_search' and 'paper_detail' available, there's no indication of whether this tool is for a specific scholar's papers versus general search, or how it differs in scope or functionality. The user must infer usage from the parameter requirements alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the tool searches Google Scholar, it doesn't describe rate limits, authentication requirements, error conditions, or what specific data is returned beyond 'paper abstracts'. For a search tool with no annotation coverage, this leaves significant behavioral gaps.
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 well-structured with clear sections for Args and Returns. It's appropriately sized for a tool with 6 parameters, though the 'Returns' section could be more specific about the dictionary structure. Every sentence adds value.
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?
For a search tool with 6 parameters and no annotations or output schema, the description provides good parameter documentation but lacks behavioral context and output details. The 'Returns' section is vague ('Dict: 包含论文列表的字典'), leaving uncertainty about the response format. This is adequate but has clear gaps.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. It explains all 6 parameters including defaults, optional values, and for 'sort_by' provides the complete enumeration of valid options. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Google Scholar and returns paper abstracts, which is a specific verb+resource combination. However, it doesn't explicitly differentiate itself from sibling tools like 'adaptive_search' or 'paper_detail', which might offer overlapping functionality.
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 like 'adaptive_search' or 'paper_detail'. It lacks context about appropriate use cases, prerequisites, or limitations compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions searching and summarizing but doesn't disclose behavioral traits like rate limits, authentication needs, data sources, or potential errors. The description is functional but lacks operational context needed for a tool with no annotation coverage.
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 appropriately sized and well-structured: a brief purpose statement followed by clearly labeled Args and Returns sections. Every sentence earns its place by providing essential information without redundancy. It's front-loaded with the core function.
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?
Given no annotations, 0% schema coverage, and no output schema, the description does well on parameters but lacks behavioral context. It explains what the tool does and its inputs thoroughly but doesn't cover output format details (beyond 'Markdown format text'), error handling, or operational constraints. Adequate but with clear gaps for a search/summarize tool.
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%, so the description must compensate. It provides detailed parameter semantics: 'topic' as research topic, 'count' with default 5, 'sort_by' with enum values and defaults, and optional year filters. This adds significant meaning beyond the bare schema, fully documenting all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 as '搜索并总结特定主题的论文' (search and summarize papers on a specific topic), which is a specific verb+resource combination. It distinguishes from siblings like 'paper_detail' (detailed view) and 'scholar_search' (search only), though not explicitly. The purpose is clear but lacks explicit sibling differentiation.
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?
No guidance is provided on when to use this tool versus alternatives like 'adaptive_search' or 'scholar_search'. The description implies usage for summarizing papers but doesn't specify contexts, prerequisites, or exclusions. It's a basic functional statement without strategic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 basic behavioral traits: it's a read operation (implied by '获取' - get), returns a list of papers, and has default values and sorting options. However, it lacks details on error handling, rate limits, authentication needs, or what the returned dict structure contains. For a tool with no annotations, this provides minimal but not comprehensive behavioral context.
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 well-structured and appropriately sized. It starts with a clear purpose statement, followed by organized sections for Args and Returns. Each sentence adds value: the purpose is stated upfront, parameters are explained concisely with defaults and options, and the return type is specified. There's no redundant or wasted 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 tool's moderate complexity (3 parameters, no annotations, no output schema), the description is fairly complete. It covers the purpose, all parameters with semantics, and the return type. However, it lacks details on the return value structure (e.g., what keys are in the dict), error cases, or performance considerations. For a tool without annotations or output schema, this is good but not fully comprehensive.
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 description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter: 'paper_id' as the paper ID, 'count' as the number of results with a default of 5, and 'sort_by' with detailed options and their meanings (relevance, citations, date, title). This fully compensates for the schema's lack of descriptions, providing clear semantics for all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: '获取引用指定论文的文献列表' (Get a list of papers that reference the specified paper). It uses a specific verb ('获取' - get) and resource ('文献列表' - paper list), but doesn't explicitly differentiate from sibling tools like 'paper_detail' or 'scholar_search'. The purpose is clear but sibling differentiation is only implied through the specific focus on references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the parameter explanations (e.g., '默认为5' - default is 5, '可选值' - optional values), suggesting when certain options might be appropriate. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'scholar_search' or 'paper_detail', nor does it mention prerequisites or exclusions. Usage is contextually implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 clearly explains the adaptive search logic (exact→fuzzy switching based on min_results threshold) and mentions the return format ('包含论文列表和搜索模式的字典' - dictionary containing paper list and search mode). However, it doesn't disclose potential limitations like rate limits, authentication needs, or error conditions.
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 efficiently structured with a clear purpose statement followed by well-organized parameter documentation using bullet points. Every sentence adds value with no redundant information, making it easy to parse while being comprehensive.
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?
For a tool with 6 parameters, 0% schema description coverage, no annotations, and no output schema, the description does an excellent job explaining parameters and adaptive behavior. However, it could provide more context about the return structure (what fields papers contain) and potential error cases to be fully complete.
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 description provides comprehensive parameter documentation beyond the 0% schema description coverage. It explains all 6 parameters with clear semantics: keywords purpose, count default and meaning, min_results threshold behavior, sort_by options with defaults, and optional year range parameters. This fully compensates for the lack of schema descriptions.
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 performs '自适应搜索谷歌学术' (adaptive search of Google Scholar) with specific behavior: '先尝试精确搜索，如果结果太少则自动切换到模糊搜索' (first try exact search, if results are too few then automatically switch to fuzzy search). This distinguishes it from the sibling 'scholar_search' tool by explaining its adaptive nature.
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 when to use this tool by explaining its adaptive behavior that switches from exact to fuzzy search when results are insufficient. However, it doesn't explicitly compare it to the sibling 'scholar_search' tool or provide specific exclusion criteria for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp_scholar MCP server](https://glama.ai/mcp/servers/renyumeng1/mcp_scholar/badges/card.svg)](https://glama.ai/mcp/servers/renyumeng1/mcp_scholar)

Score Badge

Copy to your README.md:

[![mcp_scholar MCP server](https://glama.ai/mcp/servers/renyumeng1/mcp_scholar/badges/score.svg)](https://glama.ai/mcp/servers/renyumeng1/mcp_scholar)

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/renyumeng1/mcp_scholar'

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