Loading ToolBench
Cal Server is a basic math and date utility tool with significant definition quality gaps. All 4 tools are properly registered with Zod schemas and descriptions, but several critical issues limit production readiness: (1) Parameter descriptions are absent, tools accept inputs with no guidance on constraints or expected formats. (2) Output schemas are not documented, forcing LLMs to infer what fields/types they receive. (3) Tool names lack action verbs, 'cal' and 'getNow' are ambiguous; verb_noun naming (evaluate_expression, get_current_timestamp) would be clearer. (4) No error handling guidance, what happens if the math expression is invalid? What's a valid timestamp range? (5) The batch tool returns inconsistent structure (TextContent array vs string for single calls), complicating composition. (6) Descriptions are generic and lack WHEN/WHY context that helps LLMs select tools.
Batch convert the provided list of timestamps to date format, used for processing multiple timestamps
Use the expr-eval library to evaluate the input mathematical expression and return the result. Constant Description E The value of Math.E from your JavaScript runtime PI The value of Math.PI from your JavaScript runtime true Logical true value false Logical false value
Convert the provided timestamp to date format
Get the current timestamp
Tool names lack action verbs and are ambiguous. 'cal' does not clearly indicate evaluation; 'getNow' uses camelCase instead of verb_noun convention. Names should be 'evaluate_expression', 'get_date_from_timestamp', 'batch_get_dates_from_timestamps', 'get_current_timestamp' to match LLM parsing expectations.
No parameter descriptions. All input parameters lack explanations: 'exp' (math expression) has no description of valid syntax, operators, or error cases. 'ts' and 'tsList' (timestamps) have no documentation of expected format (milliseconds? seconds?), range, or precision. This violates the requirement that every parameter must have a non-empty description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 14 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Output schemas are not documented. LLMs cannot plan downstream tool calls or extract fields if they don't know what the response structure is. Code shows: 'cal' returns a string (via String(calculate())), 'getDateByTimestamp' returns a string (locale string), 'batchGetDateByTimestamp' returns TextContent[], and 'getNow' returns a string (timestamp). These should be documented in tool descriptions or a separate output schema registry.
Inconsistent return types between single and batch operations. 'getDateByTimestamp' returns a plain string, while 'batchGetDateByTimestamp' returns {content: TextContent[]}. This inconsistency breaks composition, agents must handle different response structures for semantically similar operations.
No error handling or recovery guidance. What happens if 'exp' contains invalid syntax (e.g. '1 +++ 2')? Does the tool throw, return NaN, or return an error message? What if 'ts' is negative, beyond JavaScript's Date range, or a string? No error classification (retryable vs user-fixable vs fatal) guides agent behavior.
Tool descriptions are generic and lack context. The 'cal' tool description lists supported constants (E, PI, true, false) but doesn't explain when to use it vs alternatives, what expression syntax is valid (infix? prefix?), or what operators are supported (just +−*/ or also sin, cos, sqrt?). Descriptions should be 50 - 200 chars and state WHAT, WHEN, and WHY.
Timestamp format ambiguity. 'getDateByTimestamp' accepts 'ts' but does not specify whether it's milliseconds (JavaScript standard) or seconds (Unix epoch). The code uses 'new Date(ts).toLocaleString()' which expects milliseconds, but agents may pass seconds, causing off-by-1000 errors.