The server defines 38 utility tools (datetime, encoding, math, string, hashing). Tool naming follows verb_noun convention generally well (timestamp, date_diff, format_date, base64_encode, etc.). Descriptions are present for most tools but vary significantly in quality and specificity. Parameter schemas are well-structured with types and enums where appropriate, but many math tools (add, subtract, multiply, etc.) lack visible descriptions and parameter documentation in the provided source. Output schemas are not documented, critical oversight for composition. Error handling is not evident in the tool definitions; there is errorReporting=true but no recovery guidance visible. The server lacks per-tool descriptions for ~16 math/utility tools and comprehensive output documentation.

• Add descriptions to all 20 undocumented math/utility tools. For each, state: WHAT it does (e.g., 'Computes the sine of a number in radians'), WHEN to use it (e.g., 'Use when you need trigonometric calculations'), and any prerequisites (e.g., 'Input must be a valid number'). Target 50 - 150 characters per description to balance clarity and token efficiency.
• Document output schemas for all tools. Example: 'timestamp() returns { timestamp: number, iso_string: string, date: string }' or 'add() returns { result: number, inputs: [number, number] }'. Include field types and meanings.
• For tools accepting 'value' parameters, suffix with the type (value_base64, value_urlencoded, value_timestamp) or rename to match the transformation (encode_string, timestamp_string). Alternatively, enhance descriptions with explicit format requirements: 'Timestamp as Unix seconds (integer) or ISO 8601 date string'.
• Add per-tool error guidance. Example for base_convert: 'Invalid base: must be an integer between 2 and 36. Provided: {base}. Did you mean base=10?' This enables LLM self-correction without wasted retry calls.
• Define parameter constraints for numeric tools: min/max ranges (e.g., base_convert: base 2 - 36), input types (string vs number), and optional defaults. Use JSON Schema minimum/maximum and enum to enforce constraints machine-readably.
• Add idempotency and side-effect hints. Math and encoding tools are READ_ONLY (safe); clarify that repeated calls with identical inputs always produce identical outputs. This helps agents safely retry on transient failures.