Three tools with complete schemas and descriptions, but significant gaps in parameter documentation and error handling. Tool names follow verb_noun convention (get_, humanize_). Descriptions are present (100-200 chars) and explain WHAT the tools do. However, many parameters lack descriptions (e.g., 'variants', 'benchmark_register', 'approximation' in humanize_number have no guidance on when/why to use them). No error handling guidance, no recovery paths, no validation rules documented. Output schemas are not formally documented, responses are inferred from code (model_dump()). The batch tool (humanize_fragments) is well-composed but lacks pagination/limit guidance for large fragment lists.

• Add descriptions to all parameters. For 'approximation', explain: 'Controls numeric rounding strength. Use "normal" for precise estimates, "rough" for colloquial approximations (e.g., "about 1 km" vs "1000 meters").' Similar guidance needed for 'system_preference', 'variants', 'benchmark_register'.
• Document output schemas explicitly. Add a 'Returns' section to each tool docstring listing field names, types, and meanings. E.g., humanize_number returns {variants: [str], source_language: str, output_language: str, ...}.
• Add error handling guidance. Document what happens on unsupported language, invalid text, or out-of-range parameters. Provide recovery hints: 'If language not supported, call get_humanumbers_support() to list available languages.'
• Add a max_fragments parameter to humanize_fragments with a default (e.g., 50) and document the limit in the description. This prevents runaway batch calls.
• Clarify the 'mode' parameter: 'Set to "humanize" to convert numbers to natural language. Set to "benchmark" to compare two numeric expressions (requires benchmark_text parameter).'