Strong tool definitions with excellent descriptions (avg 180+ chars) and comprehensive parameter documentation. All 7 tools have clear, LLM-optimized descriptions explaining WHAT, WHEN, and WHY. Input schemas use Zod with proper types and constraints. However, output schemas are not documented, responses are JSON-stringified without field-level documentation. Error handling is basic (relies on upstream API). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Parameter naming is consistent and descriptive. Composition is clean: each tool has one responsibility, and tool outputs contain IDs needed for chaining (e.g., race_id for follow-up queries).

• Document output schemas for each tool. Add a comment block above each tool definition describing the response structure, e.g. '// Returns: { data: { races: [{ race_id, venue, jump_time, runners: [{ name, bookmakers: [{ key, price }] }] }], credits: {...} } }'
• Add readOnlyHint annotations to all 7 tools. Modify server.tool() calls to include annotations: { readOnlyHint: true } in the tool definition. This signals to agents these are safe to call speculatively.
• Enhance error handling with recovery guidance. When API returns 402, return 'Upgrade required. Visit https://puntersedge.online/api to increase credits.' When 404, return 'Invalid sport_key. Call list_sports() to see available options.'
• Validate and document parameter constraints. For 'country', add validation: z.string().regex(/^[A-Z]{2}(,[A-Z]{2})*$/).optional() and update description to 'ISO 3166-1 alpha-2 codes, comma-separated (e.g. AU,NZ).'
• Add pagination guidance to racing_next_to_go and racing_best_odds descriptions. Note that num_races is capped at 50 and explain how to iterate through results if more races are needed.