scholar-mcp

Server Quality Checklist

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

Latest release: v1.9.0
Disambiguation4/5
Most tools are clearly distinguished by resource type (papers, books, standards) and action (search, get, recommend). A few potential overlaps exist, such as get_author handling both search and fetch, and batch_resolve overlapping with get_paper for single IDs, but descriptions clarify usage.
Naming Consistency4/5
The majority follow a verb_noun pattern (search_papers, get_book, recommend_books). Minor inconsistencies include 'find_bridge_papers' instead of 'search_bridge_papers', 'batch_resolve' lacking a noun, and longer names like 'resolve_standard_identifier', but the overall convention is readable and predictable.
Tool Count3/5
At 22 tools, the server is on the heavier side, covering three distinct domains (papers, books, standards) plus utilities. While each tool has a purpose, the count exceeds the typical well-scoped range and feels slightly bloated for a single server.
Completeness4/5
The paper domain is well-covered with search, get, citation traversal, recommendations, and enrichment. Books and standards have basic CRUD-like coverage (search, get, recommend). Minor gaps exist (e.g., no separate author search, no book full-text retrieval), but core workflows are supported.
Average 4.2/5 across 22 of 22 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on July 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
The description merely restates the tool's purpose and adds no behavioral context beyond what annotations already provide. It does not mention pagination, sorting, or the nature of results, leaving the agent without insight into the tool's 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, achieving high conciseness. However, it is overly sparse and lacks the detail needed to be truly useful, making it merely adequate.
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?
Despite having 10 parameters and an output schema, the description provides no context about the tool's capabilities such as filtering, sorting, or typical usage scenarios. It does not even mention that it returns a list of papers, leaving a significant gap in contextual information.
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?
The input schema has 100% parameter description coverage, so the baseline is 3. The description does not add any additional parameter semantics, but the schema already thoroughly documents all 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 clearly states the tool searches Semantic Scholar for papers, using a specific verb and resource. It distinguishes itself from sibling tools like search_books and get_paper by explicitly naming 'Semantic Scholar' and 'papers'.
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 such as get_paper, search_books, or recommend_papers. The description lacks any mention of use cases, exclusions, or alternative tool recommendations.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds 'full metadata' but does not disclose additional behavioral context like response size, pagination, or handling of missing papers. With annotations covering safety, this is adequate but not enriched.
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 a single concise sentence, 'Fetch full metadata for a single paper,' that is front-loaded and contains no fluff. Every word contributes to clarity.
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 (one parameter, full schema coverage, output schema present, and annotations provided), the description is nearly complete. It does not explain return values, but the output schema covers that. The only minor gap is lack of mention of error cases, but openWorldHint in annotations partially covers that. Overall, it is sufficient for a straightforward fetch tool.
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% for the single identifier parameter, with a detailed explanation of supported formats (DOI, S2 paper ID, arXiv ID with prefix, etc.). The tool description adds no additional parameter context beyond the schema, so the schema carries the semantic weight; baseline 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 'Fetch full metadata for a single paper' uses a specific verb 'Fetch' and resource 'paper', with clear scope ('single'). It distinguishes from sibling tools like search_papers (search) and get_author (author), making the purpose unambiguous.
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 explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or exclusions. The usage is only implied by the name and description, which is insufficient for an agent to decide between this and similar fetch tools like get_author or get_book.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat those. However, it adds little beyond stating the lookup action; no behavior around cover_sizing, download caching, or edition inclusion is mentioned. It does not contradict 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 a single focused sentence that front-loads the main purpose and identifier scope. Every word earns its place; no redundancy or filler.
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?
The tool has an output schema and annotations cover the safety profile. The description is brief but sufficient for a metadata fetch operation; the main gap is lack of explicit usage context relative to sibling tools, which is a minor omission.
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%, with detailed parameter definitions for identifier, cover_size, download_cover, and include_editions. The description adds no new parameter semantics beyond aligning with the identifier field, which is the minimum viable level.
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's action ('Fetch') and resource ('book metadata'), and explicitly specifies the input types (ISBN or Open Library ID). This distinguishes it from sibling tools like search_books and get_book_excerpt.
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 when a book identifier is already known, but it does not explicitly contrast with alternatives such as search_books or get_book_excerpt. No exclusions or when-not-to-use guidance is provided.
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?
Annotations already disclose readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is known. The description adds the concept of positive/negative examples, but this is also reflected in the schema. No additional behavioral traits (e.g., how recommendations are computed) are disclosed.
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 a single, front-loaded sentence with no filler words. Every word earns its place, and it clearly conveys the core functionality without unnecessary detail.
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 rich schema, annotations, and output schema, the description is adequate for an agent to select and invoke the tool. It could add a bit more context about typical use cases, but the absence of such detail is not a significant gap given the structured data available.
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?
The input schema fully describes all four parameters with 100% coverage, so the baseline is 3. The description's mention of 'positive (and optionally negative) examples' adds no meaning beyond what the schema already provides.
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 ('recommend') and resource ('papers') and clearly states the mechanism ('based on positive (and optionally negative) examples'). This distinguishes it from sibling tools like search_papers, get_paper, and recommend_books.
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 use case is implied: an agent should use this tool when it has example paper IDs and wants similar papers. However, the description offers no explicit guidance on when to prefer this over alternatives, nor does it mention exclusions or prerequisites.
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?
Annotations already mark this as read-only, non-destructive, and open-world. The description adds source scope (NIST, IETF, W3C, ETSI) and mentions the 'body' filter, which is useful but not deeply behavioral. It does not disclose internal behavior like rate limits, pagination, or default ordering, but with output schema and annotations present, the extra burden is lower.
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 two concise sentences. The first sentence delivers the core purpose, and the second provides scope and a usage hint. Every sentence earns its place with no redundancy or fluff.
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 simple search tool, the description is adequate: it names the resource, search modes, source bodies, and the body filter. Combined with the exhaustive schema and output schema, it gives the agent enough to call the tool. A small gap is that it doesn't mention how results are ordered or that 'limit' caps the result count, though the schema covers the latter.
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 baseline is 3. The description reinforces query semantics ('identifier, title, or free text') and explains the purpose of 'body', but these details are also present in the schema. No additional parameter meaning is added beyond what the schema already provides.
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's function: 'Search technical standards by identifier, title, or free text.' It also specifies the resource (technical standards) and the scope (NIST, IETF, W3C, ETSI), distinguishing it from sibling search tools like search_papers or search_books.
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 gives useful context: it searches four named source bodies and explicitly instructs how to restrict to one via the 'body' parameter. This provides clear guidance on parameter usage, though it doesn't explicitly mention alternatives or when *not* to use this tool.
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?
Annotations declare readOnlyHint=true and destructiveHint=false, so safety is covered. Description adds the directional context (backward references) and clarifies it's a listing of references for a paper, but doesn't add other behavioral details like pagination behavior or error handling.
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?
A single clear sentence that conveys the core function without 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 exists and annotations cover safety, the description is sufficient for a simple fetch tool. It correctly specifies the input identifier and the direction of the relationship.
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?
All four parameters are fully described in the schema (100% coverage), so the description adds no extra parameter semantics. Baseline 3 applies.
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?
Uses specific verb 'Fetch' and resource 'papers referenced by the given paper', explicitly noting backward references, distinguishing it from get_citations (likely forward references).
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?
Implies backward-reference usage via 'backward references' but does not explicitly name alternative tools or when not to use. The sibling context suggests get_citations for forward references, but this is not 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?
Annotations already declare read-only and open-world hints, so the safety profile is covered. The description adds value by disclosing the fuzzy-input resolution behavior and the conditional full-text download via docling, which are non-obvious behavioral traits. No contradiction with 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 concise, front-loaded with the primary action, and every sentence earns its place. It avoids fluff and provides necessary details in two short paragraphs.
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?
With an output schema present and only two simple parameters, the description is complete for its complexity. It covers the core retrieval, fuzzy resolution, and optional full-text behavior, leaving no major gaps in understanding the tool's functionality.
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%, and the description largely restates the schema's parameter explanations (canonical/fuzzy identifier, fetch_full_text with docling condition). It adds no new parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
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 ('Retrieve') and resource ('standard by identifier'), and clearly distinguishes from siblings like search_standards and resolve_standard_identifier by focusing on fetching a standard. The fuzzy-to-canonical resolution detail further clarifies its unique role.
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: fetch a standard by identifier, with optional full-text retrieval. However, it does not explicitly mention when to avoid this tool or name alternatives like resolve_standard_identifier for pure identifier resolution. This is a clear context but lacks explicit exclusions.
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 declare the operation as read-only and non-destructive, but the description adds valuable behavioral details: the use of OpenAlex fallback, auto-detection of patent numbers, the configuration dependency for EPO OPS API, and that the fields parameter only applies to paper results. This goes beyond the annotations and gives the agent useful context on how the tool behaves.
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 well-structured: a clear one-sentence purpose followed by a few sentences with key technical details. Every sentence adds value without unnecessary fluff, and the length is appropriate for the tool's complexity.
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 presence of an output schema and comprehensive annotations, the description covers the essential aspects: what identifiers are accepted, how they are routed, and key fallback behavior. It does not explain error handling or partial failures, but those are likely covered in the output schema. The description is sufficiently complete for an agent to use the tool effectively.
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?
The input schema provides thorough descriptions of both parameters, achieving 100% coverage. The description adds some nuance (e.g., patent numbers are auto-detected, ISBNs require the 'ISBN:' prefix), but much of this is already implied in the schema. Since the schema carries the load, a 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 clearly states the tool's function: 'Resolve a list of paper, patent, or book identifiers to full records.' This is specific with a verb, resource, and scope. It distinguishes itself from siblings like get_paper (single) and search_papers by focusing on batch resolution of multiple identifier types.
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 clear context for when to use this tool: when you have a list of paper, patent, or book identifiers to resolve. It also explains the underlying sources (S2 batch, OpenAlex, EPO, Open Library), which helps set expectations. However, it does not explicitly mention alternatives or situations where a different tool (e.g., get_paper for single IDs) would be more 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?
The description reveals the two-step process (resolve DOI from S2, then query OpenAlex) and states that results are cached for 30 days. These details go beyond the annotations, which already mark the tool as read-only, open-world, and non-destructive. It does not mention potential failure modes or rate limits, but the provided behavioral context is valuable.
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 at three sentences, with the purpose in the first sentence, workflow in the second, and caching behavior in the third. No extraneous words or repetition of schema/annotations. It is well-structured and immediately informative.
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, the presence of an output schema, and comprehensive annotations, the description covers the essential aspects: purpose, workflow, and caching. It does not explain what happens if the DOI cannot be resolved, but that is a minor gap. Overall, the description is complete enough for effective selection and invocation.
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?
The input schema already covers both parameters with usage details, including the identifier format and the allowed enrichment fields. The description adds no new parameter-specific semantics beyond the phrase 'requested enrichment fields,' which merely restates the schema. Since schema coverage is 100%, a baseline 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 clearly states the tool's function: 'Fetch OpenAlex metadata to supplement Semantic Scholar data.' It uses a specific verb (fetch) and resource (OpenAlex metadata), and distinguishes it from sibling tools focused on searching, retrieving papers, or citations. The workflow of resolving the DOI and querying OpenAlex adds further specificity.
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 the tool is used when Semantic Scholar data needs supplementing from OpenAlex, providing clear context. However, it does not explicitly mention when not to use it or name alternative tools for comparison, such as get_paper or search_papers, so it stops short of a full usage guide.
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 declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context: it uses BFS over the citation/reference graph and leverages cached lists to minimize API calls. This informs the agent about computational cost and efficiency, which is beyond what annotations 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?
The description is two sentences: one stating the core purpose and one adding algorithmic context. Every sentence earns its place, with no filler or redundancy. The primary functionality is front-loaded, making it easy for an agent to quickly parse.
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 annotations, full schema coverage, and presence of an output schema, the description provides sufficient context for an agent to select and invoke the tool. It explains the approach (BFS) and the efficiency optimization (caching), which are valuable for understanding behavior. It lacks edge-case details like 'what if no path exists', but the output schema likely covers return semantics, so this is a minor gap.
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 coverage is 100%, with all four parameters documented including enums and defaults. The description adds no additional parameter-level explanation, so it stays at the baseline of 3. It does not contradict the schema and correctly leaves parameter details to the structured definition.
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 'Find the shortest citation path between two papers', which is a specific verb+resource pair that clearly distinguishes this tool from sibling tools like get_citations or get_references. It explicitly names the two-paper pathfinding scope, leaving no ambiguity about its primary function.
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 context is clear: use this when you need the shortest path between two papers. The mention of BFS and cached lists implies efficiency, suggesting it is preferable to manual graph traversal via sibling tools. However, it does not explicitly name alternatives or state when not to use it, so it misses a point for explicit exclusions.
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?
The description discloses the multi-step behavior: resolving via Semantic Scholar, optionally enriching with OpenAlex, and outputting to three formats. This adds meaningful context beyond the readOnly/destructive annotations, though it does not discuss failure behavior or edge cases.
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?
Two compact sentences, front-loaded with the primary action, and each clause contributes meaningful detail (resolution, enrichment, output formats). No redundancy 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?
Given the three parameters, annotations, and presence of an output schema, the description covers the main workflow and outputs. It omits edge-case handling, but that is not required for a tool of this complexity.
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?
All three parameters are fully described in the input schema (100% coverage), so the description's brief mention of resolution, enrichment, and formatting adds little new parameter-level detail. Baseline 3 is appropriate when schema carries the parameter documentation burden.
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 'Generate' and a clear object 'formatted citations for one or more papers,' and elaborates with supported formats and enrichment workflow. This clearly distinguishes it from sibling tools like get_citations, which would retrieve citation lists rather than format references.
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 the use case of converting paper identifiers into formatted reference strings, with the output formats making the context clear. It does not explicitly exclude alternatives or say 'use when you need BibTeX/CSL-JSON/RIS,' but the purpose is unambiguous enough to guide selection.
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 mark this as read-only and non-destructive. The description adds behavioral context by specifying exactly what is returned—publisher description, snippet, preview link—and the limitation that it is not full text. This goes beyond the annotations and helps set expectations for the API's constraints.
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 very concise—two sentences—and the first sentence immediately states the tool's purpose. The second sentence adds valuable behavioral limitation without redundancy. Every word 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 tool's simplicity (one parameter) and the presence of an output schema, this description fully covers what the tool does, what it returns, and its key limitation. It also aligns with the read-only annotation. No important contextual element appears 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?
The single parameter 'isbn' is fully described in the schema as 'ISBN-10 or ISBN-13,' so the description doesn't need to repeat that. The description provides no additional parameter semantics beyond what the schema already states, so a 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 begins with 'Get a book excerpt and preview info from Google Books,' which clearly identifies the action and resource. It further specifies the contents of the return: publisher description, text snippet, and link. This distinguishes it from sibling tools like get_book and search_books.
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 explains that Google Books does not expose full chapter text via API, clarifying that this tool only provides excerpts and not full content. It does not explicitly name alternative tools or when to use them, but the context of what this tool returns versus what it cannot provide is clear. Thus it offers clear context without explicit exclusions.
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 declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the key behavioral detail that this is forward citations, which is not captured by annotations or the tool name alone. It does not, however, discuss edge cases like pagination behavior beyond what the schema's parameter descriptions already 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?
The description is a single, front-loaded sentence that states the core purpose without any filler. Every word earns its place, and there is zero redundancy or tangential information.
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 presence of a complete input schema with all parameter descriptions, an output schema (not shown but indicated), and annotations that cover safety, the one-sentence description is sufficient. It clearly identifies the tool's scope (forward citations) and relies on structured fields for the rest, which is complete for a tool of this simplicity.
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?
The input schema provides 100% coverage with detailed descriptions for all 8 parameters, including the client-side filtering effect of min_citations and pagination semantics. The description itself adds no parameter information, so it does not go beyond the baseline of 3 for high schema coverage.
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 ('Fetch') and resource ('papers that cite the given paper'), and explicitly clarifies 'forward citations', which distinguishes it from backward citation tools like get_references. This leaves no ambiguity about the tool's function.
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 phrase 'forward citations' provides clear context that this tool is for finding papers that cite the given paper, implicitly differentiating it from get_references (backward citations). However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.
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?
Beyond the readOnlyHint and destructiveHint annotations, the description adds useful behavioral context: the task is processed in the background, polling is expected, and the response includes elapsed_seconds and a hint with expected duration. This helps the agent understand the polling cycle and 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?
The description is concise and well-structured, starting with the core purpose, then trigger conditions, expected duration, and response hints. Every sentence adds value without 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?
For a single-parameter polling tool with annotations and an output schema, the description covers all necessary context: when to use it, how to use it, what to expect in terms of timing and response fields. No gaps are apparent.
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 coverage is 100%, and the parameter description already explains that task_id is returned by a queued operation. The tool description reinforces this but does not add new semantic detail beyond what the schema provides, so baseline 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 clearly states the tool polls for background task results using a specific verb ('Poll') and resource ('result of a background task'). It distinguishes itself from sibling tools by focusing on task polling, which is unique among the listed siblings.
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 explicit trigger conditions: when a tool returns {"queued": true, "task_id": "..."}, call this tool. It also gives timing expectations (1-5 minutes) and polling guidance, but does not mention alternatives or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds value by disclosing the return format (JSON list of task_id and status) and the scope (active tasks), which goes beyond annotations. It does not contradict 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 extremely concise, with only two sentences: the first stating the action and the second outlining the return format. Every word is purposeful, with no redundancy 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?
For a simple, zero-parameter tool with annotations and an output schema, the description is complete. It clearly states what is listed and the shape of the return value, leaving no significant gaps in 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 zero parameters, so parameter-specific descriptions are unnecessary. The baseline for 0 params is 4, and the description appropriately focuses on behavior rather than 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 uses the specific verb "List" and identifies the resource as "active background tasks," which clearly states what the tool does. It distinguishes itself from siblings like get_task_result by focusing on the list of tasks rather than individual task results.
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 this tool is used to view active background tasks but provides no explicit guidance on when to use it versus alternatives such as get_task_result. No exclusions or alternative references are given, so usage context is only implied.
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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context about the sorting logic (by edition count as a popularity proxy) and the data source (Open Library subject API), which is beyond what annotations 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?
The description is two sentences, front-loaded with the core purpose, and every word earns its place. It avoids redundancy with the schema and annotations while providing the essential behavioral detail about sorting.
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 tool is simple with only two parameters, annotations cover safety, an output schema exists, and the description explains the underlying mechanism (Open Library API and sorting by edition count). This is fully sufficient for an agent to understand and 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 fully documents both parameters (subject and limit). The description does not add any parameter-specific information beyond what the schema already provides, so the baseline 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 clearly states the tool recommends books for a subject using the Open Library subject API, and specifies that results are sorted by edition count as a proxy for popularity. This provides a specific verb, resource, and key behavior, distinguishing it from sibling tools like search_books.
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 the use case of getting popular book recommendations for a subject, which is clear context. However, it does not explicitly mention when not to use this tool or suggest alternatives like search_books for exact matches, so it falls short of a 5.
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?
The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context by noting that it 'Uses Open Library,' implying an external dependency with potential variability, and explains the index-based performance difference between parameter types.
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?
Two sentences: the first states the core purpose, the second delivers the key usage tip. No redundant or filler content; every word 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?
For a search tool with an output schema and 100% parameter documentation, the description covers the essential aspects: what it does, the external data source, and parameter preferences. It doesn't mention full-text vs. metadata matching or potential API limitations, but these are minor given the existing structured context.
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 100% coverage with descriptions for all parameters, but the description adds semantic nuance by explaining why title/author are preferred ('dedicated indexes') and frames query as a fallback. This goes beyond the schema's 'recommended' labels by explaining the underlying reason.
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 'Search for books by title, author, or free text,' which clearly specifies the action (search) and the resource (books). It distinguishes from sibling tools like search_papers (which searches papers) and get_book (which retrieves a specific book).
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 clear internal guidance: 'Prefer title and author over query — they use dedicated indexes and return far better results.' This tells the agent which parameters to favor for better outcomes, though it doesn't explicitly contrast with sibling tools beyond the tool name and purpose.
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 declare readOnlyHint and destructiveHint, so the description adds value by explaining the dual fetch/search behavior, the 5-candidate limit for name searches, and the conditional use of limit/offset.
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?
Front-loaded with the main purpose, then a concise conditional explanation. Every sentence earns its place with no 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 and annotations, the description sufficiently covers tool behavior, parameter nuances, and disambiguation logic. No major gaps for selecting and invoking the tool.
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 covers all parameters fully, but the description adds meaning by clarifying the identifier polymorphism and the 5-candidate result for name searches, which goes 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 fetches author profiles and publications or searches by name, with a specific disambiguation behavior. This distinguishes it from sibling tools like get_paper 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?
Provides clear guidance on when to use direct ID lookup vs name search based on identifier format, but does not explicitly mention alternatives or exclusions. The conditional logic is a strong usage hint.
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 declare read-only and non-destructive behavior, and the description adds valuable algorithm details: BFS traversal, depth-limited expansion, and a hard node cap. This goes beyond the safe-read annotation by explaining execution behavior and limits, though it does not cover every edge case like open-world incompleteness.
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 concise sentences, no filler. The first sentence states the core purpose, and the follow-ups add necessary algorithm and boundary details without fluff.
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 rich input schema (100% coverage), output schema, and safety annotations, the description sufficiently covers the tool's behavior. It explains the traversal algorithm, depth limit, and node cap—enough for an agent to invoke it correctly without needing further clarification.
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 extra semantic value by explaining how depth, max_nodes, and seed_ids work together in the BFS traversal. It does not repeat every parameter but clarifies the core mechanism that gives those parameters meaning.
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 ('Traverse') and names a distinct resource ('the citation graph') with a clear scope: one or more seed papers. It differentiates itself from siblings like get_citations/get_references by emphasizing graph traversal and BFS, not simple list retrieval.
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 clearly conveys the intended use case: multi-hop citation graph traversal with controllable depth and node caps. It does not explicitly mention alternatives or when not to use it, but the BFS and graph-edge language strongly implies this tool is for relational exploration rather than basic lookup.
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 declare readOnlyHint=true, so the safety profile is known. The description adds value by detailing the exact return fields and the conditional 'when configured' upstream version block, which is useful behavioral context beyond the annotation.
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?
Two sentences, front-loaded with the primary purpose, followed by a practical usage note. Every word earns its place with no 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?
For a simple zero-parameter read-only info tool, the description fully covers what the tool does, what it returns, and when to use it. The existence of an output schema further reduces the need to describe return format in detail.
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 zero parameters, so the description doesn't need to explain parameter behavior. Baseline 4 is appropriate because there is no parameter ambiguity to resolve.
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 the specific verb 'Report' and identifies the resource ('wrapper and upstream version info'). It clearly lists the returned fields and distinguishes itself from sibling tools (which handle papers, books, etc.).
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 a clear use case: 'Useful for verifying a deployment matches the expected build.' This gives context for when to use it, though it doesn't explicitly mention alternatives or 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and non-destructive. The description adds significant behavioral detail: tries local regex first (fast, no network), falls back to source APIs, and returns all candidates when ambiguous. This goes well beyond 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?
Three sentences, all substantive. The primary purpose is front-loaded, followed by concise behavioral details. No redundant or filler content.
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?
With a single parameter fully described in the schema, an output schema present, and annotations covering safety, the description provides enough context: normalization, fallback behavior, ambiguity handling. Return values are unnecessary because output schema exists.
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?
The schema description for the sole parameter 'raw' covers 100% of the parameter semantics. The tool description does not add extra meaning about the parameter beyond calling it a 'messy standard citation string', which mirrors the schema. Baseline 3 is appropriate since schema does the heavy lifting.
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 normalizes a messy standard citation string to its canonical form, with a specific verb and resource. This distinguishes it from siblings like search_standards and get_standard, which focus on discovery or retrieval rather than normalization.
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 usage context: you use this when you have a messy citation string. It explains the local-first then API-fallback behavior, but does not explicitly mention when not to use it or alternatives like batch_resolve. Clear context is present, but exclusions are missing.
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 annotations (readOnlyHint, destructiveHint, openWorldHint), the description adds meaningful behavioral details: the output JSON structure, that 'errors' contains non-fatal error strings, and that the runs list is empty when no sync has been run. This provides context about edge cases and return semantics that annotations do not cover.
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, well-structured, and front-loaded with the main purpose. It uses a clear hierarchy: summary sentence, then details about timestamps and errors, then an explicit return format. Every sentence adds information without 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?
This tool has no parameters, a read-only annotation, and an output schema, yet the description still covers key edge cases (empty runs list, non-fatal errors, timestamp units). It is complete and self-contained, enabling the agent to understand exactly what to expect without needing additional context.
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 no parameters, and the schema coverage is trivially 100%. The description still adds value by explaining the output fields and their meanings, though parameter-level semantics are not applicable. Given the zero-parameter baseline of 4, this score 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 starts with a clear, specific verb and resource: 'Report the last sync run for each standards body.' This distinguishes it from sibling tools that handle papers, books, standards, or tasks, and leaves no ambiguity about what the tool does.
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 clearly states the tool's function and output scope ('One row per body'), making the intended use context obvious. It does not explicitly mention alternatives or exclusions, but given the unique subject matter among siblings, the usage context is clear enough to earn a 4.
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:

[![scholar-mcp MCP server](https://glama.ai/mcp/servers/pvliesdonk/scholar-mcp/badges/card.svg)](https://glama.ai/mcp/servers/pvliesdonk/scholar-mcp)

Score Badge

Copy to your README.md:

[![scholar-mcp MCP server](https://glama.ai/mcp/servers/pvliesdonk/scholar-mcp/badges/score.svg)](https://glama.ai/mcp/servers/pvliesdonk/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/pvliesdonk/scholar-mcp'

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