Loading ToolBench
A Deno-based MCP server that integrates inference processing with tool execution and web search capabilities
Two tools with minimal documentation. Both lack comprehensive input schemas, detailed descriptions, and output schema documentation. 'add' has basic parameter descriptions but 'web_search' is vague. Neither tool has documented error handling, and neither follows verb_noun naming conventions clearly. The server uses Express with Streamable HTTP transport (good), but tool definitions fall short of production standards. Based on the rubric's 549-tool baseline (avg description 194 chars, 100% of A+ tools have documented params), these tools score in the D/C range.
Add two numbers together
Search query to find information on the web
web_search lacks output schema documentation. The tool description says 'Search query to find information on the web' but does not document what fields are returned (url, title, content, etc.) or their types. LLMs cannot plan downstream tool calls without knowing the response structure.
web_search description is only 57 characters ('Search query to find information on the web'), below the rubric's 10 - 1024 char guideline and far below the 194-char baseline. It does not state WHAT the tool returns, WHEN to use it vs other tools, or whether it has prerequisites (API keys). Add dependency hints: 'Returns search results from DuckDuckGo and Jina Reader, including URL, title, and content. Use this to find recent information on the web.'
Both tools lack documented error handling. The implementation has try-catch blocks (e.g. 'Search failed: ...'), but the tool definitions do not document what errors are possible, whether they are retryable, or how the LLM should recover. E.g., web_search can fail if Jina API is down or rate-limited, the LLM needs explicit recovery guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
add tool lacks minimum/maximum bounds on numeric parameters. The schema shows 'type: number' for both 'a' and 'b' but does not document valid ranges. Can 'a' and 'b' be negative? Decimals? Arbitrarily large? Unbounded numeric parameters let LLMs pass values that break APIs or cause unexpected behavior.
web_search implementation exposes a Jina API key in the source code (Bearer token in plain text). This is a critical security issue, credentials must never appear in source or tool parameters. Use environment variables or a vault to inject secrets server-side. Agent traces log all parameters; this key is now compromised.
add tool description ('Add two numbers together') is only 28 characters and lacks depth. It should clarify: Does it support decimals? Negative numbers? Large integers? What does it return (the sum as a number, or an object)? Current description is too generic and leaves ambiguity.
Neither tool documents their output schema. The code shows add() returns a result, and web_search() returns a JSON object with 'query', 'url', 'title', 'content', 'source' fields, but these are not documented in the tool definition. LLMs need to know the response shape to extract and chain values.