This server has severe definition quality issues across both tools. While the tools are explicitly registered with Zod schemas in src/index.ts, they suffer from critically incomplete descriptions and undocumented parameters. The 'add' tool has a trivial 18-char description ('Simple addition tool') that provides no context on when to use it vs 'calculate'. Both tools have parameters (a, b, operation) with null descriptions in the schema inspection output, meaning LLMs receive no guidance on parameter purpose, constraints, or expected formats. The Zod schemas provide type information (number, string enum) but the parameter descriptions are completely absent from the actual tool registration calls. Error handling is minimal, the 'calculate' tool returns a text error for division by zero rather than structured error guidance that would help an LLM retry or self-correct. There is no output schema documentation, pagination, or guidance on result structure. The tools lack any idempotency hints, readonly markers, or acknowledgment of their side-effect-free READ_ONLY nature. Composition is poor: 'add' duplicates the 'add' operation within 'calculate', creating tool redundancy that wastes LLM reasoning cycles.

• Add Zod description metadata to every parameter. Replace `z.number()` with `z.number().describe('The first operand (a numeric value)')` for each numeric parameter. For 'operation' enum, use `.describe('The arithmetic operation to perform: add|subtract|multiply|divide')` to document constraints.
• Expand tool descriptions to 80 - 150 chars each. For 'calculate': 'Performs arithmetic operations (add, subtract, multiply, divide) on two numbers. Use instead of add() when you need operations beyond addition.' For 'add': 'Adds two numbers together. Equivalent to calculate with operation=add. Use only if you need a simple addition without selecting an operation.'
• Document the output schema explicitly. Define a response structure like { result: number } and mention it in the tool description: 'Returns an object with a numeric result field.'
• Remove the 'add' tool entirely. It is redundant with calculate's add operation. Let calculate be the single canonical tool for all arithmetic, reducing LLM confusion.
• Implement structured error responses for division by zero. Return { error: { code: 'DIVISION_BY_ZERO', message: 'Cannot divide by zero', guidance: 'Ensure the divisor (b) is non-zero before calling this tool.' } } instead of a plain text error string.
• Add tool annotations: declare both tools as readonly/idempotent via tool registration metadata (if the MCP framework supports it) or document these properties in the description.
• Consider adding a validate step: check that inputs are finite numbers (not Infinity or NaN) and return actionable errors if validation fails.