Server Quality Checklist

Tool Scores

• push_workout_guideA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description reveals that delivery depends on normal Suunto app sync, there's no direct live push to the watch, and the guide may need manual pinning in the Suunto app if it doesn't appear. It also notes it's a write operation. However, it doesn't discuss failure modes, rate limits, or whether a guideId update is destructive to existing data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a bit lengthy but every sentence contributes context: the API used, the step conversion, env var requirement, and sync behavior. It could be tightened slightly but is not bloated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description lacks a clear contrast with push_interval_guide, but the context of the SuuntoPlus Guide Cloud API and sync behavior is sufficiently explained. There is no output schema, so the return value is not described, but for an async API push that might be acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Description adds meaning to the exercises parameter by explaining each exercise becomes one step and is advanced by a lap-button press, and it interprets the detail field as a display string. However, with 75% schema coverage, the guideId parameter is documented in the schema but the description adds little beyond stating it updates an existing guide. The date and title are already well described by the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: pushing a text-step workout guide to the user's Suunto account via the SuuntoPlus Guide Cloud API. It distinguishes itself from siblings like push_interval_guide and upload_workout by explicitly mentioning it pushes a text-step workout guide and describing the exercise-to-step conversion. This provides a clear verb, resource, and conceptual model.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains when to use this tool, especially noting the env var requirement and behavior around syncing. However, it doesn't explicitly contrast with push_interval_guide for choosing which guide type to push. Usage context is fairly clear (a workout guide), though not as definitive as listing alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• export_routeA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden of behavioral disclosure. It explicitly states the operation is read-only, specifies the response as a GPX 1.1 XML string, and avoids implying side effects. It does not describe failure behavior for an invalid route ID, but this is minor for a simple read-only export.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences, each adding useful information: what the tool does, where the output is applicable, and how to obtain a valid input. No filler or redundant restatement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter, read-only export tool with no output schema and no annotations, the description gives enough to select and use it correctly: target resource, output format, input source, and safe behavior. It could mention error outcomes, but that is not essential for initial invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents routeId as 'Route ID returned by list_routes.' The description adds a similar hint, but no significant new semantic value beyond what the schema provides. With 100% schema description coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Exports') with a clear resource ('a saved Suunto route') and names the output format ('GPX 1.1 XML string'). It is also implicitly differentiated from the sibling export_workout_gpx, which targets workouts rather than routes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs the agent to use list_routes to discover valid route IDs and states that the export is suitable for import into navigation apps. It does not explicitly enumerate when to choose this over export_workout_gpx, but the route/workout distinction makes the appropriate context clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_daily_activityA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description fully bears the transparency burden. It states the tool is read-only, returns an empty payload for days without synced data, and implies no side effects. The schema description additionally warns about date constraints, but the tool description does not mention rate limits or response structure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with no unnecessary words. It front-loads the primary purpose and efficiently covers sample content, edge case, alternative, and requirements.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description covers purpose, sample contents, edge case, sibling alternative, and requirements. However, it omits details about the response format or fields, which would be helpful given the lack of output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the schema already provides a detailed description for the 'date' parameter including format, pattern, and sync behavior. The tool description adds little new about the parameter, only that it expects a single day. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns 24/7 activity time-series samples for one calendar day. It specifies the API source, sample contents (timestamp, steps, HR), and edge case (empty payload). This distinguishes it from sibling tools like list_daily_activity (date range) and get_daily_activity_statistics (statistics).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Use list_daily_activity to fetch a date range,' providing a clear alternative. It also mentions the requirement for a subscription and that days without data return an empty payload, but does not elaborate on when to use other siblings like get_daily_activity_statistics.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_upload_statusA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It does add useful behavioral context: 'polls' implies transient, non-destructive repeated reads, and the status examples ('Queued', 'Processing', 'Processed', 'Error') plus the delayed appearance of workoutKey clarify when the poll is complete. However, it does not disclose behavior for an invalid/unknown uploadId or whether there is any terminal retry/error pattern, which is a noticeable gap for an unannotated polling tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each carrying useful cargo: purpose, return shape, and downstream routing. No filler, and the main verb and context are front-loaded in the first sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one required string parameter), has no annotations, and no output schema. The description compensates well by specifying the status enum and the workoutKey result, plus the follow-up step with get_workout. The only gaps are edge-case behavior for invalid upload IDs or polling termination decisions, which are minor for a tool this small.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the input schema already explains uploadId as 'Upload ID returned by upload_workout.' The description merely repeats this provenance ('initiated by upload_workout') without adding new syntax, format, or lifecycle details, so it does not raise the value above the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('polls') and resource ('processing status of a workout upload'), and explicitly ties it to upload_workout as its origin. This clearly distinguishes it from get_workout and other siblings by framing it as the polling stage in an upload workflow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The workflow is explicitly laid out: this poller follows upload_workout ('initiated by upload_workout') and its output is consumed by get_workout ('Use the returned workoutKey with get_workout for full detail'). This gives the agent exact when-to-use context and routes it to the correct next step.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• upload_workoutA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description takes on the behavioral disclosure burden. It explicitly identifies the operation as a write, explains the async side effect (file appears in the app after processing), gives a latency estimate, and states that the return value is a pollable uploadId. It does not cover failure modes or authentication requirements, which prevents a 5.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the first sentence states the operation and target, then it covers the required input, the expected side effect, the return value, format constraints, and write semantics. There is no filler, and each sentence contributes to successful invocation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is complete enough for the tool's complexity: it names the required parameter, accepted file types, the side-effect timing, and the follow-up polling flow. The lack of failure-mode details like what happens with invalid files or upload limit errors is the only meaningful gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the input schema already documents all four parameters. The description adds useful emphasis on the absolute path and file format details, but it does not materially expand on the parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Uploads a FIT or GPX workout file'), a clear target ('the user's Suunto account'), and the file path requirement. This clearly distinguishes it from sibling list/get/export tools, and even names the follow-up polling tool get_upload_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use this when uploading a local .fit/.gpx workout file, and poll the returned uploadId via get_upload_status afterward. It does not explicitly state when not to use it or compare it against push_workout_guide/push_interval_guide, but the workflow guidance is strong enough for an agent to decide correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_workout_fitA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Explains read-only nature, default output content, and size implications of full mode. Also notes that workoutKey is not guessable. Good coverage without annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Concise, well-structured with main action first. Each sentence adds necessary information without redundancy. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema, but description adequately explains return shape for both modes. Covers key aspects for agent to decide invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters. Description adds valuable context: workoutKey must be discovered via list_workouts, and full parameter effect is clarified beyond schema defaults.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool downloads a binary FIT file and returns parsed JSON. It distinguishes between default compact summary and full mode, and notes read-only. This differentiates it from siblings like get_workout and export_workout_gpx.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit guidance on when to use default vs full=true based on data size. No explicit mention of when to use this over other workout tools, but the context is clear for its specific function.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_daily_activityA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, so description carries full burden. States read-only, omits days without synced data, accepts future dates with no entries, and confirms chronological ordering. Lacks details on rate limits or pagination, but sufficient for basic understanding.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences plus one for alternatives/requirements. No redundant words, front-loaded with core functionality. Highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given simplicity (2 params, no output schema), description covers return structure, ordering, and data omission. Could mention sample frequency or additional metrics, but still adequate for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with both parameters having detailed descriptions (date format, constraints, behavior like silent omission). Description adds minimal extra meaning beyond schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states it returns 24/7 activity time-series samples with verb 'returns' and specifies resource, scope, and ordering. Distinguishes from siblings get_daily_activity (single day) and get_daily_activity_statistics (aggregated).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly advises when to use siblings for single day or aggregated totals. Also mentions required subscription, providing clear usage context. No ambiguous phrasing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• export_workout_gpxA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, but the description discloses that the tool is read-only, returns empty GPX if no GPS data, and the output is an XML string. This adequately covers behavioral aspects, though some details like internal processing are absent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four concise sentences, front-loaded with the primary action, each sentence adding unique value: format, content, empty case, alternative, and read-only nature. No redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter tool with no output schema, the description fully explains the return format, content details, edge case (empty GPX), and provides usage context and sibling differentiation. No gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the description does not need to add parameter details. The description does not mention the parameter, but the schema itself is sufficient. Baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it returns the GPS route as a GPX XML string (not JSON), specifies the format and contents of trackpoints, and differentiates from sibling tools like get_workout_samples.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly tells when to use (for GPS route export) and when not to use (for numeric time-series), and provides the alternative tool get_workout_samples. Also mentions compatibility with common GPS tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_routesA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description correctly carries the disclosure burden by stating the operation is read-only and specifying what data will be returned. It does not discuss pagination or edge cases like an empty route list, but for a read-only list operation this is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with no filler. It front-loads the core result, lists return fields, and flags the main alternative in one compact statement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless list operation, the description fully defines behavior, output contents, read-only nature, and how to get track data. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is nothing for the description to clarify. The baseline 4 applies because the description fully covers the no-input behavior and return fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb (Returns) and resource (routes saved in the user's Suunto account), and enumerates the exact fields returned. It is clearly distinguishable from siblings like list_workouts and export_route.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly directs agents to use export_route when navigation data is needed, establishing a clear alternative and condition. It doesn't contrast with list_workouts, but the resource is clearly route-specific.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_daily_activity_statisticsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description fully bears the burden. It states the tool is read-only, describes the response structure, and discloses behavioral traits like maximum interval and null value meaning. No contradictions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences clearly convey purpose, response format, usage guidance, and read-only nature. No redundancy, but could potentially be slightly more concise by merging response format details. Still efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the moderate complexity (2 params, no output schema, no annotations), the description covers all necessary context: what the tool does, what it returns, constraints, and differentiation from siblings. It is complete for a retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific information beyond what is already in the schema (ISO-8601, UTC, 28-day constraint). The response structure description is helpful but not directly about parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns aggregated daily step count and energy consumption from the /247 API for a datetime range. It specifies the verb ('Returns') and resource, and distinguishes from sibling list_daily_activity by noting preference when totals are needed vs intraday time-series.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly advises when to prefer this tool over list_daily_activity (for totals) and notes the maximum fetch interval of 28 days. It also explains that null Value indicates no synced data, providing clear usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_subscriptionsA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description adequately discloses read-only behavior, empty array response, and a prerequisite (Subscriptions API product). Lacks details on authentication or rate limits, but sufficient for this simple read operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences, each providing essential information: output format, empty state, and usage guidance. No redundant or missing words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless tool with no annotations or output schema, the description fully covers purpose, behavior, and usage context, enabling an agent to correctly select and invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so no parameter documentation is needed. The description adds value by specifying the output structure and usage context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns all active webhook subscriptions as an array with specific fields (id, eventType, callbackUrl, createdAt), distinguishing it from sibling tools focused on workouts, activities, sleep, and recovery.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly advises using the tool to audit existing subscriptions before adding new ones, and notes it is read-only. Does not explicitly mention alternatives or when not to use, but the context is clear given the specialized functionality.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_workoutsA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description calls itself 'Read-only' and explains auto-pagination behavior. Since no annotations are provided, the description carries the full burden and does so well. It could improve by noting that the returned data is summary-level, but the field list already implies that.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only three sentences: one for purpose, one for return fields, one for pagination and sibling tool. No redundant words, well structured, and front-loaded with key purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description lists all expected fields. Parameters are fully documented with examples. The tool references a sibling for more detail. For a list endpoint with simple parameters and a clear use case, it covers everything needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with good descriptions. The tool description adds meaningful context beyond the schema, such as explaining how 'since' and 'until' relate to pagination and suggesting using 'limit:1' for the single most-recent workout. This compensates for any schema-only gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns recent Suunto workouts ordered newest-first, and lists all returned fields. It is specific about the verb ('returns') and resource ('workouts'), and distinguishes itself from siblings by mentioning the API version and suggesting 'get_workout' for full detail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Use get_workout for full detail...' when more detail is needed, and mentions auto-pagination. It provides clear usage context, though it does not explicitly state when not to use the tool or mention prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_sleepA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Describes the return values, empty payload behavior, and subscription requirement. Annotations are absent, so description carries the full burden; it covers key behaviors but omits rate limits or data staleness beyond parameter-level sync note.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences that front-load the core purpose and immediately follow with usage guidance and prerequisites, with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with no output schema, the description thoroughly covers inputs, outputs, edge cases, and dependencies, providing complete context for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema already provides 100% coverage for the date parameter, but the description adds valuable context about wake-up date keying and sync timing, enhancing the agent's understanding beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool returns sleep time-series samples for one calendar day, listing the specific fields. It distinguishes itself from sibling tool list_sleep by specifying single-day focus.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly instructs to use list_sleep for date range, and mentions the required API subscription with a 404 error if missing, providing clear usage boundaries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• generate_daily_digestA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It discloses that this is a write operation updating a sidecar file and a history file, names the sidecar path and env var, explains the CTL/ATL/TSB computation, rolling baselines, party-night bucket, and subscription fallback — far beyond what the schema provides.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but almost every sentence carries distinguishing information — side effects, state persistence, calculus, subscription requirements. It front-loads the core purpose and append behavior first. It could be tightened slightly, but it earns its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 3-parameter tool with 100% schema coverage and no output schema, the description covers everything an agent needs: what to do, when to call, prerequisite subscription, computation, storage side effects, and first-run behavior. Nothing important is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already documents all three parameters. The description adds key nuance: seedAtl and seedCtl only matter on the first digest, seedCtl should be anchored to the user's watch value, and the date should be yesterday or earlier. That adds value beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource ('Builds a color-coded daily health digest') and clearly distinguishes it from sibling read-only tools like get_daily_activity or get_sleep by explaining it computes and appends a markdown history file rather than just returning API data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says to use yesterday or earlier, notes today's data is usually incomplete, and explains that Sleep/Recovery API subscriptions are needed for those sections. It also says what falls back to 'no data' if subscriptions are missing, giving the agent clear when-to-call guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_workout_samplesA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses read-only nature, error thrown (SuuntoNotFoundError), sampling rate, and data volume caveat for long workouts, all beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with purpose, followed by field list, caveat, alternative, and error condition. No redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description explains the output contents and key behaviors. It could explicitly state the output is a list, but the context is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides a description for workoutKey, but the description adds crucial context about the key's origin and discoverability, enhancing understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns time-series sample streams for one workout, listing all fields and distinguishing it from get_workout_fit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly tells when to use (detailed data) and when not (long workouts), and suggests an alternative tool (get_workout_fit with full=false).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• push_interval_guideA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full behavioral disclosure burden, and it does so thoroughly. It discloses the write nature, the auto-advance mechanism, the target-HR display capability, the environmental prerequisite, and the 'no live push' delivery caveat. These are exactly the behavioral traits an agent needs to anticipate correct behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: purpose, differentiation, behavior, requirements, and caveat are each handled in direct, memorable sentences. No sentence is wasted or merely repeats schema content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the high schema coverage and absent annotations, the description adds the missing behavioral context: it explains the async sync behavior, the write operation, and the most important execution constraint (environment variable match). It does not discuss error conditions or update-via-guideId side effects, but those are secondary for a tool with this clear schema and no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents all 4 parameters with 100% coverage, so the baseline for this dimension is 3. The description goes beyond by explaining the practical meaning of the parameters: durationSec/distanceM drive auto-advance, and targetHrMin/targetHrMax can appear live alongside the segment display. This contextual layer helps the agent understand how parameter choices affect device behavior.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Pushes an interval/cardio guide ... to the user's Suunto account via the SuuntoPlus Guide Cloud API.' It also explicitly differentiates itself from push_workout_guide by contrasting auto-advancing interval segments with manual lap-per-exercise, making its purpose and distinct role unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states its context and alternative: interval/cardio guides with auto-advance should go here, while manual lap-by-lap guides belong to push_workout_guide. It also gives practical usage constraints, like the SUUNTO_APP_NAME environment variable requirement and the after-sync delivery behavior, helping the agent decide when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_recoveryA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist; description fully discloses: read-only, empty payload for no data, subscription dependency with 404 error, date constraints for reliable results.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Six sentences, each adding value. Front-loaded with primary action, followed by key details. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given single required parameter, no output schema, and no annotations, description covers all needed context: return structure, edge cases (empty payload, errors), and setup requirements.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but description adds critical context about sync frequency, reliable date range, and expected error for today/future dates, going beyond schema examples.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states verb ('returns'), resource ('recovery and HRV time-series samples'), and scope ('for one calendar day'). Distinguishes from sibling 'list_recovery' by specifying single-day vs date-range.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly provides alternative tool ('Use list_recovery for a date range'), prerequisites ('Requires Recovery API subscription'), error conditions ('returns 404 without it'), and date-validity guidance ('use yesterday or earlier').

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_workoutA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It declares read-only behavior, clearly states the error condition, and lists the types of data returned. This is sufficient for an agent to understand the tool's behavior without surprises.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (3 sentences), front-loaded with the main purpose, and every sentence adds value. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description explains return content (laps, HR zones, training-effect, sport-specific), mentions error handling, and references related tools. It is complete for a simple retrieval tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage, but the description adds significant context: the opaque nature of workoutKey, requirement to discover via list_workouts, and the specific error on invalid key. This goes beyond the schema's own description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states it returns the full summary for one workout, listing specific fields (laps, HR zones, training-effect, sport-specific metrics). It distinguishes from siblings like get_workout_samples and list_workouts by specifying what this tool does versus alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly tells the agent to use list_workouts to discover valid workoutKey values and directs to get_workout_samples for time-series data. Also warns that invalid key throws SuuntoNotFoundError, providing clear when-to-use and when-not-to.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_recoveryA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations, but description fully discloses behavior: chronological order, omission of days without data, future dates accepted but yield no entries, and subscription requirement. Marks read-only.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Five sentences, each adding value. Front-loaded with main action, followed by output format, sibling reference, error conditions, and optimization tip.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Complete without output schema: includes output structure, enum meanings, API source, and prerequisite. No gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 100% coverage; description adds context: days without data silently omitted for 'from', future dates accepted with no entries and responsiveness hint for 'to'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it returns recovery and HRV time-series samples for a date range, ordered chronologically. Distinguishes from sibling 'get_recovery' for single day.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says 'Use get_recovery for a single day', mentions subscription requirement and 404 error, and advises preferring ranges ≤30 days.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_sleepA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses it is read-only, returns 404 without subscription, omits nights without recorded sleep, and that future dates produce no entries. Covers all behavioral traits despite no annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences with bullet-point-like format for fields. No wasted words, front-loaded with key information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Explains return fields in detail (timestamp, sleep stages, efficiency, score) and notes when entries are omitted. Complete for a list tool without output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Adds significant meaning beyond schema: specifies 'from' and 'to' as wake-up dates inclusive, notes silent omission for missing nights, and recommends ranges ≤30 days. Schema coverage is 100% but description still adds value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it returns sleep time-series samples from the /247samples API for a date range, ordered chronologically. Distinguishes from sibling get_sleep for single night.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly mentions to use get_sleep for a single night, and notes requirement of Sleep API subscription. Provides clear context on when to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.