Loading ToolBench
MCP server demonstration with RSQL lineage conversion and basic arithmetic tools
This server contains only 1 tool (add_numbers) with a minimal, trivial definition. The tool does basic integer arithmetic with no practical utility for agent-driven workflows. While the schema is technically present with proper JSON Schema structure and type definitions, the tool lacks meaningful context for agentic selection. The description 'Adds two numbers.' is only 18 characters, below the 34-char p10 baseline for production tools, providing no context about when or why an LLM should invoke this tool. There are no error handling patterns, no idempotency guarantees, and no composition guidance. The server appears to be a proof-of-concept or tutorial example rather than a production-grade tool. The repository structure (rsql_lineage_app.py, gradio UI code) suggests this is a demo application that happens to expose one trivial MCP tool, not a focused tool service.
Adds two numbers.
Tool description is trivially short (18 chars). 'Adds two numbers.' provides no agentic context: no WHEN to call it, no composition hints, no error cases, no prerequisites. Production baseline is 34-392 chars with explicit guidance on selection and recovery.
Tool name 'add_numbers' is generic and lacks clear agentic intent. Verb-noun naming (perform_arithmetic_sum, compute_sum) would be clearer. Current name does not distinguish this from a math library function vs. an agent-orchestrated operation.
No error handling. What happens if non-integer inputs are passed? What if the sum overflows? No recovery guidance for the agent. Pattern: recovery-guide.
No tool composition context. What downstream tools consume the result of add_numbers? Is the output used in further calculations or reporting? Agents need to understand the role of this tool in multi-step workflows.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Parameter descriptions are minimal ('First number', 'Second number'). Per pattern:tool-description, every parameter must explain WHAT it controls, expected formats, ranges, and constraints. A parameter 'a' leaves LLMs guessing about limits, negative handling, and precision.
No output schema documented. What is the return type of add_numbers? An integer? A float? A structured object with result and metadata? LLMs cannot plan downstream operations without knowing the response shape.
Single trivial tool. This server does not demonstrate real domain utility. A production MCP server should expose a coherent set of related tools (e.g., arithmetic operations: add, subtract, multiply, divide; or data transformation tools; or API integration tools). One toy tool suggests this is a tutorial, not a functional tool service.