This MCP server exposes 16 AFL-related tools with mixed quality. All tools have names that start with action verbs (Get*), which is good. However, descriptions are uniformly terse (10-60 characters), falling well below the production baseline of 194 chars. Most critically, INPUT SCHEMAS ARE NOT VISIBLE in the provided source code, only tool names and parameter names are documented. The BaseAFLTool class shows error handling patterns and logging infrastructure, but the actual JSON Schema definitions that should accompany each tool are not shown. Without visible schemas, schema scores must be capped at 0 per the hard rules. Parameter descriptions exist (e.g., 'The ID of the game'), but are minimal and lack guidance on ranges, formats, or dependencies. No output schemas are documented. All 16 tools are READ_ONLY, which is good for safety but suggests limited value-add complexity. The server appears to be a wrapper around a third-party AFL sports API with no custom logic for composition or multi-step workflows.

• CRITICAL: Provide complete JSON Schema definitions for all tool inputs. Example for GetGameResult: {"type": "object", "properties": {"gameId": {"type": "integer", "description": "The ID of the game (integer > 0)", "minimum": 1}}, "required": ["gameId"]}.
• Expand all tool descriptions to 80 - 200 characters, including WHEN to use the tool and WHAT data it reveals. Example: 'Retrieve the final score, teams, date, and venue for a completed AFL game. Use after knowing the game ID from a search or schedule tool.' Current: 'Gets result from a played game'.
• Enrich parameter descriptions with ranges and constraints. Example: 'The year (integer; valid range 1897 - 2026; power rankings available from 2022 onwards)' instead of 'The year of the rankings'.
• Document output schemas for each tool in tool descriptions or in separate schema definitions. Example: 'Returns {gameId, homeTeam, awayTeam, homeScore, awayScore, date, venue, status}'.
• Implement structured error responses. When a tool fails, return {"error": "not_found", "message": "Game 99999 not found. Try GetTipsByRoundAndYear to discover available games.", "recoveryAction": "retry_with_different_id"}.
• Add rate-limit handling and timeout guidance. Specify expected latency and max concurrent requests to prevent agent runaway loops.
• Consider breaking down multi-filter tools (GetProjectedLadderByRoundAndYearBySource) into simpler primitives (GetProjectedLadder + optional source filter) to reduce cognitive load for the LLM.
• Add pagination or result-limit guidance. Document whether tools return all results or cap at a limit; if capped, provide guidance on how to page through large datasets.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry