Loading ToolBench
MCP server with OAuth 2.0 authentication provider running on Cloudflare Workers, demonstrating remote authorization flows
Single tool 'add' has a clear verb-noun name and basic schema with typed parameters. However, the description is extremely minimal (22 chars), barely meeting the 10-char floor. 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 security considerations. The tool is trivial (arithmetic), so complexity is low, but the definition lacks the rigor expected of production tools. Baseline: 194 chars for tool descriptions (p10=34, p90=392); this server is at the p10 floor. 100% of A+ tools document return types; this one does not.
Adds two numbers together
Tool description is 22 characters, below the recommended 50-200 char range for LLM optimization. 'Adds two numbers together' lacks context on when to use it, what it returns, or any prerequisites.
Output schema is not documented. The tool returns {content: [{type: 'text', text: string}]} but this structure is not declared in the tool definition. LLMs cannot plan downstream calls or validate responses without explicit output documentation.
Parameter descriptions are minimal (12-13 chars each). 'First number to add' and 'Second number to add' lack format hints, range constraints, or examples. Baseline: 72 chars average for param annotations.
No error handling guidance. What happens if inputs are NaN, Infinity, or non-numeric? No recovery hints or validation rules documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Tool is marked READ_ONLY but has no idempotentHint or other tool annotations in the schema. Modern MCP servers should declare idempotency and destructiveness via annotations.