Loading ToolBench
This server has critical definition quality issues across all three tools. Tool names lack action verbs (add, multiply, elon_add are weak), parameter descriptions are completely missing (null values in schema), descriptions are extremely brief (8-23 chars, well below the 34-char p10 baseline), and input/output schemas are undocumented. The elon_add tool returns random nonsensical values, violating idempotency and determinism requirements. No error handling, validation, or recovery guidance is present. All tools are trivially simple arithmetic operations without composition or chaining potential.
Add two numbers
Elon Addition Method
Multiply two numbers
All parameter descriptions are null. LLMs cannot infer that 'a' and 'b' are addends vs sum vs operands.
No input schema documented in source. While fastmcp likely auto-infers type hints (int, int), the schema is not explicitly visible in the code and cannot be verified from the repository.
Descriptions are under 20 characters. 'Add two numbers' (14 chars), 'Multiply two numbers' (20 chars), 'Elon Addition Method' (19 chars) are too brief. Baselines show p10=34 chars; these fail to meet minimum.
elon_add violates idempotency and determinism. It returns random.choice([420, 69]), which means the same input produces different outputs on every call. Agents cannot rely on this for planning or retry logic. Violates pattern:idempotent-operation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 25 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
Tool names lack action verbs. 'add', 'multiply', 'elon_add' do not follow verb_noun convention (e.g., 'calculate_sum', 'calculate_product'). While 'add' and 'multiply' are borderline acceptable as verbs in math context, they are weak and conflict with naming guidelines requiring clarity and specificity. 'elon_add' is particularly opaque to an LLM encountering it for the first time.
No output schema documented. Tools return int, but no description tells LLMs what the returned int represents, how to use it downstream, or what edge cases exist (e.g., integer overflow, division by zero for multiply).
No error handling or validation. Negative numbers, zero, very large integers are not described or validated. No guidance on what happens if inputs are out of range. No recovery instructions for LLMs.
No tool composition or chaining. Tools are isolated arithmetic operations with no integration points. No 'next logical action' fields in responses. No cross-references between tools.