Loading ToolBench
Remote MCP server with OAuth 2.0 authorization provider for Cloudflare Workers, exposing MCP tools via SSE transport
The server defines a single tool 'add' with minimal quality. The tool has a valid JSON Schema with properly typed parameters (both numbers), but lacks critical descriptions. The tool itself has no description explaining what it does, when to use it, or what it returns. Both input parameters 'a' and 'b' have null descriptions, violating the pattern:tool-description requirement that every parameter needs a non-empty description explaining what it controls. The tool performs a simple arithmetic operation (addition) but provides no context about return format or output schema. This is a minimal proof-of-concept implementation lacking production-grade documentation.
Adds two numbers together
Tool 'add' has no description. LLMs cannot determine when to select this tool or what it does without explicit documentation.
All input parameters lack descriptions. Parameter 'a' and 'b' both have null descriptions, making it impossible for LLMs to understand what values represent or why they're needed.
Tool name 'add' is generic and does not follow verb_noun convention. A better name would be 'add_numbers' to clarify the operation and match production naming standards (avg tool name 18 chars).
No output schema documented. The tool returns {content: [{type: 'text', text: string}]} but this structure is not documented for the LLM, forcing it to guess what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 6 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 28 | - | v1 |
No error handling or recovery guidance. If the operation fails (e.g., invalid input types), there is no error classification or guidance for the LLM on what to do next.