semanticscholar-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: search vs. retrieval vs. authors vs. references/citations. Even the search variants (search_papers, search_papers_bulk, match_paper_title, autocomplete_paper) are clearly differentiated by their descriptions—relevance ranking, bulk output, exact title match, and title completion.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (get_, search_, match_, autocomplete_). Plural/singular usage is logical (get_paper vs get_papers_batch) and the bulk suffix is uniformly applied.
Tool Count5/5
14 tools is well within the ideal range for a scholarly data API. Each tool covers a meaningful aspect of paper and author retrieval, with bulk and single-item variants earning their place.
Completeness5/5
The tool surface covers the full read-only lifecycle: paper search, paper details, references, citations, author search, author details, author papers, and bulk operations. No obvious dead ends or missing operations for the stated domain.
Average 3.3/5 across 14 of 14 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source for behavioral disclosure, but it only restates the search action and gives no information on case sensitivity, matching behavior, pagination, ordering, or result structure. It does not contradict annotations (none exist), but 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, but it is under-specified rather than concisely informative. It could include parameter or usage details without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and sibling tools offering alternative search/retrieval paths, the one-line description leaves out essential context about pagination, parameter semantics, and when to choose this over related tools. An output schema exists, but that does not compensate for the missing contextual guidance.
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?
Input schema has 0% description coverage and 4 parameters. The description adds meaning only to the 'query' parameter ('by name'), leaving limit, offset, and fields unexplained in either the schema or description.
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?
Description clearly identifies verb ('Search') and resource ('authors') with the search criterion ('by name'), distinguishing this from sibling tools like get_author or search_papers at a basic level. However, it doesn't explicitly contrast with siblings or define the exact search scope, so not 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use search_authors versus search_papers, get_author, or get_authors_batch. The phrase 'by name' implies a use case, but it provides no context, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the 'up to 1000' limit, but omits what happens if more than 1000 IDs are passed, how invalid or missing IDs are handled, whether partial results are returned, or any permissions/rate limits. The read-only nature is implied by 'get' but not explicitly stated.
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: 'Get details for up to 1000 authors at once, given a list of author IDs.' Every word adds value, and there is no redundancy or filler. It fully earns its place.
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?
The tool is simple, and the existence of an output schema covers return values, but the description still leaves critical gaps: the 'fields' parameter is unexplained, and there is no guidance on when to choose this tool over get_author or search_authors. The description is functional but incomplete for an agent to confidently invoke it with correct parameters.
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 for parameter explanation. It implicitly covers 'author_ids' by saying 'given a list of author IDs', but the 'fields' parameter is never mentioned. Without any hint, the agent cannot know whether 'fields' selects a subset of details or controls output formatting. This is a significant gap for a two-parameter tool.
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 gets details for multiple authors at once, which distinguishes it from the singular get_author sibling. The verb 'get' and resource 'details for up to 1000 authors' are specific, but it doesn't explicitly name the alternative tool for single-author lookups, so it doesn't fully capitalize on sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicit: 'given a list of author IDs' suggests using this when you have multiple IDs, but it doesn't explicitly say when not to use it (e.g., for a single author use get_author). No alternatives or exclusions are mentioned, so the guidance is present only by inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without describing pagination defaults, sorting, or what constitutes 'referenced' (e.g., whether it includes self-citations or only works cited). No additional behavioral traits 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 sentence with no redundant words. It is appropriately concise and front-loaded with the core action, making it easy to parse.
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?
The tool is relatively simple and includes an output schema, so return values are covered. However, the description leaves gaps: it does not explain when to use this over get_paper_citations, nor does it elaborate on parameter behavior. It is adequate for a basic list operation but lacks essential usage context.
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%, and the description provides no explanation of parameters beyond the schema's names/types. It does not clarify the meaning or semantics of 'limit', 'offset', 'fields', or even 'paper_id'. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists papers referenced by a given paper, using a specific verb ('List') and resource ('papers referenced by a given paper'). It distinguishes from sibling tools like get_paper_citations, which would list citing 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?
The description provides no guidance on when to use this tool versus alternatives such as get_paper_citations or search_papers. There is no mention of any exclusions or specific scenarios for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states a basic listing action and does not mention pagination, field selection, or any side effects. The read-only nature is implied but not explicitly stated.
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 unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly.
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?
The tool has four parameters and an output schema, but the description omits important usage details like pagination (limit/offset) and field selection. While output schema covers return values, the lack of parameter context makes the description incomplete.
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 only implies the author_id parameter via 'given author' and does not explain limit, offset, or fields. This adds minimal meaning beyond the parameter names.
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 'List' and identifies the exact resource: papers written by a given author. This clearly distinguishes it from sibling tools like get_paper_authors (which lists authors for a paper) and search_papers (which finds papers via search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_papers or get_paper. It simply states what the tool does without any exclusions or context about preferred use cases.
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?
The description carries the full burden since no annotations are provided. It discloses the relevance-ranking behavior, but it does not mention whether the operation is read-only, what fields are searched (title, abstract, full text), or any rate limits or pagination behavior. This lack of behavioral detail makes it insufficient for a tool with no annotation support.
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, well-structured sentence of 23 words. It is front-loaded with the core action ('Relevance-ranked search') and efficiently lists the filters without superfluous wording. Every phrase contributes to the overall understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no annotations, the description is relatively sparse. It covers the main purpose and enumerates key filters, but it does not explain pagination defaults, the meaning of 'fields' vs 'fields_of_study', or any nuances of relevance ranking. The output schema may fill some gaps, but the description alone is only minimally complete for a complex 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 schema has 0% description coverage, so the description must compensate. It adds meaning by listing the filter categories (year, venue, field of study, publication type, citation count, open access), which map to several parameters. However, it omits query, limit, offset, and the 'fields' parameter, leaving some parameters unexplained. It partially compensates but not fully.
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 that the tool performs a relevance-ranked search for papers with optional filters on year, venue, field of study, publication type, citation count, and open access. This provides a specific verb (search) and resource (papers), making the core purpose clear. However, it does not explicitly distinguish this tool from sibling tools like search_papers_bulk, which also searches papers, so it falls short of a perfect 5.
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. There is no mention of 'use this for single queries' or 'use search_papers_bulk for batch queries'. The description only states what the tool does, without any context on appropriate use cases 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?
No annotations are present, and the description only states the basic function. It does not disclose pagination behavior, parameter requirements, or return format, leaving the agent without critical 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 that directly states the tool's purpose with no redundant information, achieving high conciseness and clear structure.
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?
While the tool is simple and has an output schema, the description lacks context on pagination or parameter usage, making it only partially complete for an agent to use effectively.
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 describes parameters limit, offset, fields, and paper_id, but the description adds no semantic meaning. With 0% schema description coverage, the description fails to compensate for the missing parameter explanations.
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 verb 'List' is specific and 'papers that cite a given paper' clearly identifies the resource, distinguishing it from siblings like get_paper_references which lists papers cited by the paper.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives such as get_paper_references, nor does it give 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning pagination, ordering, field filtering, or access requirements. The schema's limit/offset parameters imply pagination, but the description itself adds no 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, front-loaded sentence with no filler. It is appropriately concise for the simplicity of the tool, though more details could be added without violating conciseness.
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?
Although an output schema exists, the description is incomplete for the tool's full capability. It fails to mention how to use fields, limit, or offset, and does not describe any behavioral nuances. It is minimally viable for a basic call but not sufficiently complete for an agent to fully exploit the tool.
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%, and the description only clarifies the role of paper_id. It does not explain the semantics of limit, offset, or the fields parameter, such as which author fields are available or how pagination works. This provides minimal compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('authors of a given paper'), making it easy to distinguish from sibling tools like 'get_paper' (paper metadata) or 'search_authors' (author search).
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 usage context (given a paper ID) but provides no explicit exclusions or alternatives. It does not say when to choose this over related tools such as 'get_paper_references' or 'get_author_papers'.
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 must disclose return behavior, error handling, and matching semantics. It only states the basic action, not what happens when no match exists, how titles are compared, or whether the result is a single object. This lack of behavioral detail is a significant gap.
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 that is immediately front-loaded with the core action and resource. Every word contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no annotations and no schema descriptions, the description is too sparse. It gives no context about the 'fields' parameter, the matching algorithm, or edge-case behavior. Even though an output schema exists, the description alone doesn't provide enough information for an agent to know how to correctly invoke the tool in all situations.
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 provides no descriptions (0% coverage). The description clarifies that 'query' is the query string to match, but the optional 'fields' parameter is unexplained—there is no hint about what fields can be requested, how they affect the response, or the default behavior. As a result, the description only partially compensates for the schema's lack of parameter documentation.
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 'Find' and clearly identifies the resource as 'the single paper whose title best matches the given query string.' This distinguishes it from sibling search tools by emphasizing the single-result, title-specific nature.
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 a precise use case (finding the one best title match) but does not explicitly state when to prefer it over search_papers, search_papers_bulk, or autocomplete_paper. No alternatives or exclusions are mentioned.
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 of behavioral disclosure. It specifies the source fields (full texts, abstracts, titles) and mentions optional filters, but does not disclose whether the operation is read-only, any result ordering, pagination, or side effects. The verb 'search' implies read-only, which adds a bit of context, but this is minimal.
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, well-structured sentence that front-loads the core action and resource. It is concise with no fluff or irrelevant details.
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 an output schema, the description is too sparse for a tool with 7 parameters and no annotations. It does not elaborate on the optional filters, any constraints, or how this tool fits into the broader search capability set. The lack of parameter details makes it incomplete for an agent to use effectively.
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?
With 0% schema description coverage, the description must compensate for parameter meaning. It only names 'query' and refers to 'optional filters' without enumerating the six filter parameters (venue, paper_ids, etc.) or explaining their purpose. This is insufficient for correct invocation.
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 (search), the resource (text snippets from paper full texts, abstracts, and titles), and the query matching aspect. It distinguishes itself from sibling tools like search_papers by focusing on snippets rather than papers themselves.
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 searching for snippets within paper text, but it does not explicitly mention when to use this tool over search_papers or other alternatives. There is no exclusionary guidance or mention of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions the 500-paper limit but lacks details on error handling, missing IDs, response format, or any side effects. It doesn't even explicitly state it is a read-only operation, though that is implied.
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 core purpose ('Get details') and key constraints ('up to 500', 'list of paper IDs'). Every word earns its place, with no filler or repetition.
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 the complexity of a batch tool and the presence of an output schema, the description is incomplete. It omits critical context about the 'fields' parameter, behavior with invalid IDs, and whether the response is a list or map. While the output schema partially covers return format, the description still fails to clarify usage nuances that an agent would need to invoke the tool correctly.
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%. The description does not explain the 'fields' parameter, which controls which details are returned. Paper_ids is self-explanatory from the description, but the optional 'fields' parameter is ambiguous and could mean different things (e.g., field names for filtering, response fields, etc.). The description adds no additional meaning beyond the bare 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 'Get', the resource 'papers', and the batch scope 'up to 500 at once' with a list of paper IDs. This differentiates it from the singular get_paper and search-oriented siblings like 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?
The description implies when to use this tool: when you have multiple paper IDs and need details in a single call. It doesn't explicitly name alternatives or exclusions, but the batch context is clear enough for an agent to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get details' and does not mention read-only nature, error conditions, authentication requirements, rate limits, or any side effects. For a GET tool with zero annotation coverage, more 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 a single, tightly worded sentence that front-loads the core action and resource. No wasted words, and it is appropriately sized for the tool's simplicity.
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?
The tool is a simple single-author lookup, and an output schema exists (though not shown), so return values need no explanation. However, the description lacks guidance on the 'fields' parameter and does not provide alternatives or exclusions, leaving some ambiguity for an agent choosing among similar tools. It is a minimal but not fully complete description.
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 explains the required parameter 'author_id' (identified by author ID), but completely omits the optional 'fields' parameter, whose purpose (likely field selection) remains ambiguous. Only half of the parameters receive semantic explanation.
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 'Get details about a single author identified by their Semantic Scholar author ID' – a specific verb ('Get'), resource ('details about a single author'), and identifier ('Semantic Scholar author ID'). This distinguishes it from siblings like get_author_papers (papers of an author) and search_authors (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?
The description implies clear usage context: you need an author ID to call this tool. It does not explicitly name alternative tools for when you lack the ID, but the condition is evident. This meets 'clear context, no exclusions' but falls short of explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral transparency. It only states that it 'gets details' but does not disclose potential behaviors like error handling, authentication requirements, or the effect of the 'fields' parameter on the response. The supported ID types offer marginal behavioral context but are primarily parameter semantics.
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, well-structured sentence that front-loads the core purpose and supported ID types. It contains no fluff or redundancy, earning a high score for conciseness.
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?
The description covers the basic purpose and ID types, and an output schema exists to explain return values. However, it lacks important context for the 'fields' parameter and does not differentiate this tool from sibling tools in terms of usage. For a simple retrieval tool, it is minimally adequate but has clear 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?
The input schema has 0% description coverage, so the description must compensate. It clarifies that paper_id can be a Semantic Scholar ID, DOI, arXiv ID, or other external ID, which adds meaning. However, the 'fields' parameter is entirely unexplained, and the description does not fully cover what the parameters do or their valid values.
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 details for a single paper using a variety of supported ID types. It distinguishes itself from sibling tools like get_paper_authors and search_papers by specifying the resource and scope precisely.
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 the tool: when you have an ID (Semantic Scholar, DOI, arXiv, etc.) and want the paper's details. However, it does not explicitly mention alternatives or exclusions, such as using get_paper_authors for author-specific 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?
No annotations are provided, so the description carries the burden. It clearly indicates a non-destructive suggestion behavior, but it does not disclose additional traits like result limits, case sensitivity, or that it only matches titles. For a simple read-only tool, this is acceptable 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 a single concise sentence that is front-loaded with the core action and resource. Every word adds value, with no unnecessary detail or repetition.
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 string parameter) and the existence of an output schema, the description is adequately complete. It states the purpose and input format clearly. The only missing context is explicit guidance on differentiation from similar tools, but that is a usage guideline issue rather than 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?
The schema provides only the parameter name 'query' with no description. The description adds meaning by clarifying that it is a 'partial query string', which is essential for understanding the input. This compensates for the 0% 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 clearly states the tool's function with a specific verb ('Suggest'), resource ('paper title completions'), and input ('partial query string'). It distinguishes itself from sibling tools like search_papers by focusing on autocomplete rather than full-text search.
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 user has a partial query and needs title completions, but it does not explicitly contrast with alternatives or state when not to use it. With many sibling tools, explicit differentiation would be helpful, but the purpose is clear enough to infer 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?
With no annotations, the description carries full burden. It discloses key behavioral traits: the 1000-paper limit, lack of relevance ranking, and continuation-token pagination. These are valuable beyond the tool's name. It does not mention error handling or permissions, but for a read-only search tool, this is adequate.
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, well-structured sentence. It front-loads the primary purpose ('Bulk paper search') and efficiently packs key details (limit, ranking, pagination) without wasted words.
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?
The tool has 8 parameters and no annotations, but an output schema exists. The description covers the tool's unique behavior (bulk, no ranking, pagination) but leaves parameter semantics mostly unaddressed and does not clarify how it relates to search_papers. Given the complexity, this is adequate but with notable 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 only explains the 'token' parameter's purpose (continuation for paging). The other seven parameters (query, year, venue, fields, fields_of_study, publication_types, sort) receive no semantic explanation. Parameter names are somewhat self-explanatory, but the lack of guidance on formats or allowed values leaves 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 the tool's function: 'Bulk paper search' with specific capabilities (up to 1000 papers, no relevance ranking, continuation token). This distinguishes it from sibling tools like search_papers (which likely returns ranked, smaller sets) and get_papers_batch (which retrieves by IDs). The verb 'search' and resource 'papers' are explicit.
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: use when you need bulk results without ranking and with pagination. It implies a use case for large-scale retrieval but does not explicitly mention when not to use it or name alternative tools. This is clear context without explicit exclusions, fitting 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:

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

Score Badge

Copy to your README.md:

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

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