Static source inference · medium confidence · evidence: structured output
No deprecated protocol patterns detected
Summary
icuvisor demonstrates moderate definition quality with a mix of strengths and significant gaps. Tool naming follows verb-noun conventions (get_*, create_*, delete_*) which is good. However, parameter schemas are inconsistently documented, descriptions vary widely in quality, and output schemas are not visible in the source code. 18 tools total: 12 read-only tools and 6 write/destructive tools. Critical issues include: (1) parameter schemas visible for some tools (e.g., get_fitness, get_training_summary) but missing for others (e.g., icuvisor_list_advanced_capabilities, icuvisor_check_server_version); (2) descriptions are present but often too brief (under 50 chars for some tools); (3) no visible documentation of output schemas; (4) tools are well-named but parameter descriptions lack detail about constraints, formats, and examples. The codebase shows good structure with separate directories for tool types (read_tools.go, write_tools.go, delete_tools.go, compute_tools.go), but tool registration details are not fully visible in the provided code snippet.
Tools (18)
compute_zone_timeread onlyauth50/100
Compute zone time metrics from training activities and summaries
create_eventwriteauth50/100
Create a calendar event or workout
delete_activitydestructiveauth50/100
Delete a recorded activity
delete_custom_itemdestructiveauth50/100
Delete a custom fitness chart item
delete_eventdestructiveauth50/100
Delete a calendar event
delete_geardestructiveauth50/100
Delete a gear item from the equipment list
delete_sport_settingsdestructiveauth50/100
Delete sport-specific settings
get_activitiesread onlyauth50/100
List athlete activities with filtering and pagination
Tools icuvisor_list_advanced_capabilities and icuvisor_check_server_version have NO visible input schemas. Cannot verify parameter types, constraints, or descriptions.
Output schemas are not documented in the provided source code. LLMs cannot infer what fields to expect from responses, limiting ability to chain tools and extract relevant data.
Parameter descriptions lack detail about expected formats, constraints, and enums. For example, sport parameter in compute_zone_time and get_activities is described as 'Optional sport filter' but does not list valid sport types.
Recommendations
Add explicit input schemas (with type, required fields, constraints) to icuvisor_list_advanced_capabilities and icuvisor_check_server_version. Specify whether they accept parameters and validate them.
Document output schemas for all tools. Include field names, types, and which fields are required. Example: 'Returns object with fields: activity_id (string), sport (string), duration_seconds (integer), power_zones (array of {zone (string), minutes (integer)})'.
Enhance parameter descriptions with format constraints. Replace 'Start date for fitness data retrieval' with 'Start date for fitness data retrieval (ISO 8601 format: YYYY-MM-DD)'. Add enums for sport: 'Sport filter (one of: cycling, running, swimming, triathlon)'.
Implement confirmation/dry-run pattern for destructive tools. For delete_* tools, consider adding a 'dry_run' parameter (boolean, default false) to preview impact before committing.
Add recovery guidance to error messages. When a date range is invalid, return 'Invalid date range: end_date must be after start_date. Specify as ISO 8601 (YYYY-MM-DD)'. When a resource is not found, suggest 'Activity not found. Call get_activities() to list available activities.'
Expand short descriptions. Rewrite icuvisor_list_advanced_capabilities as: 'List available tools filtered by execution capabilities (e.g. coach-mode authorization). Returns tool name, description, execution capability, and authorization status. Use before invoking tools to verify permissions.' (100+ chars, actionable).
Score history
Overall score trend
First recorded score · v2 rubric
52/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-23
D
52
2025-06-18+
v2
get_activityread onlyauth50/100
Get detailed activity data with all metrics and intervals
Destructive tools (delete_*) lack confirmation/dry-run patterns. No evidence of recovery guidance or per-item success/failure reporting for bulk operations.
Tool descriptions for icuvisor_list_advanced_capabilities and icuvisor_check_server_version are very short (under 50 characters), failing to explain WHEN to use them or dependencies on other tools.
Date/time parameters (start_date, end_date, start_date_local) lack explicit format documentation. No mention of ISO 8601 or expected timezone handling, forcing LLMs to guess.
Clarify timezone handling for date/time parameters. Document whether dates are local or UTC, and if create_event's start_date_local should be a string with timezone info or just a date.
Add pagination parameters (limit, offset/cursor) and result counts to list-like tools (get_activities, get_events, get_wellness) if they can return large result sets.
For tools accepting optional array parameters (e.g. fields in get_wellness), document valid field names and provide examples: 'Optional specific wellness fields to retrieve (array of strings: sleep_duration, stress_level, recovery_index).'
Document idempotency and retry semantics for write tools (create_event, update_event). Can updates be safely retried? Are creates idempotent with an idempotency_key parameter?