Loading ToolBench
MCP server with OAuth 2.0 authorization provider running on Cloudflare Workers, demonstrating remote authentication flows
Single tool 'add' has a clear verb-noun name and basic schema with typed parameters. However, the description is extremely minimal (23 chars), barely meeting the 10-char floor but well below the 194-char baseline for production tools. Parameter descriptions are present but terse (12-13 chars each). No output schema is documented, the response structure is inferred from code but not declared in tool metadata. No error handling guidance, no idempotency hints, no composition context. The tool is trivial (arithmetic) and lacks the depth expected of production-grade definitions.
Adds two numbers together
Tool description is 23 characters, below the 194-char baseline and lacks context on when/why to use it. Descriptions should state WHAT the tool does, WHEN to use it, and any prerequisites.
Output schema is not documented in tool metadata. LLMs cannot plan downstream calls or extract fields without knowing the response structure. Code shows text content response, but this must be declared in the tool definition.
Parameter descriptions are terse (12-13 chars each). 'First number to add' and 'Second number to add' are minimal; should explain format, range, and any constraints. Baseline is 72 chars per parameter.
No error handling guidance. If inputs are non-numeric or NaN, the tool should return actionable error messages telling the LLM what went wrong and how to recover.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Tool is trivial (arithmetic) and lacks composition context. No indication of when an agent should call this vs. other tools, or what downstream operations might follow. Real-world tools need richer metadata.