Single tool 'evaluate_batch' has a basic schema but critical gaps in descriptions. Tool description is minimal (27 chars, below 34-char p10 baseline). Parameter 'expressions' lacks description entirely, LLMs cannot infer what format strings should take (e.g., '2+2', '(3*4)/2', or raw tokens). No output schema documented; response structure is inferred from code only. No error handling guidance, division by zero and parse errors are handled internally but not communicated to the LLM. Tool naming is acceptable (verb_noun pattern) but descriptions fail the 10 - 1024 char and completeness bar.

• Add a detailed description to 'evaluate_batch': 'Evaluate an array of arithmetic expressions in parallel. Supports +, -, *, / with standard precedence, parentheses, decimals, and negatives. Returns per-expression success/failure with result or error message. Max 100 expressions per call. Use this to compute multiple calculations in one round-trip.'
• Add description to 'expressions' parameter: 'Array of arithmetic expressions as strings (e.g., ["2+2", "(3*4)/2", "10-5*2"]). Each expression is evaluated independently. Supports operators: +, -, *, / with standard precedence. Parentheses allowed. Max 100 expressions per call.'
• Document output schema in tool definition: 'Returns {"success": bool, "results": [{"expression": string, "result": number|null, "error": string|null, "success": bool}]}. Each result object contains the input expression, computed result (if successful), error message (if failed), and success flag.'
• Enhance error messages with recovery hints: Instead of 'Division by zero', return 'Division by zero in "10/0". Rewrite the expression to avoid division by zero, or use a different operation.'
• Add array size constraint: Limit 'expressions' to 1 - 100 items. Document in parameter description and validate in code with clear error message if exceeded.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry