Output schemas are not documented. The server provides only input schemas (date ranges, single dates) but does not document what fields responses contain. LLMs cannot plan downstream tool chaining or extract the correct fields from results.

Tool descriptions are too generic and lack LLM guidance. Most descriptions are 30-50 characters and state only what data is returned, not when to use the tool or what makes it distinct from similar tools. Baseline for production tools is 50-200 characters with decision context.

Error responses provide no recovery guidance. The server catches RuntimeError, ValueError, and generic Exception, logging them and returning error text like 'Auth error in tool X: <message>'. The LLM has no guidance on whether to retry, lookup credentials, or abandon the attempt.

Parameter descriptions lack actionable format guidance. The input schemas declare date parameters as type string with description 'Start date in YYYY-MM-DD format' or 'End date in YYYY-MM-DD format'. This is minimally compliant but does not specify boundary conditions, valid ranges, or what happens with future dates or malformed dates.

No pagination or result limiting is visible in tool definitions. Tools like get_activities and get_body_composition accept only date ranges, with no limit, offset, or page parameters. If a user requests a year of activity, the response could be massive and blow context windows. No documentation of result caps.

No distinction between daily-scoped and range-scoped tools in naming. Tools like get_activities, get_body_composition operate on date ranges, while get_daily_stats, get_heart_rate operate on single dates. The naming does not make this distinction obvious (e.g., 'get_activities_range' vs 'get_activities_day'). LLMs may misapply tools.