Server has 14 well-named tools with consistent verb_noun patterns (search_, get_, tool_ prefix). All tools have descriptions (avg ~100 chars, within baseline 34-392 range). Input schemas are visible and properly typed in function signatures. However, critical gaps: (1) No output schemas documented, LLMs cannot predict response structure for planning; (2) Parameter descriptions are minimal (avg ~50 chars vs baseline 72); (3) No error handling guidance, tools return JSON strings with no recovery hints; (4) No pagination support despite tools like search_connections returning lists; (5) No input validation or constraint documentation (e.g., 'stations' array must be exactly 2 elements, but not enforced or clearly stated). Tool names are clear and action-oriented, but descriptions lack WHEN/WHY context and dependency hints.

• Document output schemas for all tools. Add a 'Returns' section to each tool docstring specifying field names, types, and meanings. E.g., 'Returns: {stations: [{id: int, name: str, slug: str, type: str}]}'.
• Add pagination to list-returning tools. Introduce limit (default 20, max 100) and offset/cursor parameters. Return total_count and next_cursor in responses to enable multi-page iteration.
• Validate and document parameter constraints. For tool_get_seat_stats, enforce len(stations)==2 and return 'stations must contain exactly 2 station names' on violation. For tool_search_connections, document 'length: 1-50 (default 5)'.
• Wrap API responses with error recovery hints. Instead of returning raw API errors, catch exceptions and return structured errors like '{error: "Station not found", suggestion: "Try search_stations(\"Krakow\") to find the correct station ID"}'.
• Enhance parameter descriptions with timezone, format, and dependency info. E.g., 'date: ISO 8601 datetime in UTC (e.g., 2026-02-27T14:00Z). Defaults to current UTC time. Past dates are allowed for historical queries.'