Server exposes 17 tools across racing and sports betting domains. Most tools lack parameter descriptions entirely, only 6 of 17 have any documented parameters. Tool names are reasonably verb-forward (api_*, list_*, call_*) but descriptions are often generic or missing context. Schemas are present but sparse: many parameters lack type info or descriptions. No output schemas documented. Error handling is absent, no recovery guidance or categorization. The meta-tools (list_tools, tools_for_capability, call_tool) are self-referential and add little value to end agents. Overall quality is below median for production MCP servers.

• Add parameter descriptions to all 17 tools. For api_price, document 'box' (boolean: whether to box the selection), 'margin' (number: margin % to apply), 'legs' (array: leg objects for same-race multi). Use 50 - 70 character descriptions per pattern:tool-description baseline.
• Document output schemas for all tools. For api_race, specify: returns {race_key, status, runners: [{number, name, odds}], ...}. For api_sgm, specify: returns {price, probability, correlation_model, ...}. This enables agents to plan chaining.
• Replace meta-tool indirection. Instead of call_tool(tool_name, args), expose racing and sports tools directly (get_race, get_game, calculate_price). Remove list_tools and tools_for_capability unless agents genuinely need dynamic discovery.
• Add error recovery guidance. When api_race fails with 'race not found', return: 'Race key invalid. Available races: [list]. Try api_board() to see current races.' This follows pattern:recovery-guide.
• Rename tools to verb_noun convention: api_board → get_racing_board, api_race → get_race_details, api_price → calculate_exotic_price, api_sgm → calculate_same_game_multi. This improves LLM intent inference and reduces ambiguity.