Loading ToolBench
MCP server with OAuth 2.0 authorization provider running on Cloudflare Workers, demonstrating remote authentication flows
Single tool 'add' has a basic schema with typed parameters (number, number) and minimal descriptions. Tool name lacks action verb (should be 'compute_sum' or 'add_numbers'). Description is only 28 characters, below the 50-200 char baseline for LLM-optimized descriptions. Parameter descriptions are present but generic ('First number to add', 'Second number to add'). No output schema documented. No error handling guidance. No pagination, composition, or idempotency considerations. This is a toy example, not production-grade.
Adds two numbers together
Tool name 'add' lacks action verb. Should start with verb (e.g., 'compute_sum', 'add_numbers') to help LLMs infer intent from the name alone.
Tool description is only 28 characters ('Adds two numbers together'). Baseline is 50-200 chars. Expand to explain WHEN to use it, WHAT it returns, and any constraints.
No output schema documented. LLMs cannot plan downstream calls or extract results without knowing the response structure (e.g., is it {result: number} or {sum: number, type: string}?).
No error handling guidance. What happens if inputs are NaN, Infinity, or null? How should the LLM recover?
Parameter descriptions are generic and do not specify constraints (e.g., range, precision, special values). LLMs cannot validate inputs without explicit bounds.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | 2026-07-28+ | v2 |