Loading ToolBench
MCP server for Semantic Scholar research workflows with stdio and Streamable HTTP transports. Provides access to the Semantic Scholar Academic Graph for searching papers, authors, and analyzing citation networks.
Server provides 9 well-structured tools for academic research via Semantic Scholar API. All tools have clear, descriptive names following the verb_noun pattern (search_papers, get_paper, match_paper, etc.). Descriptions are present and substantive (ranging 80-180 chars), explaining what each tool does. Input schemas are comprehensive with proper type definitions and parameter descriptions. However, output schemas are not documented in the source code, only input schemas are visible. Error handling guidance is absent; tools do not indicate what to do on failure or how to recover. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Parameter validation logic is not visible in the provided source excerpt, making it unclear whether constraints (min/max, enum validation) are enforced at runtime.
Get detailed information about a specific author by their ID.
Get all papers published by a specific author with pagination support.
Get detailed information about a specific paper by its ID (supports Semantic Scholar ID, DOI, arXiv, and other formats).
Get all citations of a specific paper, including the citing papers and citation contexts.
Get all references from a specific paper, including the referenced papers and reference contexts.
Get details for multiple papers at once using the /paper/batch endpoint. Automatically handles chunking for large batches.
Find a single paper that is the closest title match to the given query using the Semantic Scholar API.
Output schemas are not documented. LLMs cannot plan downstream tool calls or extract specific fields without knowing what the tools return. This forces agents to guess at response structure.
Tool annotations missing. Despite all 9 tools being read-only (no side effects), none declare readOnlyHint. Agents cannot distinguish safe tools from destructive ones, increasing caution and wasting reasoning cycles.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Search for authors using the Semantic Scholar API with support for pagination and field selection.
Search for papers using the Semantic Scholar API with support for filters like year range, venue, fields of study, and more.
No error handling guidance in tool descriptions. If a paper ID is invalid, API rate limits are exceeded, or the Semantic Scholar service is down, tools provide no recovery hints. LLMs cannot self-correct or suggest alternatives.
Parameter 'fields' (comma-separated list of fields to return) lacks guidance on valid options. LLMs will guess and may pass invalid field names, causing API errors. Should document available fields or provide an enum/link to documentation.
Pagination parameters (limit, offset) lack documented constraints. Min/max values are not stated (e.g., 'limit: max 100'). Without bounds, LLMs may request 1000+ results, wasting tokens and API quota.
No result count or pagination cursor in documented output. Tools accept 'limit' and 'offset' but no source indicates they return 'total' or 'next_offset'. LLMs cannot determine if more results exist without making another call and discovering empty results.