scholar-mcp

by Liyux3

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

Server Quality Checklist

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

Latest release: v0.8.4
Disambiguation5/5
Each tool targets a clearly distinct task: finding papers, looking up a known paper, exploring related work, finding authors, downloading PDFs, and reading PDFs. The descriptions explicitly cross-reference when to use one tool instead of another, eliminating ambiguity.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern: search_papers, search_authors, download_paper, read_paper, recommend_papers. The outlier is paper_info, which uses noun_info instead of a verb like get_paper_info, creating a minor inconsistency.
Tool Count5/5
Six tools is a well-scoped size for an academic search and reading server. Each tool covers a necessary part of the workflow without redundancy or bloat.
Completeness5/5
The tool set covers the full scholarly research loop: discovering papers, retrieving metadata, finding related work, identifying authors, and accessing full text by downloading or reading. No obvious dead ends or missing core operations for the stated purpose.
Average 4.8/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- Last stable release on September 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.
This server has been verified by its author.
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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent, non-destructive write behavior, and the description adds valuable details beyond them: repeat calls overwrite the same path, resolution tries specific sources in order, and a failed resolution writes nothing. There is no contradiction with the annotations.
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 compact and front-loads the primary purpose, then adds necessary behavioral and alternative-tool context. Every sentence contributes useful information without filler or redundancy.
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?
The description covers the key operational details: resolution order, file persistence and overwrite semantics, indexing option, failure behavior, and the alternative read_paper. With the output schema and annotations also present, an agent has enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description mostly restates defaults and indexing behavior rather than adding new parameter-level meaning, so the baseline score of 3 is appropriate.
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 and resource: resolving one paper to an open-access PDF and saving it to disk. It also distinguishes itself from read_paper by noting the alternative is for text-only needs, making the tool's purpose and scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names read_paper as the alternative and states the condition for choosing it: when only the text is needed once. It also clarifies that paywalled papers with no open copy fail cleanly, helping an agent decide when this tool is appropriate.
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?
Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond annotations: fuzzy name matching, common names returning many candidates, and the resulting need for disambiguation. This is meaningful behavioral disclosure that helps the agent set expectations.
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?
Three tightly written sentences each earn their place: purpose, routing guidance, and behavioral/usage tip. There is no filler or redundancy, and key information is front-loaded.
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?
Given the strong annotations, complete parameter schema, output schema presence, and explicit sibling comparisons, the description covers purpose, usage, behavior, and parameter semantics thoroughly. Nothing material is missing for an agent to select and invoke this tool correctly.
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?
Schema description coverage is 100%, so both query and limit are already documented. The description goes further by explaining that the query supports affiliation or field words and that matching is fuzzy, which adds semantic value beyond the bare schema. The guidance to keep limit small also clarifies how the limit parameter relates to the fuzzy matching behavior.
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 starts with a specific verb and resource: 'Search for researchers by name' and enumerates the returned fields (affiliations, paper counts, h-index, identifiers). It also differentiates itself from the sibling tools search_papers and paper_info, making its purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this for people, not papers,' and names the alternatives for each different case: search_papers for papers and paper_info for a paper's own author list. It also gives concrete disambiguation advice: add an affiliation or field word and keep limit small.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful behavioral detail: fan-out to live APIs under a time budget, degraded coverage reporting for timed-out sources, and duplicate merging across identities. No contradiction exists.
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 multi-sentence but every sentence earns its place: core function, usage routing, behavioral caveats, and a parameter-usage hint. It is organized and front-loaded without repetition or filler.
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?
The description covers purpose, sibling alternatives, failure-mode behavior, and parameter usage in a compact form. With an output schema present, return-value details are not needed. No critical information for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented. The description adds general guidance about where filters belong and the reranking behavior, which is helpful but does not need to re-explain individual parameters.
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 names a specific verb and resource ('Search for academic papers across many sources') and lists concrete sources, duplicate merging, and reranking. It also distinguishes itself from siblings by routing paper_info to identifier lookups, recommend_papers to expansion, and search_authors to people.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('find papers from a topic, a question, or a half-remembered title') and gives alternatives for other cases. It adds practical advice to put years, venues, and filters in parameters rather than the query text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, and the description adds valuable behavior: "one upstream lookup per requested section," "unresolvable identifier returns a not-found message rather than an error," and lists "ordered by influence and cut at limit." This gives the agent concrete expectations beyond safety hints.
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 compact and front-loaded: the core purpose appears in the first sentence, usage routing in the second, and behavioral notes in short, scannable sentences. Every sentence adds information; there is no filler or redundancy.
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?
Given the output schema, full parameter schema descriptions, and strong annotations, the description covers all necessary selection and invocation context: when to use it, alternatives, error behavior, list ordering, and truncation. No critical operational detail is missing.
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?
Schema coverage is 100%, so the baseline is 3. The description adds useful semantic context by explaining that citation and reference lists are "ordered by influence and cut at limit," clarifying how the limit parameter behaves and how include sections are returned. It does not need to restate schema details.
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 begins with a specific verb and resource: "Get metadata for one known paper, optionally with the papers that cite it and the papers it references." This clearly distinguishes it from search-oriented tools by emphasizing a known identifier, and the title reinforces the citation-neighborhood scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: "Use this when you already have an identifier," and names alternatives: "use search_papers to find one first, and recommend_papers for related work that is not a direct citation." This provides clear routing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses temporary file behavior, non-persistence of data, the open-access resolution chain, clean failure for paywalled papers, and the focused visual return behavior. This is substantial behavioral context that annotations alone do not provide.
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?
Three tight sentences with no filler. The core purpose is front-loaded, usage guidance follows, and the visual workflow is placed at the end. Every sentence earns its place.
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?
Given the output schema is present and annotations cover safety traits, the description covers what remains important: temporary persistence, failure behavior, sibling differentiation, and how to chain selectors into a visual call. Nothing essential for correct invocation is missing.
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?
Schema description coverage is 100%, so the schema already documents all parameters well. The description adds workflow-level meaning for pages (default reaches conclusion, max 20 pages) and visual (pass a selector from a previous response), which goes beyond the schema's per-parameter text.
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 states a specific verb and resource: fetch a paper's PDF into a temporary file and return page-aware Markdown text with figure and table selectors. It clearly differentiates itself from download_paper by noting that download_paper is the alternative for keeping the PDF.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use this to read; use download_paper to keep the PDF.' It also explains when the tool fails cleanly for paywalled papers and how to use a previous response selector as the visual parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds genuine behavioral context beyond those flags: results come from embedding and citation data, so 'very new or uncited papers return few or no neighbours.' It also explains the meaningful behavioral differences among the three relation types, which is not visible from annotations alone.
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 moderately long but every section earns its place: a one-sentence purpose, explicit routing to alternatives, a data-source caveat, and a structured explanation of the three relation types. It is front-loaded with the core purpose and usage guidance before diving into parameter semantics, with no filler.
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 tool with three relation modes and an output schema, the description is complete. It covers when to use the tool, how to choose between relations, data limitations, and the meaning of each parameter. Because an output schema is present, the absence of return-format details does not hurt completeness.
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 schema description coverage is 100%, so the baseline is 3. However, the description goes well beyond the schema by explaining what each relation value means semantically: similar, peers, and kin each get a clear definition with practical implications. This is especially valuable because the schema merely lists 'similar | peers | kin' with no per-enum 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 opens with a specific verb and resource: 'Find related papers by a chosen citation-graph relation.' It clearly distinguishes this tool from siblings by explicitly naming search_papers and paper_info as the alternatives for different needs, so an agent can immediately tell what recommend_papers is and is not for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: 'Use this when you hold one paper and want its neighbourhood.' It also names alternatives and their conditions: 'Use search_papers for a topic and paper_info for a paper's direct citation lists.' This leaves no ambiguity about tool selection.
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

scholar-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![scholar-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Liyux3/scholar-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Liyux3/scholar-mcp)

Score Badge

Copy to your README.md:

[![scholar-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Liyux3/scholar-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Liyux3/scholar-mcp)

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/Liyux3/scholar-mcp'

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