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 50-200 char LLM-optimized baseline. Parameter descriptions are present but terse (12-18 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), so limited real-world applicability, but the definition quality issues would be critical in a production domain.
Adds two numbers together
Tool description is 23 characters, below LLM-optimized baseline (50-200 chars). Lacks context on when to use, what it returns, and any prerequisites.
Output schema not documented. Response structure (content array with text type) is inferred from code but not declared in tool metadata. LLMs cannot plan downstream calls without knowing return fields.
Parameter descriptions are terse (12-18 chars). 'First number to add' and 'Second number to add' lack format hints, range constraints, or type clarification beyond the schema.
No error handling guidance. Tool does not document what happens on invalid input (non-numeric, NaN, Infinity), how to recover, or whether errors are retryable.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Tool is read-only but lacks idempotent hint annotation. Even trivial tools benefit from explicit idempotency declaration for agent retry logic.