Loading ToolBench
A MCP server to search for accurate academic articles.
Server defines 3 tools with adequate naming and descriptions, but lacks key elements expected of production tools. All three tools follow verb-first naming (search-*), which is good. Descriptions are present and substantive (150-250 chars), meeting the 10-1024 character guideline. However, the tools have critical gaps: (1) parameter descriptions are minimal, all three tools accept only a single 'keyword' parameter with a 1-line description, violating the pattern that every parameter needs a clear explanation of format, constraints, and valid values; (2) output schemas are completely undocumented, tools return strings, but there is no documentation of what fields, structure, or format the string contains, making it impossible for LLMs to parse results reliably; (3) no error handling guidance, the code raises ValueError for empty keywords, but the tool descriptions do not explain error cases or recovery paths; (4) no pagination or limit information, the arXiv search hardcodes max_results=10 and Google Scholar uses MAX_RESULTS=10, but tool descriptions do not state this limit or explain what happens if results exceed it. The descriptions are clear about intent (search academic sources) but lack actionable constraints and output documentation needed for reliable LLM composition.
Search arxiv for articles related to the given keyword. Results are ranked by relevance, but arxiv returns best-effort matches for any query, so a result set may contain weak or unrelated papers. Judge each result on its own; do not treat the presence of results as proof that prior work exists.
Search google scholar for articles related to the given keyword.
Search Google for articles and web results related to the given keyword. Available when the SERPBASE_API_KEY environment variable is set; when it is not set, this tool is not registered.
Output schema completely undocumented. Tools return concatenated strings, but no description of expected format, structure, or parseable fields. LLMs cannot reliably extract data (e.g., paper titles, URLs) from unstructured output.
Parameter constraints not documented. 'keyword' parameter has a 1-line description but no guidance on minimum/maximum length, required format, or what constitutes a valid query. arxiv_search.py hardcodes max_results=10, but this limit is not exposed or documented in tool descriptions.
No error handling guidance. Tool descriptions do not explain what errors can occur (invalid keyword, API rate limit, service unavailable) or how the LLM should recover. Code raises ValueError for empty keywords, but this is not documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
No result limit or pagination documented. ArxivSearch defaults to max_results=10, but tool description does not state this. If an LLM expects 50 results and only gets 10, it may incorrectly infer that only 10 papers exist on the topic.
Output structure incompatible with tool chaining. Tools return newline-delimited multi-field strings ('Title: ...\nSummary: ...\nLinks: ...\nPDF URL: ...'). Downstream tools (if any) would need to parse this unstructured format. No structured object with typed fields (e.g., {title: str, summary: str, links: [str], pdf_url: str}).
google-web tool conditional registration not validated at startup. Tool description states it is 'Available when the SERPBASE_API_KEY environment variable is set' but the server provides no validation, capability report, or guidance if the key is missing. An LLM may attempt to call this tool only to discover at runtime that it is unavailable.