Four tools with complete schemas and descriptions in Japanese. All tools follow verb_noun naming (search_*, get_*). Descriptions are domain-specific and actionable (avg ~120 chars). Input schemas use Zod with proper types, enums, and constraints. However, output schemas are undocumented, responses are JSON-stringified without field documentation. Error handling returns raw exception messages rather than recovery guidance. No tool annotations (readOnlyHint, etc.). Parameter descriptions are good but lack explicit format/range guidance in some cases (e.g., 'via' array max=3 is in schema but not description text).

• Document output schemas for all tools. Define field names, types, and meanings. E.g., search_route returns { routes: [{ departure: string, arrival: string, fare: number, transfers: number, legs: [...] }], ... }. Include this in tool descriptions or a separate schema reference.
• Enhance error handling: catch exceptions, categorize as retryable/user-fixable/fatal, and return structured errors with recovery hints. E.g., 'Station not found: "Shinjuku-ku". Try search_station("新宿") to find exact station codes.'
• Add tool annotations: set readOnlyHint=true for all four tools (they only read transit data). This signals to LLMs that calls are safe to retry and have no side effects.
• Expand parameter descriptions to include format/range guidance inline. E.g., 'via: Transfer stations (max 3, e.g., ["Shibuya", "Shinjuku"]). Omit if direct route preferred.'
• Standardize search_station response. Always return { candidates: [...], directions?: [...] } so LLMs can rely on a consistent shape. Document when directions are populated (only if single candidate).