This server has severe definition quality issues. All three tools lack parameter descriptions (required by pattern:tool-description), making them unsuitable for LLM-driven tool selection. Tool names are simple mathematical operations without clear action verbs that establish context. Parameter schemas are present with types (float, string) but completely lack descriptions, a critical gap that prevents LLMs from understanding what 'a' and 'b' represent or why they matter. Tool descriptions are extremely brief (10-32 characters), below the actionable baseline of 50-200 chars. No output schemas are documented. No error handling guidance. The server reads as a basic tutorial implementation rather than production-ready tooling.

• Add comprehensive parameter descriptions to every parameter. For 'add' and 'multiply': describe what 'a' and 'b' represent (e.g., 'First operand (numeric value to be added/multiplied)' and 'Second operand (numeric value to be added/multiplied)'). For 'echo': describe 'message' (e.g., 'The text string to be echoed back unchanged').
• Expand tool descriptions to 50-200 characters and include usage context. Example for 'add': 'Adds two numeric values and returns their sum. Use this for arithmetic operations requiring addition. Returns a float.' Current: 27 chars.
• Declare output schemas explicitly in tool metadata. Each tool should state: 'Returns: float (numeric result)' or 'Returns: string (echoed message)'.
• Rename tools to follow verb_noun convention: 'add' → 'calculate_sum', 'multiply' → 'calculate_product', 'echo' → 'repeat_message'. This clarifies intent for LLM tool selection.
• Add parameter constraints and type hints in descriptions. For numeric tools, specify range or precision if applicable (e.g., 'Must be a valid float between -1e6 and 1e6').
• Implement error handling with actionable guidance. If type conversion fails, return: 'Error: parameter "a" must be numeric (e.g., 3.14 or -5). Received: [actual_value]'.