Single tool 'getFurigana' has a basic description (47 chars) and minimal parameter documentation. Input schema is present with type and description for the 'kanji' parameter, but output schema is not documented, LLMs cannot predict the List<String> return structure. No error handling guidance, no parameter constraints (e.g., single kanji vs multi-char strings), and no indication of when/why to use this tool beyond the bare description. Tool naming is acceptable (verb_noun pattern), but lacks context about what 'furigana' means to users unfamiliar with Japanese linguistics.

• Expand tool description to 100-150 chars: 'Get the list of possible furigana (phonetic readings) for a Japanese kanji character. Returns all known readings from the furigana.info database. Useful for language learning, text-to-speech, or understanding kanji pronunciation variants.'
• Document output schema explicitly: 'Returns a list of strings, each representing one valid furigana reading (e.g., ["みち", "どう", "い"]). Empty list if kanji not found or service unavailable.'
• Add input validation: constrain 'kanji' parameter to single Unicode characters in the CJK Unified Ideographs range (U+4E00 - U+9FFF). Add description: 'A single Japanese kanji character (e.g., "道"). Must be a valid CJK ideograph.'
• Implement explicit error handling: distinguish between 'kanji not found' (return empty list with note) and 'service error' (throw exception with retry guidance). Return structured error objects with actionable messages.
• Add HTTP/SSE transport support. Implement Streamable HTTP endpoint so the server can be deployed as a remote service and accessed by hosted MCP clients. STDIO-only limits adoption.