Six tools with clear verb-noun naming (list_*, search_*, book_*, cancel_*, my_*). All have descriptions (avg 120 chars, within 10-1024 range). Input schemas present with type definitions and parameter descriptions. Output schemas documented via docstrings. Key strength: dry-run/confirmation pattern on destructive ops (book_court, cancel_booking). Weaknesses: some parameter descriptions lack format/constraint details (e.g., 'date' accepts multiple formats but no regex/enum); no explicit error recovery guidance; output structure inferred from code rather than formally documented in schema.

• Add regex pattern or enum constraint to 'date' parameter: accept ISO 8601 (YYYY-MM-DD) or natural language ('today', 'tomorrow') but validate format before parsing.
• Document output schemas explicitly in tool definitions. E.g., book_court returns {date, time, court_name, opponent_names, booking_id, status}. Use JSON Schema in the tool registration.
• Enhance error messages with recovery steps. E.g., 'Invalid court_type: got "indoor_grass". Valid types: indoor, outdoor, grass. Call list_slots with court_type=None to see all available courts.'
• Add pagination to list_slots: accept 'page' and 'limit' params, return {slots: [...], total_count, next_page}. Cap default limit at 20-50 to prevent context bloat.
• Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to FastMCP tool decorators to signal to clients which tools are safe to retry and which require confirmation.