Single tool server with significant quality gaps. The rational_calculator tool has a valid input schema with three parameters, but descriptions are inadequate for LLM selection and reasoning. Tool description is in Korean, making it inaccessible to most LLM systems. Parameter descriptions are minimal (e.g., 'Arithmetic operator' without specifying allowed values). No output schema documented. No error guidance provided. The tool wraps an external subprocess with minimal validation or recovery guidance.

• Rewrite tool description in English: 'Performs rational and integer arithmetic without loss of precision. Use for basic arithmetic operations and magnitude comparisons. Supports +, -, *, /, %, <, >, <=, >=, ==, !=.'
• Rename tool to 'calculate_rational' or 'compute_rational' to follow verb_noun pattern and signal action to LLM.
• Add enum constraint to 'operator' parameter: {"type": "string", "enum": ["+", "-", "*", "/", "%", "<", ">", "<=", ">=", "==", "!="], "description": "Arithmetic or comparison operator. Arithmetic: +, -, *, /, %. Comparison: <, >, <=, >=, ==, !=."}
• Update 'operand1' and 'operand2' descriptions: 'First operand as an integer (e.g., 5) or rational number in p/q notation (e.g., 3/4). Negative numbers supported.' Same for operand2.
• Document output schema in tool description: 'Returns the arithmetic result as a rational number (p/q) or integer, or a comparison result (true/false). String format.'
• Implement error recovery guidance. Catch errors from subprocess and map to actionable messages: if parsing fails, return 'Invalid operand format: expected integer or p/q notation (e.g., 3/4)'. If operator invalid, return 'Operator not supported. Valid: +, -, *, /, %, <, >, <=, >=, ==, !=.'
• Add examples in parameter descriptions (but NOT as enum fallbacks): 'e.g., 5 for integer, 3/4 for rational.' Then enforce via validation, not description text.