Single-tool server with basic implementation. Tool name follows verb_noun pattern ('get_square'), but description is minimal (8 words, 34 chars, below the 10-word minimum). Input schema is present with proper type (float) and parameter description ('The number to square'), meeting JSON Schema requirements. However, output schema is NOT documented anywhere in the codebase, tool returns a dict but LLMs have no contract for expected fields. No output documentation violates the 'Document the output schema' critical check. Error handling exists (try/except) but returns unstructured error text without recovery guidance. No pagination, no batching (not applicable here), no idempotent hints. The tool is READ_ONLY and stateless, which is correct, but the definition lacks the depth required for production use.

• Add full output schema documentation in the docstring or codebase: 'Returns a dict with keys: success (bool), number (float), square (float), and error (str if success=false).'
• Expand tool description to 50-100 chars with LLM-friendly language: 'Calculate the square of a numerical value. Useful for mathematical transformations. Returns both the input and result for verification. Accepts any float value.'
• Document parameter constraints in description: 'The number to square (any real number as float; returns result as float). Precision limited by floating-point representation.'
• Replace bare exception message with classified, actionable errors: return {success: false, error: 'Invalid input: number must be a valid float'} instead of str(e).
• Add input validation with clear error messages: if input is not a valid number, respond with 'Invalid input: expected a number (int or float), got {type(number).__name__}'.

Inferred effective spec: <=2025-11-25.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained