18 tools with complete JSON Schema definitions and consistent naming (verb_noun pattern). All tools are READ_ONLY and properly described. However, descriptions are generic (avg ~60 chars, well below the 194-char baseline for A+ tools) and lack context about when to use each tool vs. similar ones. Parameter descriptions are minimal. Output schemas are not documented. No error handling guidance. Missing idempotent/readOnly annotations. Tool composition is reasonable but lacks chaining hints (e.g., getUserLeagues returns league_id, which feeds getLeagueInfo, but this dependency is not documented).

• Expand tool descriptions to 100-200 chars. Include WHEN to use each tool and how it differs from similar ones. Example: 'Fetches all rosters in a league (team assignments and player lists). Use this after getLeagueInfo to see which players are on each team. Returns roster_id, owner_id, and players array.'
• Document output schemas for all tools. Specify the structure of returned objects, required fields, and data types. Example: 'Returns {league_id, league_name, season, total_rosters, status, scoring_format, ...}'. This enables LLMs to plan downstream calls.
• Add readOnlyHint annotation to all 18 tools in the tool definition. This signals to MCP clients that these tools are safe to cache and retry without side effects.
• Add error handling guidance to tool descriptions. Example: 'If user_id is invalid, returns 404 with message "User not found". Try getUserInfo with username instead.' This guides LLM recovery.
• Document tool chaining dependencies. Example in getUserLeagues description: 'Returns league_id values. Pass these to getLeagueInfo, getLeagueRosters, or getLeagueMatchups to fetch league details.' This reduces discovery overhead.

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

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