This server presents severe definition quality gaps. Both tools have minimal or missing descriptions (8-40 chars, well below the 10-1024 baseline). Parameter descriptions are entirely absent (null values in schema). The 'add' tool is redundant given the more general 'calculate' tool. While input schemas are technically present using Zod validators, they lack the descriptive metadata LLMs need for proper tool selection and error recovery. No error handling guidance is provided, the divide-by-zero case returns text instead of a structured error object with recovery steps. Output is unstructured text rather than typed JSON objects.

• Expand tool descriptions to 100 - 200 characters. Example for 'calculate': 'Performs arithmetic operations (add, subtract, multiply, divide) on two numbers. Use this for any numeric computation. Returns the numeric result or an error if division by zero is attempted.'
• Add descriptions for all parameters. For 'operation': 'The arithmetic operation to perform: add (addition), subtract (subtraction), multiply (multiplication), or divide (division).' For 'a' and 'b': 'First operand (numeric value)' and 'Second operand (numeric value)'.
• Document the output structure explicitly in the tool descriptions: 'Returns a JSON object with {result: <number>} on success, or {error: <string>, suggested_action: <string>} on failure.'
• Replace unstructured error text with structured objects: instead of 'Error: Cannot divide by zero', return {error: 'Division by zero', operation: 'divide', a: <value>, b: 0, suggested_action: 'Check divisor before calling divide operation'}.
• Remove the redundant 'add' tool. It serves no purpose the 'calculate' tool cannot handle. Reduces cognitive load on the LLM.
• Add constraints to numeric parameters if applicable. E.g., 'a and b must be finite numbers (not NaN or Infinity).' Include min/max bounds if the use case has them.
• Add examples to descriptions to clarify usage. E.g., 'calculate with operation=divide, a=10, b=2 returns 5.0'.