Loading ToolBench
An MCP server that allows LLM's to use math formulas and operations!
This server has 2 tools with basic mathematical operations. Both tools have input schemas with proper typing (arrays of integers/numbers), and descriptions are present but generic. However, the definitions fall short of production quality: descriptions lack context about when to use each tool, parameter descriptions are minimal, there is no output schema documentation, error handling provides no recovery guidance, and there is no separation of concerns or composition patterns. The naming is acceptable but generic. Overall, this represents a below-average implementation that would require substantial refinement for production use.
Calculate the sum of a list of numbers. This endpoint takes a query parameter `q` which is a list of numbers and returns their sum.
Perform element-wise subtraction of two lists of numbers. This endpoint takes two query parameters, `q1` and `q2`, which are two lists of numbers. It performs element-wise subtraction (q1 - q2).
Descriptions lack LLM-optimized guidance. Both descriptions (95-110 chars) explain WHAT the tools do but not WHEN to use them or what distinguishes them from each other. Addition and subtraction descriptions do not clarify expected input constraints, error conditions, or output format. Per the rubric baseline, descriptions should be 10 - 1024 characters, preferably 50 - 200 chars with actionable context for LLM selection.
No documented output schema. Neither tool declares what the response structure will be. addition returns a scalar (float via np.sum()), and subtraction returns an array (via np.subtract()), but this is not documented in the tool definition. LLMs cannot plan downstream calls or validate results without knowing the output shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Parameter descriptions are too brief and lack constraints. The 'q' parameter in addition is described as 'A list of numbers (integers or floats) to be added together.' This omits: minimum/maximum list length, whether empty lists are allowed, numerical bounds, and rounding/precision expectations. Similarly, 'q1' and 'q2' in subtraction do not document whether the lists must be the same length (the implementation will error if they differ).
Error handling does not guide recovery. Both tools catch exceptions and wrap them in HTTPException(400, detail=f"{E}"), which will expose raw Python error messages (e.g., 'operands could not be broadcast together'). Per the rubric: 'Error responses must tell the LLM what to do next' and 'Include the invalid value and the constraint it violated.' Raw exceptions do not help an LLM self-correct. There is no categorization of errors as retryable, user-fixable, or fatal.
No tool composition or tool-chaining support. The server provides only two isolated mathematical operations. There is no mechanism for agents to chain operations (e.g., add two lists, then subtract the result from another), no batch variants to reduce sequential calls, and no guidance on what related tools exist.
Naming could be more descriptive. 'addition' and 'subtraction' are correct verb-noun pairs, but they do not follow the Arcade baseline pattern of verbs like get_, create_, search_, update_. More idiomatic names would be 'sum_numbers' (paralleling np.sum) or 'calculate_sum', and 'subtract_lists' or 'calculate_difference' for clarity. Current names are acceptable but generic.