This is a simple arithmetic calculator MCP with 13 tools covering basic math operations. While tool schemas are properly defined via FastMCP decorators, the definitions have significant quality gaps: (1) Tool descriptions are extremely generic and lack decision-making context for LLMs (e.g., 'Add two numbers together' doesn't explain WHEN to use add vs other operations or differentiate it from similar tools). (2) Parameter descriptions are minimal, 'First number' and 'Second number' don't explain format, constraints, or ranges. (3) No output documentation or chaining IDs. (4) Multiple tools expose type inconsistencies: 'power', 'sqrt', 'cbrt', 'factorial', 'log', 'remainder', 'sin', 'cos', 'tan' accept 'int' parameters, but 'add', 'subtract', 'multiply', 'divide' accept 'float', this inconsistency is not explained and forces the LLM to reason about type coercion. (5) Error handling is minimal (only divide checks for zero; others lack bounds validation). (6) No tool annotations (readOnlyHint, etc.). (7) The single resource (greeting) is outside the scoring focus but shows the server can define multiple feature types. Overall, this reads like a tutorial/demo rather than a production-grade tool composition.

• Expand every tool description to 50 - 200 characters, including: WHAT the tool computes, WHEN an LLM should call it, any prerequisites (e.g., 'divide requires non-zero divisor'), and how the result is formatted. Example for divide: 'Divide the dividend by the divisor. Returns the quotient as a float (IEEE 754 double precision). Requires divisor != 0; provide non-zero value or call will fail. Use this when the user asks for division, ratios, or fractions.'
• Add range and constraint documentation to every parameter. Example: 'a (float): The dividend. Can be any finite number (positive, negative, or zero). Range: roughly ±1e308 (IEEE limits).' and 'b (float): The divisor. Must be non-zero. Passing zero will raise ValueError.'
• Align parameter types: decide whether the calculator is float-based or int-based, and apply consistently. If float is intended, update power(), sqrt(), cbrt(), factorial(), log(), remainder(), sin(), cos(), tan() to accept float and document the coercion. If int is intended, update add(), subtract(), multiply(), divide() to accept int and explain rounding behavior.
• Add input validation to all tools: factorial() should check a >= 0; log() should check a > 0; sqrt()/cbrt() should reject negative inputs explicitly with actionable error messages. Example: 'Cannot compute log of negative number. log() only accepts positive values. Received: -5. Pass abs(-5) = 5 or use a different operation.'
• Document return types and precision in tool descriptions. Example: 'sqrt() returns a float (IEEE 754 double, ~15 decimal digits precision). For inputs > 1e308, may return infinity. For non-perfect squares, result is approximate (e.g., sqrt(2) ≈ 1.414...).'