Loading ToolBench
MCP server providing tools for writing, researching, and content assembly workflows
This server has critical gaps in definition quality across multiple dimensions. While all 6 tools are explicitly registered with names and descriptions, the schemas lack proper type constraints, most parameters are under-described, and error handling is minimal. Tool naming generally follows verb-noun convention (wiki_search, save_txt, writer_tool, review_tool, assemble_content, arxiv_search), but descriptions are superficial (10-80 chars), and parameter descriptions are missing or trivial. The save_txt tool exhibits a dangerous pattern: it calls an LLM (gpt-5-nano, which does not exist in OpenAI's API) without validation, could fail silently, and appends to files without proper error recovery. Output schemas are not documented. The server would fail code review on security, composability, and error guidance grounds.
Search arxiv for the given query on topics such as science, math, engineering, etc.
Assamble written content into one coherent written piece
Reviews written content and provides updated content with improvements
Save text to a .txt file
Search wikipedia for the given query and returns a summary.
Writes content on a given topic
Missing parameter type constraints and descriptions. 'sentences' param in wiki_search has no min/max bounds; 'content' params in writer_tool, review_tool, and assemble_content lack guidance on expected length or format. LLMs will hallucinate unbounded text sizes.
save_txt tool calls non-existent LLM model 'gpt-5-nano' without error handling or validation. This will always fail at runtime. The tool description ('Save text to a .txt file') contradicts its implementation (which calls an LLM to format content). This is misleading to agents.
No output schemas documented. Tools return untyped strings (e.g., wiki_search, writer_tool, review_tool, assemble_content). LLMs cannot plan downstream calls or extract structured data. This violates the 'return structured objects' pattern.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Minimal error recovery guidance. Exception handlers in wiki_search return generic strings like 'An error occurred: {e}'. LLMs receive no actionable recovery path, no suggestion to try a different query or alternative tool.
Tool descriptions are too brief (10 - 80 chars), below the 194-char average for production tools. 'Save text to a .txt file' (24 chars) does not explain when to use it, what it returns, or that it calls an LLM. Descriptions do not answer: What does it do? When should the LLM call it? What does it return?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). save_txt is clearly destructive (appends to files) but carries no annotation. LLMs cannot determine which tools are safe to retry or compose without side effects.
Parameter descriptions missing or trivial. 'content' param in save_txt: no description. 'content' in writer_tool, review_tool, assemble_content: no descriptions. 'query' param in arxiv_search: no description. LLMs cannot infer what values are expected.
No composition support for batch operations. Tools like writer_tool and review_tool operate on single strings. If an agent needs to process 10 items, it must call the tool 10 times, wasting tokens and latency. No batch variants offered.
Idempotency not guaranteed. save_txt appends to a file without checking if content already exists. Repeated calls with identical input produce duplicate entries. Agents should not retry this tool, but no guidance is provided.