Loading ToolBench
A MCP server to search for accurate academic articles.
This server has critical gaps in definition quality. Both tools have minimal descriptions (under 50 chars), no parameter descriptions whatsoever, and missing output schema documentation. The schema for parameters is present but extremely sparse. Error handling is non-existent, the code raises ValueError with minimal context, giving LLMs no recovery guidance. The tool names are reasonable (verb + noun), but the definitions lack the depth required for reliable LLM selection and parameter reasoning.
Search arxiv for articles related to the given keyword.
Search google scholar for articles related to the given keyword.
Parameter 'keyword' lacks description. LLMs cannot infer whether to pass a single term, a phrase, or structured queries. No guidance on length, format, or examples.
Tool descriptions are too brief (under 50 chars each). 'Search arxiv for articles related to the given keyword' lacks context for when to use this tool vs search-google-scholar, what fields are returned, or any constraints on results.
No output schema documented. The server returns TextContent with concatenated article strings, but LLMs cannot parse the structure without knowing the field names, types, and formats of returned data.
Error handling is minimal and unhelpful. ValueError exceptions with bare messages like 'Unknown tool' or 'Missing keyword' give LLMs no recovery guidance. No categorization of errors as retryable or user-fixable.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
No pagination or result limits enforced. The code defaults max_results=10 and MAX_RESULTS=10, but these are hardcoded and not exposed to the LLM. If an API returns 10 results verbatim and they are very long, the context window could be exhausted.
Output format is free-text concatenation. Results are joined with '\n\n\n' into a single TextContent string. Structured output (array of objects with title, summary, url, pdf_url fields) would let LLMs extract data reliably without parsing heuristics.