Skip to main content
Glama
Sign In
Scholar MCP

Scholar MCP

by Liyux3
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Recommend related papers

recommend_papers
Read-onlyIdempotent

Find related academic papers around a given paper using semantic similarity, co-citation, or shared references to explore connections across topics.

Instructions

Explore related work around a paper, including connections across topics.

similar finds semantic neighbours and is the default. peers finds papers cited alongside it. kin finds papers sharing its references, including connections across topics. For direct citation lists, use paper_info.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum results (default 10)
paper_idYesPaper identifier (S2 ID, DOI, ArXiv:ID, OpenAlex ID, etc.)
relationNosimilar | peers | kinsimilar

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.8.3
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum recommendations (1-500, default 10)"New value: +"Maximum results (default 10)"
    • addedInput schema / properties / relation
      Added value: +{
+  "default": "similar",
+  "description": "similar | peers | kin",
+  "type": "string"
+}
    • addedOutput schema / additionalProperties
      Added value: +true
    • removedOutput schema / properties
      Removed value: -{
-  "result": {
-    "type": "string"
-  }
-}
    • removedOutput schema / required
      Removed value: -[
-  "result"
-]
    • removedOutput schema / x-fastmcp-wrap-result
      Removed value: -true
  2. First observedv0.6.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds behavioral context the annotations cannot: which relation is the default when the agent omits it, and what kind of relatedness each mode surfaces. It stops short of noting result-set characteristics, but the output schema exists to cover returns.

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?

Purpose is front-loaded in one sentence, followed by a compact per-mode breakdown and a routing pointer to paper_info. The only waste is the phrase "including connections across topics," which appears both in the opening sentence and in the kin definition.

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 three-parameter, read-only recommendation tool with an output schema, the description covers modes, defaults, and the sibling escape hatch. Nothing essential to a correct call is missing; limit behavior is left to the schema, which is reasonable.

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, but the schema's relation field only lists "similar | peers | kin" with no enum, leaving the values opaque. The description supplies the actual meaning of each value and flags similar as the default, which is real added value over the structured field.

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 ("Explore related work around a paper") and then decomposes it into three named modes. It explicitly distinguishes itself from the sibling paper_info ("For direct citation lists, use paper_info"), so an agent can route between them without opening either schema.

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?

Each mode carries a when-to-use rule: similar is called out as the default, peers for co-cited papers, kin for shared-reference papers, and paper_info for raw citation lists. That is explicit when/when-not guidance with a named alternative, leaving little to inference.

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

Deploy Server

Other Tools