Scholar MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there are multiple tools for similar operations (e.g., author search from different sources, full-text extraction methods) which could cause confusion. Descriptions help differentiate, but an agent might struggle to choose the optimal tool without deep understanding.
Naming Consistency3/5
Tool names are descriptive but lack a consistent pattern. Verbs like 'search', 'get', 'fetch', 'retrieve', 'autocomplete' are used interchangeably, and some names include suffixes like '_s2', '_scopus', '_unpaywall' without a uniform convention. This can hinder predictability.
Tool Count4/5
27 tools is slightly above the typical range but justified by the broad domain coverage (author profiles, paper search, full text, citations, books). The tools are specialized but mostly warranted; however, some could be consolidated (e.g., multiple PDF extraction tools).
Completeness4/5
The server covers a comprehensive set of academic research workflows: author disambiguation, paper search across multiple sources, metadata retrieval, full-text extraction, citation analysis, and book search/interaction. Minor gaps exist, such as lack of personal collection management or advanced analytics, but core needs are well-addressed.
Average 3.9/5 across 27 of 27 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 15, 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?
No annotations are provided, so the description carries full responsibility. It mentions search and return of data, but does not disclose behavior such as pagination, rate limits, or read-only nature. For a search tool, more behavioral context is needed.
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: two sentences with no redundant words. Front-loaded with the action and key return fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, output schema exists, many sibling tools), the description provides the essential purpose and return values. However, it lacks details on sorting, pagination, or how the institution parameter affects results, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly references 'name' and 'institution' (via 'recent institutions'), but does not explain the 'limit' parameter or provide format/syntax guidance. The description adds limited value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for deep author profiles via OpenAlex and lists specific return fields (h-index, i10-index, recent institutions). This distinguishes it from siblings like autocomplete_authors_tool (suggestions) and retrieve_author_works_tool (works), though it could be more explicit about the difference from other author search tools.
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 search_author_by_orcid_tool or get_author_profile_s2_tool. The description does not explain context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but discloses minimal behavioral traits. It mentions 'bypass' implying circumvention, but fails to disclose failure modes (e.g., Sci-Hub down, PDF not extractable), rate limits, or caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence front-loading the key functionality. It avoids redundancy, but could be slightly more structured with separate mentions of resolution and extraction steps.
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?
Given no annotations and a complex tool involving paywall bypass and PDF extraction, the description is too brief. It does not cover output schema details, reliability, or limitations. The presence of an output schema doesn't excuse missing behavioral context.
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 has one parameter (doi) with 0% description coverage. The description adds context that the DOI is resolved via Sci-Hub, but does not specify format, examples, or validation rules. It provides some meaning but not comprehensive detail.
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 it resolves a DOI via Sci-Hub and extracts full text using PyMuPDF, specifying the verb (resolve, extract) and resource (DOI, PDF). It distinguishes from sibling tools like fetch_pdf_text_unpaywall_tool and get_scihub_link_tool by combining both steps.
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 or when not to use it. There is no mention of prerequisites (e.g., valid DOI, Sci-Hub availability) or comparison with sibling tools like get_scihub_link_tool or get_full_text_tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only says 'search' and mentions is_oa, but lacks details on output format, pagination, rate limits, 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?
The description is two concise sentences, front-loaded with the core purpose, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the presence of an output schema, the description is adequate but lacks details on behavior when no results are found or on result scope.
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 0%, so the description compensates by mentioning the is_oa parameter explicitly. The query parameter is implied via 'paper titles' but lacks detailed format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Unpaywall's database by paper titles, which is specific and distinct from sibling tools. However, it does not explicitly differentiate from other search tools like search_papers_tool.
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 a tip for the is_oa parameter but offers no guidance on when to use this tool versus alternatives, nor any when-not-to-use information.
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?
Discloses the 1 req/second rate limit and slowness, which is useful. No annotations, so description carries the burden; but lacks details on output behavior beyond what output schema provides.
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?
Short and front-loaded with key information. Every sentence adds value, but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values are covered. However, parameter semantics are missing. Adequate for a simple search tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage). Description does not explain 'limit' or 'query' parameters, adds no meaning beyond names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool searches papers using Semantic Scholar, but does not distinguish from sibling tool 'search_papers_tool' which likely uses a different source.
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?
Mentions relevance sorting, TLDRs, and rate limit, implying when to use, but lacks explicit guidance on when to prefer over alternatives like OpenAlex or Scopus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'attempts' which hints at possible failure, but does not disclose failure behavior, availability restrictions, or rate limits.
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 sentence with no wasted words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and presence of an output schema, the description covers the core action but misses failure behavior and edge cases (e.g., invalid DOI). It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'doi' parameter. The description only repeats the term DOI without adding format, validation, or context 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 verb 'resolve', the resource 'DOI to PDF link', and the method 'using Sci-Hub'. It distinguishes from siblings like get_unpaywall_link_tool by specifying the source.
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 use for paywalled DOIs but provides no explicit when/when-not guidance, nor does it mention alternatives like get_unpaywall_link_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?
Describes the two backend behaviors, sort limitations, and return format (formatted string). With no annotations, this is adequate but lacks details on rate limits or authentication.
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?
Concise single paragraph with no redundancy. All sentences add value, though a bulleted list could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two backends, sort options) and no visible output schema, the description is fairly complete but the return format ('formatted string') is vague.
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?
With 0% schema description coverage, the description compensates by explaining sort_by values and use_scopus behavior, and provides a query example. However, the 'limit' parameter is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for papers using Scopus or OpenAlex, with specific mention of standard and advanced syntax. However, it does not explicitly differentiate from sibling search tools like search_papers_s2_tool.
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?
Provides guidance on when to use OpenAlex vs Scopus (e.g., for open access PDF links) and notes sort_by only works with OpenAlex. But no explicit comparison to alternatives or in which scenarios to prefer this tool over siblings.
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?
With no annotations, the description carries the full burden. It mentions rapid autocomplete via OpenAlex but does not disclose specifics such as what happens on no match, multiple suggestions, rate limits, or authentication needs. Minimal behavioral insight.
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, no wasted words, front-loaded with purpose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple autocomplete tool with output schema present, the description covers purpose, source, and use case. However, it lacks parameter descriptions, which are important. Mostly complete but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions. The description does not mention the name or limit parameters at all, so it adds no meaning beyond the schema. This is a significant gap.
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 it rapidly autocompletes author names via OpenAlex to find the correct OpenAlex ID, and positions it for disambiguation before tracking works. This distinguishes it from siblings like search_authors_tool or retrieve_author_works_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Useful for disambiguation before tracking works,' which gives clear context for when to use it. It does not explicitly exclude other scenarios or mention alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; the description discloses the action (resolves PDF, extracts text) and uses PyMuPDF. However, it omits failure modes (e.g., no PDF found), authentication needs, and rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose with 'An all-in-one bypass'. It is concise but could benefit from clearer structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set (only DOI) and the existence of an output schema, the description covers the essential action. However, missing error handling details slightly reduces completeness.
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?
With 0% schema coverage, the description adds value by stating 'Takes a DOI'. For a single parameter, this clarifies its role, though format expectations are not detailed.
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 verb ('resolves', 'downloads/extracts'), resource ('PDF via Unpaywall'), and distinguishes from siblings like get_unpaywall_link_tool and fetch_pdf_text_scihub_tool.
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 explicit guidance on when to use this tool vs alternatives, prerequisites (e.g., valid DOI), or rate limits. The description only implies usage for Unpaywall access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes a read operation ('Get') but does not disclose any behavioral traits such as rate limits, authentication, or data freshness. The output schema covers return details, but the description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. However, it lacks context such as how to obtain the required S2 authorId. More could be added to guide the user.
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 0%, so the description must compensate. It adds meaning by specifying that the author_id should be an S2 authorId, which is more specific than the schema's 'Author Id' label.
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 verb 'Get', the resource 'author bibliometrics', and the source 'Semantic Scholar using an S2 authorId'. It distinguishes from sibling tools like get_author_profile_scopus_tool which uses a Scopus ID.
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 does not provide guidance on when to use this tool versus alternatives. It does not mention that a prior search tool should be used to obtain the S2 authorId, nor does it specify any 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?
No annotations are provided, so the description carries the burden. It states the tool returns 'formatted detailed text', implying a non-destructive read operation. However, it does not disclose potential error conditions, rate limits, or authentication requirements. The behavioral disclosure is adequate but not rich.
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: three sentences that front-load the purpose, explain ID handling, and mention the output format. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which details return structure), the description does not need to elaborate on output fields. It adequately states it returns 'detailed text' with abstract. Considering sibling tools exist for different sources, the description provides enough context for basic usage.
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 single parameter paper_id has no schema description (0% coverage). The description adds significant value by explaining valid formats: Scopus ID (including prefix) or DOI. This helps the agent format the input correctly, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: getting detailed metadata and the full abstract for a specific paper. It also explains the ID resolution logic, distinguishing it from the sibling get_paper_details_s2_tool by noting it uses Scopus for Scopus IDs and DOIs. However, it does not explicitly state this tool uses Scopus exclusively, which could be clearer.
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 provides some usage guidance by explaining which paper_id formats are accepted and that it uses Scopus. However, it does not give explicit when-to-use or when-not-to-use guidance, nor does it mention the alternative sibling tool (get_paper_details_s2_tool) for comparison.
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?
The description discloses that results are chronologically sorted, providing some behavioral context. However, with no annotations, it lacks details on side effects, authentication, rate limits, or return structure beyond the sorting.
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 two sentences, no fluff. The first sentence states the core action, the second gives a practical example.
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 description is sufficient for a simple retrieval tool given the existence of an output schema. It covers purpose, sorting, and input format. Slightly more detail on when to use would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the author_id format via example but does not address the 'limit' parameter at all. Since schema coverage is 0%, the description should compensate but fails to explain what limit controls or how to use it.
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 retrieves chronologically sorted publications for an OpenAlex author ID. It uses a specific verb and resource, and distinguishes it from siblings like search_authors_tool or get_author_profile_scopus_tool.
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 via an example input but does not explicitly state when to use this tool over alternatives or any prerequisites. There is no guidance on 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions using CrossRef content negotiation, which hints at an external dependency, but does not disclose potential failure modes, rate limits, or internet requirement. With no annotations, more detail would be beneficial.
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 with no wasted words. The purpose is front-loaded in the first sentence. Every statement adds value.
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 a single parameter and an output schema (present but not shown), the description covers the essential purpose and behavior. Missing some edge case handling details, but overall sufficient for a simple 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?
The only parameter (doi) is referenced in the description as 'given its DOI', but no additional validation, format, or example is provided. With 0% schema description coverage, this is minimal but adequate for a single obvious parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a BibTeX entry for a paper given its DOI. It specifies the input and output, distinguishing it from sibling tools like format_citation_tool by focusing on BibTeX format.
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 use when a BibTeX entry is needed for LaTeX, but does not explicitly state when to use this tool versus alternatives (e.g., format_citation_tool) or when not to use it. No guidance on handling invalid DOIs or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Get detailed metadata', implying a read operation but not explicitly stating it is non-destructive or if it requires authentication. No information about error behavior, rate limits, or side effects is provided.
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 with two sentences, no filler, and the core action is front-loaded. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values need not be explained. However, the description lacks behavioral completeness (e.g., no mention of safety or error handling). For a simple metadata retrieval, it is adequate but could be more comprehensive.
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 0%, so the description must compensate. It explains both parameters: book_id format ('e.g., OL12345W or Google Volume ID') and source values ('openlibrary' or 'googlebooks'). It adds meaning beyond the schema, though it could note that source defaults to 'openlibrary'.
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 action ('Get detailed metadata') and the resource ('a specific book'). It distinguishes itself from sibling tools like search_books_tool and interact_with_book_tool by focusing on retrieving metadata for a single known 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 explicit usage by naming the required parameters (book_id and source) and giving examples. However, it does not specify when not to use this tool (e.g., when searching is more appropriate) or mention alternatives like other get tools for papers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that the tool extracts text from OA sources, supports page ranges, and can return large strings. However, it does not mention error handling, authentication, or rate limits, leaving gaps.
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 brief and front-loaded with the main purpose. Every sentence adds value: the use case, page range help, and a warning. 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 3 parameters and no annotations but has an output schema (not shown). The description covers the main behavior and parameter usage. Missing details like error responses or size limits, but adequate for a straightforward extraction 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 coverage is 0%, so the description must compensate. It explains the url parameter as 'Open Access PDF or HTML page' and describes start_page/end_page as 1-indexed for specific page extraction. This adds meaningful context, though the url description is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts full text from an OA PDF or HTML page given a URL. It specifies a use case after search_papers_openalex. However, it does not explicitly differentiate from the sibling tool get_full_text_visual_tool, missing a 5.
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 when to use (after finding an OA PDF link) and provides guidance on start_page/end_page usage. It includes a warning about large strings. It lacks explicit when-not-to-use or alternative tools, but gives clear context.
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?
Without annotations, the description carries full burden. It mentions using CrossRef/DOI content negotiation, hinting at authoritative formatting, but does not disclose error handling, rate limits, or required DOI validity.
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: purpose, supported styles, technology. Front-loaded and concise with no redundancy.
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 simple 2-param tool and presence of output schema, the description covers the main purpose, styles, and technology. Minor gap: no mention of DOI format requirements.
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 has 0% description coverage, so description must compensate. It adds value by listing supported styles for the 'style' parameter, but does not clarify the 'doi' parameter format 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 verb 'format' and the resource 'citation for a paper', and lists the supported styles, distinguishing it from sibling tools like get_bibtex_tool.
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 lists supported styles and mentions using DOI/CrossRef, providing context for when to use. However, it lacks explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses it accepts two identifier types and returns metadata with TLDR, but omits behavioral traits such as error handling, rate limits, or authentication requirements. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words. The most critical information is front-loaded: 'Get detailed metadata from Semantic Scholar, including the AI-generated TLDR.' Immediate 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?
With one parameter and an output schema present, the description covers the essential input details and the core functionality. It lacks information on error conditions or prerequisites, but given the tool's simplicity and the presence of an output schema, it is reasonably complete.
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 0%, so the description compensates by clarifying that paper_id can be an S2 paper ID or a DOI, providing concrete examples. This adds significant meaning beyond the schema's generic 'Paper Id' label.
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 retrieves detailed metadata from Semantic Scholar, including the AI-generated TLDR. It specifies the resource (Semantic Scholar) and the action (get metadata), distinguishing it from sibling tools like get_paper_details_tool which may use a different source.
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 provides input guidance (accepts S2 paper ID or DOI) but does not specify when to use this tool over alternatives like get_paper_details_tool or search_papers_tool. There is no explicit 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals the underlying method (bibliographic coupling and co-citation), which adds transparency. However, it does not discuss side effects, rate limits, or authentication requirements, leaving some gaps.
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 three sentences long, front-loaded with the main purpose, and each sentence adds value without extraneous words. It is efficiently structured for quick parsing.
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 and the presence of an output schema, the description covers the essential input details (paper ID format, limit) and method. It is mostly complete, though it could explicitly describe the limit parameter's effect.
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 0%, so the description must compensate. It clarifies that paper_id accepts DOI or OpenAlex ID, adding meaning beyond the schema. However, it does not explain the limit parameter beyond its existence (default 10), leaving room for improvement.
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 finds related/similar papers for a given paper, specifying accepted identifiers (DOI or OpenAlex ID) and the method used (bibliographic coupling and co-citation). This distinguishes it from sibling tools like search_papers or get_paper_details.
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 the tool is for finding related works based on a specific paper, but does not explicitly state when to use it versus alternatives, nor provides exclusions or prerequisites. It offers basic usage context but lacks guidance on 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?
No annotations are provided, so the description must convey behavioral traits. It does so by stating that the tool returns topic names, parent fields, domains, and publication volume, which implies a read-only operation. The verbs 'Browse and discover' suggest nondestructive behavior. The description adds sufficient behavioral context for a search tool.
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: three sentences that efficiently convey purpose, return values, and use cases. It is front-loaded with the core action and contains no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema exists), the description covers the core purpose and return fields. However, it lacks parameter explanations and more detailed usage context, such as when to prefer this over sibling search tools. The presence of an output schema reduces the need for return value details, but the overall guidance could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter description coverage, and the tool description does not explain the parameters 'query' or 'limit'. While the parameter names are somewhat intuitive, the description offers no additional meaning, such as expected query format or limit range. This forces the agent to rely solely on parameter names, which is insufficient for optimal use.
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 purpose: browsing and discovering research topics/concepts for a given keyword. It uses specific verbs like 'Browse and discover' and identifies the resource as 'research topics/concepts', distinguishing it from sibling tools focused on authors or papers. The mention of returned fields (topic names, parent fields, domains, publication volume) further clarifies its 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 description provides explicit use cases: 'mapping a research landscape, finding subfields, or identifying trending areas.' This guides the agent on when to use the tool. However, it does not explicitly state when not to use it or compare to alternatives like search_papers_tool. The context is clear but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly indicates read-only behavior by stating 'retrieve' and 'returns'. It does not mention any side effects, auth requirements, or rate limits, which is acceptable for a simple retrieval tool. However, it could be more explicit about the source (Scopus).
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 with no wasted words. The first sentence states the action and constraint, the second describes the output. Front-loaded and efficient.
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 existence of an output schema, the description need not detail every returned field. It mentions key metrics (h-index, document metrics). For a simple retrieval tool, this is sufficient. It leverages the output schema for the rest.
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 sole parameter author_id has no schema description (0% coverage), but the description compensates by specifying that it must be a Scopus Author ID consisting of digits. This adds meaning beyond the schema's generic string type. The format constraint ('digits') is useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves a Scopus author profile using a Scopus Author ID, and specifies the returned metrics (h-index and document metrics). It distinguishes itself from sibling tools like get_author_profile_s2_tool (Semantic Scholar) and search_authors_tool (search by name).
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 that the tool should be used when you have a Scopus Author ID (digits) but does not explicitly state when not to use it or what alternative to use if the ID is unknown. It lacks guidance on prerequisites or fallback options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively explains the behavior of each action: returns TOC, searches for keyword returning only found pages, extracts text from start_page to end_page. It adds context beyond the schema but could be improved by mentioning error handling or limitations (e.g., invalid md5).
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 and well-structured, using a brief introductory sentence followed by a bullet list. Every sentence adds value, and the overall length is appropriate for the 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 5 parameters (1 required), no annotations, and existing output schema, the description covers the key behaviors for the actions. The missing explanation for 'md5' is a minor gap. Overall, it is sufficiently complete for an agent to use 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 0%, so the description must compensate. It explains the 'action' parameter and its values, and contextualizes 'keyword', 'start_page', 'end_page'. However, the required 'md5' parameter is only mentioned vaguely in the first line without detailed semantics (e.g., format, length). This leaves a gap.
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 purpose: 'Extract text or interact with a book using its Libgen MD5 hash.' It enumerates specific actions (toc, search, pages) making it distinct from sibling tools like search_books or get_book_details.
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 guidance on when to use each action (e.g., 'toc' for table of contents, 'search' with a keyword, 'pages' for a page range). However, it does not explicitly state when not to use this tool or suggest alternatives, leaving some implicit inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states what is returned, not behavioral traits like pagination, error handling, or rate limits. Adequate for a simple search but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, 20 words. No fluff. Front-loaded with the action and key details.
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 an output schema exists (not shown), the description provides sufficient context for a search tool. Could mention that results include identifiers for further actions, but overall complete for basic use.
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 has 3 parameters with 0% description coverage. The description adds meaning by naming the possible values for source (openlibrary, googlebooks). Does not elaborate on limit or query beyond 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?
Clearly states it searches for books using specific sources (openlibrary or googlebooks) and returns titles, authors, and year. Distinguishes from sibling tools like search_papers and search_authors.
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?
Indicates the tool is for book searches via two sources. While it doesn't explicitly exclude other use cases, the sibling tool names make the context clear. Could mention when to prefer this over search_papers or search_libgen.
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?
No annotations provided, so description carries burden. Reveals it searches and returns MD5 for text extraction. Could mention pagination or error states but adequate for a search tool.
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 short sentences plus a brief best practice. Front-loaded with purpose, no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return values are covered. Purpose and guidelines are strong, but missing parameter documentation for limit leaves a gap. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description only implicitly references 'query' via 'search for books'. Does not explain 'limit' parameter. Fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search for books in Library Genesis (Libgen).' Verb+resource+context. Differentiates from sibling 'search_books_tool' by noting that tool is for synopsis first.
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?
Explicit BEST PRACTICE section: 'ALWAYS use search_books_tool FIRST... Once you decide which book is best, use this tool to find its MD5.' Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as retrieving citations and tracking lineage, which implies read-only behavior, but does not explicitly state that or disclose other traits like rate limits or authorization needs.
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, with four short sentences. The first sentence states the purpose, and subsequent sentences add necessary details. No superfluous words.
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 two parameters, both adequately explained. There is an output schema, so return values are covered. The description could be considered complete for a simple retrieval tool, though it might lack context on the format or size of the citation list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds full meaning: paper_id accepts a DOI or OpenAlex ID, and direction accepts 'references' or 'citations' with clear explanations. Compensates completely for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a paper's citations (verb 'retrieving', resource 'paper's citations'). It distinguishes from sibling tools by focusing on citation lineage.
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 explicit guidance on how to use it: providing a DOI or OpenAlex ID, and setting direction to 'references' or 'citations'. It explains the purpose of each direction, but does not explicitly mention when not to use or alternatives.
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?
Without annotations, the description effectively discloses behavior: downloads PDF, renders pages to images, returns multimodal content, and warns about high token/vision usage. It does not mention any destructive actions, which is appropriate. Could be improved by noting that it doesn't modify the PDF.
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, with a clear opening statement, specific use cases, and a warning. Every sentence is necessary and front-loaded. No redundancy.
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 no output schema, the description covers purpose, usage, behavior, parameter defaults, and return format ('sequence of texts and images'). It is complete enough for an agent to use effectively, though exact output structure could be clarified.
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 0%, so description must compensate. It mentions max_pages defaults to 3 and implies its purpose, but url is not described. This adds some value but does not fully clarify both parameters. 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 is a multimodal vision tool for analyzing visual elements like graphs and tables, contrasting with text-only tools. It specifies the action (download PDF, render pages into images) and distinguishes from siblings by emphasizing visual analysis.
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?
Explicitly says 'Use this if the user asks you to analyze a graph, table, format, or layout' and 'If the text extractor doesn't capture formatting, you can use this tool'. This provides clear when-to-use and when-not-to-use guidance, referencing alternatives implicitly. Also warns about high token usage.
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 key behavioral traits: it accepts up to 50 DOIs and returns specific fields (title, authors, year, citation count, OA status). With no annotations provided, the description carries the full burden, and it adequately covers the operation's read-only nature and output structure.
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 three sentences, each adding value. It front-loads the core action and then provides detail, with no redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple batch lookup tool with one parameter and an output schema (though not shown), the description covers the essential behavior. However, it lacks details on error handling (e.g., invalid DOIs) and partial results, which would enhance 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 input schema has low coverage (0%), but the description adds significant meaning: it specifies the parameter is a list of DOIs with a maximum of 50, and it clarifies the expected output fields. This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Batch-fetch metadata for multiple DOIs in a single call.' It specifies the resource (DOIs) and the verb (batch-fetch), which distinctly sets it apart from sibling tools like get_paper_details that handle single DOIs.
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 context for usage: 'Useful for processing reference lists or comparing multiple papers at once.' This implicitly suggests when to use the tool, though it does not explicitly exclude alternatives or provide when-not-to-use guidance.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns full author profile with specific fields (h-index, works count, affiliations), which is informative for a read operation.
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 with no waste. The main purpose is front-loaded, followed by input format and output summary.
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 single parameter, clear input format, output schema existence, and the description listing key return fields, the description is complete and does not leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (empty property description), but the tool description adds crucial format guidance: accepts raw ORCID or full URL. This fully compensates for the schema's lack of description.
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 verb 'Look up' and the resource 'author directly by their ORCID identifier'. It distinguishes from sibling tools that search by other criteria.
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?
It explains when to use (when you have an ORCID) and provides input format options, but does not explicitly mention when not to use or list alternatives. The context is clear enough for an agent.
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?
No annotations are present, so the description carries full burden. It transparently describes the behavior: queries Unpaywall, returns URL if found, or states strict paywall. No side effects or contradictions.
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 efficient sentences, front-loaded with the key action. No excess words or 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 single parameter and existence of an output schema, the description provides sufficient context for the tool's purpose and behavior. It covers input, process, and typical outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter (doi) with 0% coverage. The description explains that the DOI is used to query the Unpaywall database, adding crucial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it checks the Unpaywall database with a DOI to find a legal Open Access PDF link, and indicates success or paywall. It distinguishes from siblings like get_scihub_link_tool (illegal) and fetch_pdf_text_unpaywall_tool (fetches text).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you have a DOI and want OA PDF), but does not explicitly mention when not to use or suggest alternatives like search_titles_unpaywall_tool for title-based search or get_scihub_link_tool for non-legal links.
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/mlintangmz2765/Scholar-MCP/badges/card.svg)](https://glama.ai/mcp/servers/mlintangmz2765/Scholar-MCP)

Score Badge

Copy to your README.md:

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

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