Allows interaction with Semantic Scholar's public APIs, providing tools for searching and retrieving academic papers, authors, citations, references, recommendations, and dataset releases.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@semanticscholar-mcp-server Find recent open-access papers about retrieval-augmented generation."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An unofficial, community-maintained toolkit for the public Semantic Scholar APIs: a Model Context Protocol server, two CLIs, and two independently installable agent skills.
Version 2.3.0 provides 20 endpoint-aligned operations, two backward-compatible operations, a schema-driven endpoint CLI, an evidence-oriented ScholarQA CLI, and separate skills for endpoint routing and research synthesis.
This project is not affiliated with or endorsed by Semantic Scholar or the Allen Institute for AI. API availability, terms, and rate limits are controlled by Semantic Scholar.
Language-model agents often understand the research task but call the wrong API surface. Typical failures include using generic paper search for an exact-title lookup, treating autocomplete as evidence, confusing recommendations with citation edges, inventing unsupported endpoint names, or sending fields and pagination parameters to operations that do not accept them.
Raw REST documentation leaves endpoint selection, argument construction, and response handling to the model. This project separates those concerns into composable layers:
MCP server: exposes typed tool schemas directly to MCP-capable clients.
Endpoint CLI: lets shell-based agents inspect and call those same 22 operations with validated JSON.
ScholarQA CLI: collects auditable multi-query evidence bundles and batch-verifies citations without embedding an LLM provider.
Two agent skills: one teaches exact endpoint routing; the other teaches attributed evidence synthesis and research ideation.
The endpoint MCP and CLI share the same FastMCP definitions. The ScholarQA CLI uses the same direct API client but adds a bounded evidence workflow. Skills contain agent instructions, not another API implementation.
Related MCP server: McpDeepResearch
The similarly named CLI and skill are deliberately separate:
Layer | Runtime | Optional skill | Purpose |
Endpoint access |
|
| Select and call an exact API operation, including citations, references, recommendations, and datasets. |
Research QA |
|
| Retrieve complementary evidence, build a claim ledger, synthesize multiple papers, and verify final citations. |
Common combinations:
Goal | Install |
Give an MCP-capable agent typed Semantic Scholar tools | MCP runtime only |
Let a shell agent make exact endpoint calls |
|
Let a shell agent perform evidence-first literature QA |
|
Perform research QA through MCP | MCP runtime + |
Add graph traversal or endpoint-level control to shell QA | Both CLIs + both skills |
Neither skill requires the other. The Python package installs all three executables, so one package can support any runtime combination. npx skills installs only the selected skill instructions.
scholarqa-cli intentionally stops at model-free evidence collection and citation verification. The agent using $scholarqa-research performs the reasoning and prose synthesis, so the CLI does not require a second model API key or hide unsupported claims inside an opaque generation step.
Broad API coverage: authors, papers, citations, references, full-text snippets, recommendations, and dataset releases.
No Semantic Scholar SDK dependency: the server uses a small asynchronous httpx client and depends only on mcp and httpx.
Native responses: endpoint-aligned tools preserve Semantic Scholar's JSON response shape instead of converting it into a reduced local model.
Explicit pagination: callers control offsets or continuation tokens; the server never silently crawls an unbounded result set.
Rate-limit aware: HTTP 429 and transient 5xx responses use Retry-After when available and bounded exponential backoff otherwise.
Shared endpoint contract: MCP and semanticscholar-cli use the same tool names, schemas, validation, and API client.
Auditable QA bundles: scholarqa-cli records queries, filters, raw results, candidate IDs, partial failures, and evidence-level guidance.
Agent-ready skills: semantic-scholar-cli provides strict endpoint routing, while scholarqa-research provides attributed, evidence-first synthesis and ideation.
Installable distribution: the release ZIP installs semanticscholar-mcp, semanticscholar-cli, and scholarqa-cli.
Offline tests: the test suite uses an in-memory HTTP transport and does not consume Semantic Scholar API quota.
Python 3.10 or later
An MCP client that supports stdio servers, if using the MCP transport
Optional: a Semantic Scholar API key for a dedicated rate limit
Anonymous requests work for many endpoints, but they use a heavily shared rate limit.
Send the following entire message to your coding agent rather than only its first line. It deliberately requires the agent to ask which form you want before changing your environment:
Install this Semantic Scholar MCP / CLI / skill toolkit for me:
https://github.com/XWang20/semanticscholar-MCP-Server
Before making any changes, first ask me which form I want:
1. MCP server
2. semanticscholar-cli (exact endpoint CLI)
3. scholarqa-cli (evidence collection and citation verification CLI)
4. semantic-scholar-cli skill (endpoint routing instructions)
5. scholarqa-research skill (research QA and ideation instructions)
6. a combination of these components
Do not choose for me and do not begin installation until I answer. After I answer,
detect whether you are running in Codex or Claude Code, follow the repository README,
ask whether the installation should be project-local or global when relevant, explain any
runtime a selected skill needs, and verify the selected components without exposing or
committing an API key.中文版本：
为我安装这个 Semantic Scholar MCP / CLI / skill 工具集：
https://github.com/XWang20/semanticscholar-MCP-Server
开始任何更改之前，先问我要安装哪一种形式：
1. MCP server
2. semanticscholar-cli（精确端点 CLI）
3. scholarqa-cli（证据收集与引用核验 CLI）
4. semantic-scholar-cli skill（端点路由指令）
5. scholarqa-research skill（研究问答与研究构思指令）
6. 这些组件的组合
不要替我选择，也不要在我回答前开始安装。得到确认后，再判断你当前运行在
Codex 还是 Claude Code 中；按照仓库 README 安装；如果涉及安装范围，再询问
是项目级还是全局安装；说明所选 skill 需要的 runtime；最后验证所选组件，
并且不要泄露或提交 API key。python -m venv .venv
source .venv/bin/activate
python -m pip install ./semanticscholar-mcp-server-2.3.0.zipThe package installs all three entry points:
semanticscholar-mcp
semanticscholar-cli tools
scholarqa-cli --helppython -m venv .venv
source .venv/bin/activate
python -m pip install -e .You can then use the console entry points above or run a module directly:
python semantic_scholar_server.py
python scholarqa_cli.py --helpOn Windows PowerShell, activate the environment with .venv\Scripts\Activate.ps1.
semanticscholar-cliThe CLI intentionally does not invent a second set of friendly-but-different command names. It exposes the same 22 operation names and JSON schemas as MCP.
List operations:
semanticscholar-cli tools
semanticscholar-cli tools --jsonInspect one operation before calling it:
semanticscholar-cli schema search_semantic_scholar_papersCall an operation with a JSON object:
semanticscholar-cli call search_semantic_scholar_papers \
--params '{"query":"retrieval augmented generation","open_access_pdf":true,"limit":5}'For larger inputs, use --params-file params.json or --params - to read JSON from stdin. Add --compact for single-line output.
Endpoint CLI exit statuses are designed for agents and scripts:
Status | Meaning |
| Successful operation. |
| The operation returned a top-level API |
| Invalid CLI input, schema mismatch, or unknown operation. |
| Interrupted by the user. |
scholarqa-cliThe ScholarQA CLI prepares evidence for an agent; it does not generate a final answer. collect runs complementary snippet and paper searches for each query and emits one JSON bundle:
scholarqa-cli collect "Does retrieval-augmented generation reduce factual errors?" \
--query "retrieval augmented generation factuality evaluation" \
--query "RAG hallucination benchmark" \
--year "2020-" > evidence.jsonAfter the agent selects the papers that support its material claims, verify their canonical records:
scholarqa-cli verify ARXIV:2005.11401 DOI:10.1145/3786335.3813161 \
> verified.jsonIDs can also be provided as a JSON array or one ID per line with --ids-file FILE; use --ids-file - for stdin. Show the methodology sources and adaptation boundary with:
scholarqa-cli provenanceFor collect, status 0 means all searches succeeded, status 1 means the JSON bundle contains usable partial results plus operation_errors, and status 2 means invalid input or a local failure. For verify, status 0 means every ID resolved and status 1 means at least one ID was unresolved or the upstream batch request failed. Both commands use 130 for interruption.
The repository contains two Agent Skills-compatible skills. They can be installed and used separately:
Skill | Best paired runtime | Purpose |
| Select the exact Semantic Scholar operation and construct valid parameters. | |
| Perform evidence-first multi-paper synthesis, citation verification, and Scideator-style facet ideation. |
scholarqa-cli and scholarqa-research form an independent Semantic Scholar adaptation, not the official Ai2 Scholar QA implementation. The evidence-QA workflow credits the Ai2 Scholar QA paper and official allenai/ai2-scholarqa-lib repository. The ideation workflow credits the Scideator paper. See the skill's provenance reference and third-party notices for scope, licenses, and adaptation boundaries. No upstream ScholarQA code or runtime dependency is bundled.
npx skillsList the available skills:
npx skills add XWang20/semanticscholar-MCP-Server --listInstall either skill for the current project; the installer detects supported agents:
npx skills add XWang20/semanticscholar-MCP-Server \
--skill semantic-scholar-cli
npx skills add XWang20/semanticscholar-MCP-Server \
--skill scholarqa-researchInstall both together:
npx skills add XWang20/semanticscholar-MCP-Server \
--skill semantic-scholar-cli --skill scholarqa-researchOr install either skill globally for a specific agent:
# Codex
npx skills add XWang20/semanticscholar-MCP-Server \
--skill scholarqa-research --global --agent codex
# Claude Code
npx skills add XWang20/semanticscholar-MCP-Server \
--skill scholarqa-research --global --agent claude-codenpx skills installs skill instructions only. It does not install the Python package or configure an MCP client. Install the Python package when the endpoint skill needs semanticscholar-cli, or when the research skill will use scholarqa-cli. The research skill may instead use an already configured MCP runtime.
Extract the standalone skill ZIP into the appropriate global skills directory, or copy the source directory directly:
# Codex
unzip semantic-scholar-cli-skill-1.1.0.zip -d ~/.codex/skills
unzip scholarqa-research-1.1.0.zip -d ~/.codex/skills
# Claude Code
unzip semantic-scholar-cli-skill-1.1.0.zip -d ~/.claude/skills
unzip scholarqa-research-1.1.0.zip -d ~/.claude/skills
# Or, from a source checkout (Codex examples):
cp -R skills/semantic-scholar-cli ~/.codex/skills/
cp -R skills/scholarqa-research ~/.codex/skills/Invoke a skill explicitly, for example:
Use $semantic-scholar-cli to find recent open-access papers about retrieval-augmented generation and verify the final paper records.
Use $scholarqa-research to synthesize the evidence for whether retrieval-augmented generation reduces factual errors, with verified citations and limitations.semantic-scholar-cli expects semanticscholar-cli and can use python semantic_scholar_cli.py during local development. scholarqa-research can use either scholarqa-cli (python scholarqa_cli.py in a checkout) or the connected MCP server. Install both skills only when the task benefits from both high-level research synthesis and low-level endpoint control.
After installing the package, configure your MCP client with the absolute path to the virtual environment's console script:
{
"mcpServers": {
"semanticscholar": {
"command": "/absolute/path/to/.venv/bin/semanticscholar-mcp",
"env": {
"SEMANTIC_SCHOLAR_API_KEY": "your-optional-api-key"
}
}
}
}For a source checkout without package installation:
{
"mcpServers": {
"semanticscholar": {
"command": "/absolute/path/to/.venv/bin/python",
"args": ["/absolute/path/to/semantic_scholar_server.py"],
"env": {
"SEMANTIC_SCHOLAR_API_KEY": "your-optional-api-key"
}
}
}
}Do not commit an API key to an MCP configuration stored in a public repository. Prefer your client's secret or environment-variable mechanism when available.
Once the MCP server, CLI, or corresponding skills are available, an assistant can handle requests such as:
“Find recent open-access papers about retrieval-augmented generation.”
“Resolve this DOI and return its references with citation contexts.”
“Recommend papers similar to these two papers but unlike this negative example.”
“Search full-text snippets for evidence about calibration in scientific QA.”
“List the datasets in the latest Semantic Scholar dataset release.”
“Synthesize the evidence across these papers, cite every material claim, and surface disagreements.”
“Generate facet-grounded research ideas from these seed papers, then check novelty against retrieved literature.”
The exact natural-language workflow depends on the agent. MCP exposes typed tools, semanticscholar-cli exposes the same endpoint schemas to shell agents, and scholarqa-cli packages evidence for the research skill to synthesize.
Environment variable | Default | Description |
| unset | Sent to Semantic Scholar as the |
|
| Request timeout in seconds. |
|
| Retries for HTTP 429 and transient 5xx responses. |
|
| API origin override, primarily for tests and compatible proxies. |
WhenSEMANTIC_SCHOLAR_API_URL is overridden, the API key is sent to that origin. Only use an endpoint you trust.
MCP/CLI operation | REST operation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Paper search exposes publication type, open-access, minimum citation count, publication date/year, venue, and field-of-study filters. Bulk search uses token pagination and supports sorting. Citation and reference tools can request citation contexts, intents, context/intent pairs, and influential-citation status.
MCP/CLI operation | REST operation |
|
|
|
|
Single-paper recommendations support the recent and all-cs pools. Multi-paper recommendations accept positive and optional negative paper IDs. The API returns at most 500 recommendations per request.
MCP/CLI operation | REST operation |
|
|
|
|
|
|
|
|
Dataset tools return release metadata and temporary download URLs. They do not automatically download multi-gigabyte datasets. The identifier latest is accepted wherever the upstream API supports it.
Two tool names are retained for clients built against the original project:
MCP/CLI operation | Behavior |
| Returns only the paper result list from the first relevance-search request. |
| Returns the first page of both relationships. |
New integrations should use the endpoint-aligned search, citation, and reference tools because they expose filters, fields, and independent pagination.
Paper tools accept identifiers supported by Semantic Scholar, including:
Semantic Scholar paper ID
CorpusId:
DOI:
ARXIV:
ACL:
MAG:
PMID: and PMCID:
supported Semantic Scholar paper URLs
Most tools accept a fields list. Useful paper fields include abstract, authors, externalIds, openAccessPdf, tldr, journal, citationStyles, s2FieldsOfStudy, and embedding.
Default field sets are intentionally rich but exclude the large embedding vector. Request it explicitly when needed:
{
"paper_id": "ARXIV:2005.11401",
"fields": ["paperId", "title", "embedding"]
}Offset-paginated tools return only the requested page.
Bulk paper search returns the upstream continuation token; pass it back to request the next page.
The server honors Retry-After for throttled responses and otherwise uses bounded exponential backoff.
Validation, upstream HTTP, and unexpected transport failures are returned as {"error": "..."} so one failed request does not terminate the MCP server.
The CLI prints the same normalized JSON and returns a nonzero exit status for API or schema errors.
A successful empty result is returned unchanged and is not converted into an error.
Semantic Scholar can change limits or schemas independently of this project. Consult the official API documentation when an upstream validation rule differs from the server's current defaults.
Queries, identifiers, filters, and requested fields are sent to the configured Semantic Scholar API origin.
The API key is used only as the x-api-key request header.
The server does not persist API responses, maintain a paper database, or automatically download dataset files.
Avoid placing secrets in prompts, search queries, logs, issues, or public MCP configuration files.
Dataset download URLs can be temporary and should be treated accordingly.
If you discover a security issue, do not publish credentials or exploit details in a public issue. Use the repository owner's private security-reporting channel; if none is listed, open a minimal issue requesting private contact without disclosing the vulnerability.
Create a development environment and install the project in editable mode:
python -m venv .venv
source .venv/bin/activate
python -m pip install -e .Run the complete test suite:
python -m unittest discover -vThe tests use httpx.MockTransport; they do not call the live Semantic Scholar API or consume rate-limit quota.
semantic_scholar_api.py Async HTTP client, validation, retries, and API paths
semantic_scholar_cli.py Schema inspection and JSON command-line dispatch
semantic_scholar_server.py FastMCP server and 22 registered tools
scholarqa_cli.py Evidence-bundle collection and citation verification
skills/semantic-scholar-cli/ Endpoint-routing skill for shell-based agents
skills/scholarqa-research/ Attributed evidence synthesis and ideation skill
tests/ Offline API, CLI, and tool-registration tests
pyproject.toml Package metadata and three console entry points
requirements.txt Minimal runtime dependencies
THIRD_PARTY_NOTICES.md ScholarQA and Scideator attribution boundariesContributions are welcome. A change should:
Preserve the upstream JSON response shape for endpoint-aligned tools.
Keep pagination explicit and bounded.
Add or update offline tests for endpoint paths, parameters, payloads, CLI behavior, and tool registration.
Avoid adding a heavyweight API SDK when the direct client can support the operation clearly.
Never include API keys, generated bytecode, virtual environments, or large downloaded datasets.
Run python -m unittest discover -v before opening a pull request.
For new upstream endpoints, update the client method, MCP tool, tool-registration test, skill routing reference, and this catalog together. The CLI discovers the MCP schema automatically and should not maintain a separate endpoint registry.
Version 2 is a substantial rewrite and expansion of JackKuo666/semanticscholar-MCP-Server. It replaces the original SDK-backed runtime with a direct asynchronous API client, expands coverage from four tools to 22, preserves native responses, and adds pagination, retry handling, tests, and packaging.
The two original high-level tool names listed under backward compatibility remain available so existing clients can migrate gradually. Repository history and this attribution are retained in recognition of the original work.
Distributed under the MIT License.
Research workflows and adapted third-party material retain their original attribution and license boundaries as documented in THIRD_PARTY_NOTICES.md. In particular, this repository does not relicense or claim authorship of Ai2 Scholar QA or Scideator.
“Semantic Scholar” is used only to identify compatibility with the public service. This project does not claim ownership of the Semantic Scholar name, API, data, or trademarks.
Suggest paper-title query completions for a partial query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states the core action and does not disclose any side effects, authentication needs, rate limits, or the nature of the response. The description 'Suggest... completions' is minimal and assumes read-only behavior without stating it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It front-loads the essential information about what the tool does and the condition under which it operates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema, the description covers the basic purpose and parameter meaning. However, it lacks any guidance on when to use this tool versus alternatives and does not disclose behavioral expectations such as whether it is read-only or any limitations. Thus, it is minimally sufficient but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'query' with no description (0% coverage). The description adds the qualifier 'partial query', which clarifies that the input should be a partial paper-title string. This provides some meaning beyond the schema, but it does not elaborate on format or constraints, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Suggest' with a clear resource 'paper-title query completions' and scoping condition 'for a partial query'. This clearly distinguishes it from sibling search tools like search_semantic_scholar_papers, which return full results rather than completions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for partial queries needing completions, but it does not explicitly state when to use this tool over alternatives or provide any exclusion criteria. There is no mention of related search tools or when autocomplete would be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get multiple authors by Semantic Scholar author ID (maximum 1,000).
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| author_ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must disclose behavior. It only states a maximum of 1,000 IDs, but fails to mention read-only nature, rate limits, error behavior, or what happens with invalid IDs. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the action and limit. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (covering return values), the description lacks essential context such as allowed field values, prerequisites, and when to choose this batch tool over alternatives. For a tool with no annotations and zero param descriptions, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Because schema description coverage is 0%, the description must explain parameters. It clarifies that author_ids are Semantic Scholar author IDs, but this is largely redundant with the parameter name. The optional 'fields' parameter is completely unexplained, leaving the agent to guess what values it accepts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Get'), resource ('authors'), method ('by Semantic Scholar author ID'), and scope ('multiple', max 1,000). Distinguishes from single-author and paper batch tools by explicitly limiting to authors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus alternatives like get_semantic_scholar_author_details or batch_get_semantic_scholar_papers. The only implied usage is that it is for multiple author IDs, but no exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get multiple papers by S2, CorpusId, DOI, arXiv, ACL, MAG, PMID, or URL ID.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| paper_ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only mentions what the tool does, not rate limits, batch size limits, error handling for invalid IDs, or read-only status. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource, then efficiently enumerates supported ID types. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with an output schema and two parameters. The description covers the core purpose and ID types, but lacks usage guidance, behavioral details, and clarity about the fields parameter. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It helpfully clarifies the paper_ids parameter by listing accepted ID formats (S2, CorpusId, DOI, etc.), but the fields parameter is entirely unexplained, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get multiple papers' with a specific list of supported ID types. This distinguishes it from single-paper retrieval and search tools, and the 'batch' in the name reinforces the multi-item scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have multiple paper IDs to fetch at once, but it does not explicitly specify when to use this tool versus alternatives like get_semantic_scholar_paper_details or search tools. No exclusions or alternative comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run high-volume paper search; pass the returned token for the next page.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| year | No | ||
| query | Yes | ||
| token | No | ||
| venue | No | ||
| fields | No | ||
| fields_of_study | No | ||
| open_access_pdf | No | ||
| publication_types | No | ||
| min_citation_count | No | ||
| publication_date_or_year | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the pagination mechanism (passing the token) and the high-volume nature, but omits details like rate limits, response format expectations, or any constraints around bulk usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and a key operational detail. It contains no filler or redundancy, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no annotations, and zero schema descriptions, the description is too minimal. It covers the high-level purpose and pagination, but a complex bulk search tool with many optional filters needs more contextual guidance to be used effectively, even though the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are 11 parameters. The description only gives meaning to 'token' (returned token for next page) but does not explain query, sort, year, venue, fields, or other parameters. This is insufficient compensation for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Run high-volume paper search') on a specific resource (Semantic Scholar papers). It also distinguishes this bulk variant from sibling search tools by emphasizing high-volume operation and pagination via a returned token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for high-volume, paginated searches by mentioning 'high-volume' and 'pass the returned token for the next page', but it does not explicitly state when to choose this tool over regular search_semantic_scholar_papers or provide exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one author by Semantic Scholar author ID.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| author_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the basic read operation but omits any details about response shape, error behavior, or required fields. Minimal behavioral context beyond the trivial 'get' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no superfluous words. It is concise without being a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with an output schema, the description is minimally adequate but lacks guidance on when to use it over siblings and the meaning of the 'fields' parameter. The output schema covers return structure, but the description provides no extra context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only clarifies the 'author_id' parameter ('by Semantic Scholar author ID'). The optional 'fields' parameter is not explained, and the description adds no additional semantics beyond what the schema's types already show.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('one author by Semantic Scholar author ID'), clearly distinguishing it from batch retrieval and search tools. It precisely states the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific author ID and need a single author's details, but it does not explicitly contrast with alternatives like search or batch tools, nor mention 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.
List an author's papers, optionally filtering by publication date/year.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| fields | No | ||
| offset | No | ||
| author_id | Yes | ||
| publication_date_or_year | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 core action ('List') and filtering option, but does not mention pagination behavior, field selection, ID format, or any requirements/constraints. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It conveys the core action and the optional filter efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 under-specifies a tool with five parameters, no annotations, and no schema descriptions. It does not explain how to obtain author_id, what fields can be requested, or how pagination works, making it minimally viable only for the simplest invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 by explaining parameters. It only hints at publication_date_or_year via 'optionally filtering by publication date/year', but says nothing about author_id, limit, offset, or fields. This is insufficient for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('an author's papers'), clearly distinguishing it from sibling tools like get_semantic_scholar_author_details or search_semantic_scholar_papers. It also notes the optional filtering by publication date/year, adding useful scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when you need to enumerate an author's papers, optionally filtered by date. However, it does not explicitly mention when not to use it or name alternative tools for related tasks, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy helper returning the first page of citations and references.
| Name | Required | Description | Default |
|---|---|---|---|
| paper_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It discloses that the tool is a legacy helper and returns only the first page, which is important for setting expectations. However, it does not mention the output structure, whether it combines citations and references or returns them separately, or any other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that successfully conveys the main purpose and key limitations. It is efficiently written with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential fact that this is a legacy first-page-only helper, but given the existence of separate citations and references tools, it could clarify when to use this combined one. The output schema exists but the description doesn't explain whether both types of results are included in the same response structure. Still, for a simple legacy tool, the description is adequately short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a single required parameter 'paper_id' with no description, and the description does not explain what format it should be in or how to obtain it. This leaves the agent without guidance on how to fill the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: returning the first page of citations and references for a paper. The term 'Legacy helper' distinguishes it from more modern or comprehensive sibling tools like get_semantic_scholar_paper_citations and get_semantic_scholar_paper_references. However, it could be clearer about whether it returns both in one structure or as separate items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this is a legacy tool, suggesting it may not be the preferred option, but does not explicitly name alternatives or provide conditions for when to use it. It notes that only the first page is returned, which warns against using it for full data retrieval, but does not say 'use X instead'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get incremental update/delete files between two dataset releases.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_name | Yes | ||
| end_release_id | Yes | ||
| start_release_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only says 'Get incremental update/delete files' but does not disclose return format, pagination, authentication needs, or whether it returns metadata or file contents. This is minimal and leaves the agent guessing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is efficiently written, though it sacrifices valuable context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 required parameters, no annotations) and the existence of an output schema, the description is too sparse. It does not clarify what 'diffs' entail, how releases are identified, or what the caller can expect from the result. The agent would need to rely on parameter names and possibly external knowledge to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description mentions 'two dataset releases' which hints at start_release_id and end_release_id, but it does not explain dataset_name or the expected format/range of releases. Parameter names are self-explanatory, but the description adds very little beyond what the schema already exposes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('incremental update/delete files between two dataset releases'), which distinguishes it from sibling tools like get_semantic_scholar_dataset_release or get_semantic_scholar_dataset_download_links. It is immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no prerequisites, and no exclusions. It simply states what it does without contextual hints about appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get temporary download links for one dataset in a release.
| Name | Required | Description | Default |
|---|---|---|---|
| release_id | Yes | ||
| dataset_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose that the links are 'temporary,' which is a useful behavioral trait, but it does not specify expiry duration, access requirements, or other behavioral nuances. This adds some value but falls short of rich transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose without extraneous words. Every word contributes meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface with two parameters and an output schema, so the description need not elaborate on return values. However, it lacks context on how to discover valid release_id/dataset_name values, what 'temporary' implies operationally, and when to prefer this over sibling tools. Thus it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 additional parameter semantics beyond the parameter names themselves. While release_id and dataset_name are fairly self-explanatory, the description does not clarify formats, sources, or relationships (e.g., that dataset_name belongs to the given release), so it 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'temporary download links for one dataset in a release,' identifying exactly what the tool does. It also distinguishes itself from sibling tools like get_semantic_scholar_dataset_release and get_semantic_scholar_dataset_diffs by focusing on download links for a single dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The implied usage is that this tool is for obtaining download links for a dataset within a release, but it provides no explicit guidance on when to use it versus alternatives, prerequisites (e.g., knowing the release_id), or when not to use it. The context from sibling names suggests differentiation but the description itself does not state it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List datasets and metadata in a release; latest is accepted.
| Name | Required | Description | Default |
|---|---|---|---|
| release_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates a read-only listing operation and adds the behavioral detail that 'latest' is accepted. However, it omits any mention of potential pagination, rate limits, or large payloads, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with an inline code reference for 'latest'. Every word is purposeful; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description is sufficiently complete for selection and invocation. It covers the essential choice of release (including the 'latest' shorthand) and the action. Omitting details already addressed by the output schema or sibling tools is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaningful parameter semantics by noting that `release_id` accepts the special value 'latest', which is not in the schema. Still, it does not describe typical release ID formats or how to obtain them, partially mitigating the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource: datasets and metadata within a release. It distinguishes itself from siblings like list_semantic_scholar_dataset_releases by focusing on contents of a specific release, and the inline note about 'latest' adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: with a release_id to list its datasets. It does not explicitly name alternatives, but the context of sibling tools makes the distinction apparent. There are no exclusions, so it is clear but lacks explicit 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.
List the authors of a paper with offset pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| fields | No | ||
| offset | No | ||
| paper_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds only 'offset pagination' as a behavioral detail, but fails to disclose anything about safety, rate limits, default field behavior, or response structure beyond what the output schema already provides. Minimal behavioral insight is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the primary purpose and notes pagination. There is no redundant wording or unnecessary filler, though its brevity does limit the amount of useful information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters and a custom output schema, the description is too sparse. It omits crucial context such as the expected paper_id format, the meaning of 'fields', and pagination corner cases. Even though an output schema exists, the description fails to provide the operational context an agent needs to select and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, but it does not explain any of the four parameters (paper_id, limit, offset, fields). The mention of 'offset pagination' is generic and does not clarify the semantics of 'fields' or the required 'paper_id' format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List the authors of a paper') and clearly distinguishes itself from sibling tools like get_semantic_scholar_paper_details or get_semantic_scholar_author_details. The scope is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or when a different sibling tool would be more appropriate, leaving the agent without clear decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List papers citing a paper, including contexts, intents, and influence.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| fields | No | ||
| offset | No | ||
| paper_id | Yes | ||
| publication_date_or_year | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context about returned content (contexts, intents, influence) but omits details like pagination behavior, rate limits, or what 'influence' means. It's not misleading, just incomplete for a tool without any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core action and high-value response features. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 0% schema coverage, and no annotations, the description is too sparse. An output schema exists but is not visible in the context, so relying on it for completeness is risky. The description provides the basic purpose but leaves parameter usage, alternatives, and behavioral nuances unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, but it doesn't explain any parameter. The mention of 'contexts, intents, and influence' hints at possible fields for the `fields` parameter, but `publication_date_or_year` and pagination parameters are left entirely ambiguous. Minimal added meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' and clearly states the resource: papers citing a given paper. It also highlights key included elements (contexts, intents, influence), distinguishing it from sibling tools that retrieve references rather than citations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to see citing papers), but it doesn't explicitly state when not to use it or provide comparisons with sibling tools like get_semantic_scholar_citations_and_references or get_semantic_scholar_paper_references. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one paper by S2, CorpusId, DOI, arXiv, ACL, MAG, PMID, or URL ID.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| paper_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the accepted identifier formats, which is important behavioral detail. However, it omits any mention of error behavior, required encoding, or availability of an output schema, leaving some opacity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and resource. Every word contributes, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are covered. However, the fields parameter is left unexplained, and the description doesn't clarify differences among the ID types or any prerequisites. It is adequate for basic invocation but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description must explain parameters. It effectively explains paper_id by listing the ID types it accepts, but it completely ignores the optional 'fields' parameter, leaving its semantics (e.g., what field names are allowed) undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets one paper and enumerates the accepted identifier types (S2, CorpusId, DOI, arXiv, ACL, MAG, PMID, URL ID). This sharply distinguishes it from sibling tools like batch_get_semantic_scholar_papers or search_semantic_scholar_papers, which handle multiple papers or use queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Get one paper' implies a specific use case: retrieving a single paper by its ID. This gives clear context for when to invoke the tool and implicitly excludes bulk retrieval, though it doesn't explicitly name alternatives like batch_get_semantic_scholar_papers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a paper's references, including contexts, intents, and influence.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| fields | No | ||
| offset | No | ||
| paper_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds value by mentioning that references include contexts, intents, and influence, offering insight into returned data. However, it does not disclose pagination behavior, authentication needs, or rate limits, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence provides clear information without fluff. It efficiently communicates the core purpose and key inclusions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description is incomplete for a 4-parameter tool. It lacks usage guidance, parameter explanations, and explicit behavioral caveats. The existence of related sibling tools like get_semantic_scholar_citations_and_references makes the missing guidance more noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 implicitly identifies paper_id as the target paper, but fails to explain limit, offset, and fields parameters. The output schema exists but does not help parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists a paper's references and specifies included content (contexts, intents, influence). The verb 'List' and resource 'paper's references' are specific, and the name distinguishes it from related tools like citations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need a paper's references, use this tool. However, it does not explicitly mention when not to use it or alternatives like get_semantic_scholar_paper_citations or get_semantic_scholar_citations_and_references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Semantic Scholar dataset release IDs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation by using 'list', which is transparent about the non-destructive nature, but it does not explicitly state return behavior beyond 'release IDs' or mention any potential rate limits or formatting details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that precisely states the tool's function. Every word contributes meaning, with no fluff or repetition. It is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter simplicity and the presence of an output schema, the description is mostly complete. It specifies the primary output (release IDs) and indicates enumeration of all available releases. However, it could slightly benefit from noting that this is a listing operation to precede other dataset tools, but that is a minor enhancement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially 100% covered. The baseline for 0 params is 4, and the description appropriately avoids padding with irrelevant parameter details. It adds no parameter-specific meaning because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('Semantic Scholar dataset release IDs'), making it easy to understand. It distinguishes itself from sibling tools like 'get_semantic_scholar_dataset_release' by indicating it enumerates all available IDs, though it does not explicitly reference these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor does it mention any prerequisites or context. It simply states what it does, leaving the agent to infer that it should be used to obtain release IDs before fetching specific releases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the paper whose title best matches a supplied title.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| query | Yes | ||
| venue | No | ||
| fields | No | ||
| fields_of_study | No | ||
| open_access_pdf | No | ||
| publication_types | No | ||
| min_citation_count | No | ||
| publication_date_or_year | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It only states that the tool finds the best matching paper, but does not disclose how matching works (e.g., fuzzy vs exact), whether it returns null if no match, how filters affect the match, or any potential side effects (though likely read-only). This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, directly stating the core purpose. However, given the tool's 9 parameters, this brevity borders on under-specification, though it remains efficiently structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a rich schema (9 parameters) and sibling tools that differentiate among search/match/get operations, but the description gives no context on return value, filter behavior, or edge cases. It is complete only for a trivial tool and does not meet the needs of an agent selecting among closely related Semantic Scholar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only clarifies that the 'query' parameter is the 'supplied title'; all other parameters (year, venue, fields, fields_of_study, open_access_pdf, publication_types, min_citation_count, publication_date_or_year) receive no explanation beyond their schema names. With 0% schema description coverage, the description fails to compensate for the missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Find' with resource 'paper' and specifies the matching criterion ('whose title best matches a supplied title'). This clearly distinguishes it from search tools (which return multiple results) and get-details tools (which take an ID), giving it a specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the user has a title and wants the best-matching paper, but it does not explicitly state when to use this tool over search_semantic_scholar_papers or batch_get_semantic_scholar_papers, nor does it mention exclusions or alternative tools. Thus, usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend papers from positive examples and optional negative examples.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| fields | No | ||
| negative_paper_ids | No | ||
| positive_paper_ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool uses positive examples and optional negative examples to generate recommendations, which adds context beyond the tool name. However, it does not disclose any other behavioral traits such as rate limits, authentication requirements, or how negative examples influence the output. Since no annotations are provided, the description carries the full burden but only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets straight to the point. It uses no unnecessary words and is well-structured, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists to describe return values, the description is too sparse for a tool with four parameters and a specific recommendation mechanism. It does not clarify the role of 'limit' and 'fields', nor does it provide any usage context. An agent would need to infer parameter meanings solely from names, which may be insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions positive and negative examples, which loosely map to positive_paper_ids and negative_paper_ids, but it does not explain the 'limit' or 'fields' parameters. Schema description coverage is 0%, and the description adds minimal meaning beyond what the parameter names already convey. It fails to compensate for the missing descriptions of the optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to recommend papers based on positive examples and optionally negative examples. It uses a specific verb 'recommend' and specifies the input resource, distinguishing it from sibling tools like search or get details, and even from 'recommend_semantic_scholar_papers_for_paper' which implies a single paper input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 or the other recommendation tool. It does not mention typical use cases, prerequisites, or situations where this tool would be preferred over others. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend papers similar to one positive example paper.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| fields | No | ||
| paper_id | Yes | ||
| pool_from | No | recent |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states the core function and gives no insight into how similarity is computed, whether any modifications occur, or what the response structure entails beyond the output schema. Minimal indication that this is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded and free of filler. However, it is so minimal that it borders on under-specification, though it does effectively communicate the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no annotations, and an output schema, the description is insufficient. It omits key context about how parameters like pool_from and fields affect behavior, and does not explain the recommendation criteria or any preconditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters. 'paper_id' is implicitly linked to 'one positive example paper', but limit, fields, and pool_from are entirely unexplained, leaving the agent without necessary parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recommends papers similar to one positive example paper, using a specific verb ('Recommend') and resource ('papers'), and distinguishes itself from the sibling tool 'recommend_semantic_scholar_papers' by specifying 'one positive example paper'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives like search or the batch recommendation tool. The intended usage is only implied by the phrase 'similar to one positive example paper', with no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legacy paper search returning only the result list.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| num_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states it returns a result list, which implies a limited read-only operation, but does not disclose pagination, result format, or why it is 'legacy'. The description adds minimal behavioral context beyond what the tool name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that is front-loaded with the key action ('Legacy paper search'). It avoids fluff, but it is so brief that it leaves out necessary details. Still, for what it contains, it is well-structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params) but lacks annotations and has a vague description. It does not explain what 'result list' means, how it differs from search_semantic_scholar_papers, or provide any guidance on when the legacy version is appropriate. An output schema exists but its content is not visible here, so the description must cover more ground than it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for parameter meaning, but it does not. The schema itself clearly defines 'query' and 'num_results' with types and defaults, but the description adds no additional semantics or usage context for these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a paper search with the verb 'search' and resource 'paper', and adds that it returns 'only the result list'. This distinguishes it from more comprehensive sibling tools like search_semantic_scholar_papers, though it doesn't explicitly explain what the result list contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The word 'legacy' hints that it may be deprecated, but there is no explicit recommendation to prefer search_semantic_scholar_papers or another sibling. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search authors by name, with offset pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| fields | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions offset pagination but does not disclose whether authentication is needed, rate limits, sorting behavior, or what constitutes a match (e.g., exact vs fuzzy). This is minimal transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the primary purpose and includes the key pagination detail, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no annotations, the description is too sparse to fully support correct usage. While an output schema exists, the description does not explain the meaning of 'fields', when to use this over sibling tools, or any constraints like result limits or error conditions. The context is incomplete for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the query is an author name and indicates offset/limit pagination. However, the 'fields' parameter remains completely unexplained, leaving a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for authors by name, using a specific verb and resource. It distinguishes itself from sibling tools like batch_get_semantic_scholar_authors and get_semantic_scholar_author_details by focusing on name-based searching with pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for name-based author searches but does not explicitly mention when to use it over alternatives such as batch_get_semantic_scholar_authors or autocomplete tools. No exclusions or alternative recommendations are provided, leaving usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run relevance-ranked paper search with filters and offset pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| limit | No | ||
| query | Yes | ||
| venue | No | ||
| fields | No | ||
| offset | No | ||
| fields_of_study | No | ||
| open_access_pdf | No | ||
| publication_types | No | ||
| min_citation_count | No | ||
| publication_date_or_year | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add value by disclosing that results are relevance-ranked and that offset pagination is supported, which are behavioral traits beyond the raw schema. However, it omits any mention of return format, error conditions, or rate limits, which are important for a search tool. This 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the tool's purpose and key capabilities. Every word contributes, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, this is a complex tool with 11 parameters, and the description does not explain how to use them effectively. It omits important context like how filters interact, what venue/publication_types accept, and pagination limits. The description is too sparse for an agent to make informed parameter choices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, but it does not. It merely mentions 'filters' without explaining any of the 11 parameters (e.g., year, venue, fields_of_study, min_citation_count). This provides no additional meaning over the schema's bare titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a relevance-ranked search for papers, which is a specific verb+resource. It distinguishes from sibling tools like author or snippet search by explicitly mentioning 'paper search'. However, it does not name any alternatives, so it misses the full distinguishing power of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 batch_get_semantic_scholar_papers or search_semantic_scholar. The description only says what it does, not when to prefer it over siblings, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search relevant passages from paper titles, abstracts, and full text.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| limit | No | ||
| query | Yes | ||
| venue | No | ||
| fields | No | ||
| authors | No | ||
| paper_ids | No | ||
| fields_of_study | No | ||
| inserted_before | No | ||
| min_citation_count | No | ||
| publication_date_or_year | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states the search action and source fields, but does not mention output format, pagination, result structure, or any limitations. The existence of an output schema partially covers return values, but the description adds no behavioral details beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and object. It has no filler, and every word contributes to stating the tool's purpose. For a tool of this complexity, brevity is positive, though it comes at the cost of missing details noted in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no annotations, no schema descriptions), the description is inadequate. While the output schema exists and covers return values, the description does not explain how the search works, what filters are available, or how to construct a query. It provides only the bare minimum context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 11 parameters with 0% description coverage, yet the description does not explain any parameters. It merely mentions the fields searched (titles, abstracts, full text), which does not map to specific parameters like venue, authors, or min_citation_count. The description fails to compensate for the lack of schema descriptions, leaving the agent to guess parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('search') and resource ('relevant passages from paper titles, abstracts, and full text'). This distinguishes it from sibling tools like search_semantic_scholar_papers, which search for papers rather than passages. The scope of search is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for finding passages within papers, but it does not explicitly state when to use it over sibling tools like search_semantic_scholar_papers or search_semantic_scholar. No exclusions or alternative recommendations are provided. The usage context is only implied by the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.3.0autocomplete_semantic_scholar_papersbatch_get_semantic_scholar_authorsbatch_get_semantic_scholar_papersbulk_search_semantic_scholar_papersget_semantic_scholar_author_detailsget_semantic_scholar_author_papersget_semantic_scholar_citations_and_referencesget_semantic_scholar_dataset_diffsget_semantic_scholar_dataset_download_linksget_semantic_scholar_dataset_releaseget_semantic_scholar_paper_authorsget_semantic_scholar_paper_citationsget_semantic_scholar_paper_detailsget_semantic_scholar_paper_referenceslist_semantic_scholar_dataset_releasesmatch_semantic_scholar_paperrecommend_semantic_scholar_papersrecommend_semantic_scholar_papers_for_papersearch_semantic_scholarsearch_semantic_scholar_authorssearch_semantic_scholar_paperssearch_semantic_scholar_snippetsThe tools are mostly distinct but there are overlapping pairs: the two recommendation tools differ only by one accepting negative examples, and the legacy tools (search_semantic_scholar, get_semantic_scholar_citations_and_references) duplicate existing search and citation/reference functionality. Descriptions help clarify, but an agent could easily pick the wrong tool.
All tools share the 'semantic_scholar' prefix, but the verb patterns are inconsistent: autocomplete, batch_get, search, bulk_search, match, recommend, list, and get are used in various orders and forms. Object naming also varies (author, author_details, author_papers, paper_details, papers), and the two legacy tools break the pattern entirely.
22 tools is on the heavy side, within the 16-25 borderline range. The server covers multiple subdomains (papers, authors, datasets, recommendations, snippets), so the count is defensible, but redundant legacy tools and overlapping recommendation helpers inflate it unnecessarily.
The tool set provides broad coverage of the Semantic Scholar API: paper and author search/retrieval, citations/references, recommendations, dataset access, and snippet search. Minor gaps exist—such as no direct tool for getting author citations or a more explicit 'get paper by DOI' separate from batch/get—but the core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/XWang20/semanticscholar-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
