This server provides two mathematical evaluation tools with minimal but present definitions. Both tools have short, functional descriptions and proper JSON Schema input parameters. However, descriptions lack depth and context for LLM decision-making, parameter descriptions are minimal, output schemas are not documented, and there is no error handling guidance. The tool names are reasonably clear but lack the action-verb convention. The codebase shows a solid FastMCP foundation with proper server infrastructure, but the actual tool definitions fall short of production quality. The server is functional but would benefit from substantially richer descriptions, documented output schemas, error recovery guidance, and clearer parameter intent.

• Expand tool descriptions to 100-200 characters each, explicitly stating: what it does, when to use it (vs the other tool), supported expression types, and key limitations. Example: 'Evaluate symbolic and numeric mathematical expressions using SymPy. Best for symbolic algebra, calculus, and exact rational arithmetic. Slower but more precise than MathJS for complex expressions.'
• Document output schema for each tool. Specify what fields are returned (e.g., {'result': number, 'simplified': string, 'type': 'numeric|symbolic'}) and whether there are multiple return shapes for edge cases.
• Enhance the 'expression' parameter description to 80-120 characters, including format hints and constraints. Example: 'The mathematical expression as a string (e.g., "2*x + 3" or "sin(pi/4)"). Supports standard operators: +, -, *, /, **, ^. Variables must be defined or passed as parameters.'
• Add error handling and recovery guidance in tool descriptions or via a separate 'error handling' section. Document common failures: 'If expression contains undefined variables, wrap in lambdify() or provide a variable map. If timeout occurs, simplify the expression or use numerical approximation.'
• Rename tools to follow verb_noun convention: 'evaluate_expression_with_sympy' and 'evaluate_expression_with_mathjs'. This makes intent immediately clear and helps LLMs disambiguate.
• Add a comparison table or separate description field explaining when SymPy (symbolic, exact, slower) is preferred over MathJS (numeric, fast, approximate).