Server has 13 tools with mostly complete schemas and descriptions. Naming follows verb_noun convention (gym_profile, find_exercises, list_equipment). Descriptions are present and reasonably detailed (avg ~120 chars), exceeding the 10-char minimum. However, several tools lack parameter descriptions (gym_profile, muscle_groups, coach_sessions, coach_new_session, api_surface have empty input objects with no descriptions). Output schemas are not documented, LLMs cannot predict response structure. Error handling is absent from descriptions. Some parameter names are ambiguous (e.g., 'name_or_id' in exercise_detail conflates two types). No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in metadata.

• Add output schema documentation to all tools. Example for find_exercises: 'Returns array of {id, name, equipment[], primary_muscles[], secondary_muscles[], mechanics{}}. Limit defaults to 20; use pagination for large result sets.'
• Split 'name_or_id' parameter in exercise_detail into two optional parameters: 'exercise_name' (string) and 'exercise_id' (string). Document that at least one is required.
• Add tool annotations via FastMCP: @mcp.tool(name='coach_new_session', description='...') with destructiveHint=True for write operations. Reward current spec patterns.
• Document error cases in descriptions. E.g., 'raw_get: Returns 404 if path does not exist. Try api_surface() first to discover valid endpoints.'
• Add parameter descriptions to zero-input tools. E.g., gym_profile: 'Input: none. Returns your gym profile with mapped equipment types.' This clarifies intent for LLMs.