StravaMCP has basic tool definitions but significant quality gaps. All 5 tools have descriptions and input schemas are present, but descriptions are generic (10-50 chars, well below the 50-200 char LLM-optimized baseline). Parameter descriptions are minimal or absent. The 'ping' tool is a health-check anti-pattern. No output schemas documented. Error handling returns generic failures without recovery guidance. No tool annotations (readOnlyHint, etc.). The server lacks the structured, LLM-optimized definitions needed for reliable agent reasoning.

• Expand tool descriptions to 80-150 chars. Example: 'activities' → 'Retrieve the authenticated athlete's recent activities with pagination. Returns activity summaries (name, distance, duration, date). Use page/per_page to navigate large result sets. Defaults to 30 most recent activities.'
• Add parameter descriptions with constraints. E.g., 'per_page: Number of activities per page (1-200, default 30). Larger values may slow response.' and 'page: Page number starting at 1 (default 1).'
• Document output schemas in tool descriptions or as structured comments. E.g., 'Returns: {success: bool, count: int, data: [{name, type, distance_km, moving_time_minutes, date, id}]}'
• Enhance error messages with recovery guidance. E.g., 'Failed to fetch activities: Token expired. Call refresh_access_token() or check STRAVA_REFRESH_TOKEN environment variable.' instead of generic 'Failed to fetch activities'.
• Add tool annotations to schema. Mark all tools with readOnlyHint=true since they only read Strava data. This signals to agents that these calls are safe to retry and have no side effects.

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

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