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

Annotations already cover read-only, idempotent, non-destructive, open-world. The description adds genuinely new behavior: the response is 'squeezed' with nulls and image/ID noise removed and long lists cut, which warns the agent that returned data is lossy/truncated. It stops short of stating auth requirements, rate limits, or error behavior on invalid paths.

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

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

The purpose and the exclusion rule are front-loaded in the first sentence, which is exactly right. The trailing list of five example paths is somewhat long, though each one demonstrates a different path shape and thus mostly earns its place.

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

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

Output schema exists so return values needn't be explained, and annotations carry the safety profile. What remains — what the tool is for, when not to use it, valid path shapes, and that output is trimmed — is all present.

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

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

At 100% schema coverage the baseline is 3, but the description goes beyond the single schema example by showing multiple real path templates, including segment-style ({start}/{end}) and query-style (?date=…) forms — useful for constructing a valid 'path' and knowing when to use 'params' instead.

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

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

States a specific verb and resource ('GET any Personal API path and return the JSON') and immediately frames itself as an escape hatch, which distinguishes it from every typed sibling (get_recovery, get_activity, etc.) without the agent needing to read schemas.

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

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

Explicitly says 'Use only when no other tool covers the data' — an unambiguous when-not rule — and backs it with concrete path examples showing the data domains (stress, heart rate, SpO2, fitness age, weight goal) that the typed siblings don't cover.

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

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

Annotations already establish that this is a safe, read-only, idempotent operation. The description adds useful context about what the response contains, including FIT-file-derived laps, legs, and HR-zone data, but does not explain performance implications, missing-file behavior, or other operational details.

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

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

The description is a single compact sentence that front-loads the core action and then lists the returned content. It is appropriately sized and contains no wasted language.

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

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

The tool has full parameter schema coverage, an output schema, and clear read-only annotations. The description is complete enough for an agent to understand the tool's scope and returned data, though it could be slightly stronger with explicit guidance about when to choose this over sibling tools.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description reinforces that lap/leg/HR-zone data comes from the FIT file, but it does not add parameter-specific syntax or semantics beyond what the schema already provides.

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

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

The description clearly states that this tool returns a single activity in detail, including summary metrics, planned workout, multisport legs, laps, and HR-zone time. It implicitly distinguishes itself from list_activities by emphasizing one activity, though it does not explicitly name or contrast with that sibling.

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

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

Usage is implied: this is the detail-fetch tool for a specific activity, while list_activities would be used to find activity IDs. However, the description does not explicitly state when to use this tool versus alternatives or mention prerequisites such as obtaining an ID first.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds one real behavioral fact — the 90-day default window — but says nothing about units, what happens on days with no weigh-in, or whether the average includes only recorded days.

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

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

Two sentences, the payload described first and the defaulting rule second, with no filler or redundancy.

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

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

An output schema exists so return shape needn't be restated, and the description covers scope, metrics, aggregation, and the default window. That is everything an agent needs to call this read-only tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by explaining that a null/omitted range defaults to the last 90 days, which the schema's 'default: null' does not convey.

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

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

States a specific resource (weigh-ins/body composition) and enumerates the returned metrics (weight, body fat, muscle, water, BMI) plus the range average, which clearly separates it from get_nutrition, get_recovery and the activity tools. It lacks an explicit verb like 'retrieve', but the intent is unambiguous.

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

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

No when-to-use or when-not-to-use guidance and no mention of the sibling tools whose data overlaps (e.g. get_day_detail may also include weight). Usage is only implied by the metric list, which is adequate but leaves the agent to infer boundaries.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is well covered. The description adds the default-date behavior and the scope of data returned, but says nothing about missing/no-data days, latency, or per-source auth requirements. On net it adds modest context above the annotations.

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

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

Two sentences, front-loaded with the drill-down promise and the content list, and ends with the default behavior where it belongs. Dense but no wasted sentences; the parenthetical event list is justifiable because it defines scope.

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

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

An output schema exists so return values need no explanation, annotations carry the safety profile, and the single parameter is fully documented. The description covers purpose and default behavior; only the lack of alternative-routing guidance keeps it short of full completeness.

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

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

Schema coverage is 100% and already documents 'YYYY-MM-DD, today, yesterday'. The description contributes real information the schema does not: the default is null in schema, and it clarifies that an omitted date resolves to today, which changes how an agent should call it.

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

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

States a specific verb-and-resource ('Deeper look at one day') and enumerates the concrete contents: sleep score breakdown, Garmin sleep insight, overnight HRV range, and Body Battery events. That enumeration separates it from summary-level siblings like get_recovery and get_training_summary, even though those siblings are never named.

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

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

The word 'deeper' strongly implies a drill-down from a summary view, and the listed contents imply this covers sleep/HRV/Body Battery rather than body composition or nutrition. However, no explicit when-to-use, when-not-to-use, or named alternative is given, so the routing must be inferred.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description still adds useful behavioral context by scoping exactly what data is bundled in the response (totals, goals, meals, hydration, sweat loss) and confirming the default-date behavior. It stops short of noting data availability caveats for days without logged food.

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

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

Two tight sentences with the payload contents front-loaded and the default behavior trailing. Every clause carries information; nothing is repeated from the schema or title.

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

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

With an output schema present and rich annotations, the description only needs to convey scope and defaults, which it does. A brief note on how the hydration/sweat-loss figures relate to logged intake would make it fully self-sufficient for interpreting results.

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

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

Schema description coverage is 100% and already documents the accepted formats ('YYYY-MM-DD', 'today', 'yesterday'). The description only restates the default, adding no new meaning about the parameter beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb+resource: retrieves the Garmin Connect food log for one day, and enumerates the contents (totals, goals, meals) plus hydration and sweat-loss data. It is clearly distinguishable from siblings like get_body_composition or get_recovery by subject matter, though it never names an alternative explicitly.

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

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

'Defaults to today' gives an implicit usage cue for the no-arg case, but the description never states when an agent should pick this over get_day_detail or the generic garmin_api_get escape hatch. Usage is inferable from the resource name rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only that the payload is static user settings; it says nothing about auth requirements, freshness/caching, or whether zones are user-defined vs. device-derived, which would be genuinely additive.

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

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

A single compact sentence with no filler, leading immediately with what the resource is before listing its contents. Nothing could be removed without losing information.

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

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

An output schema exists, so return values need not be spelled out, and annotations cover the safety profile; for a zero-parameter read tool the description is nearly sufficient. It could be stronger by stating the intended workflow position (call this before interpreting activity data), but no essential gap remains.

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

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

The tool takes zero parameters, which is the baseline-4 case. The description's enumeration of fields describes the return payload rather than arguments, but for a no-arg getter there is nothing further to specify.

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

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

The description names the resource (user settings/profile) and enumerates its contents — units, time zone, training days, heart-rate zones per sport — so an agent knows exactly what it returns. The 'relevant to interpreting data' framing further distinguishes it from siblings like get_activity or get_training_summary, though it never explicitly contrasts with them.

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

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

'Relevant to interpreting data' implies the calling context (fetch this before/while reading units- or timezone-dependent data), which is a useful hint. However, there is no explicit when-to-use statement, no exclusions, and no named alternative among the many siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuine operational behavior beyond that: the implicit 7-day default window and a hard 92-day ceiling per call. It does not discuss pagination or truncation near the 92-day limit, but on balance it adds real constraints.

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

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

Two sentences, no filler, with the payload contents front-loaded and the range rules as a trailing constraint. The metric list is dense but each item is informative, not restated boilerplate.

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

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

With an output schema present, the description does not need to explain return values, and the inline enumeration of metrics plus range behavior covers what an agent needs to call it. The remaining gap is sibling disambiguation against get_day_detail, which an agent may need to resolve elsewhere.

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

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

Schema coverage is 100%, so the schema already documents start_date/end_date formats ('YYYY-MM-DD', 'today', 'yesterday') and baseline would be 3. The description adds meaning the schema does not: what happens when both are null, and the maximum span the two dates may cover.

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

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

The description names a specific resource and enumerates exactly what the 'recovery picture' contains (sleep, HRV, resting HR, stress, Body Battery, steps, range averages), which lets an agent predict the payload. It never names a sibling or states how it differs from get_day_detail or get_training_summary, which likely overlap on sleep/HRV data.

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

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

Usage is only implied via the default window ('Defaults to the last 7 days') and the per-call cap. There is no statement of when to prefer this over get_day_detail or get_training_summary, and no exclusions or prerequisites are given.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's added value is the derivation source (server-side aggregation of the activity list) and the precise default range, which an agent cannot get from the schema. It does not mention performance, caching, or data-lag caveats, but with an output schema present that omission is minor.

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

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

Three tight sentences, front-loaded with the resource and its metrics, then computation source, then defaults. The '(or month/day)' parenthetical slightly duplicates the group_by enum, but nothing else is wasted.

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

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

With an output schema and full annotations, the description needs only scope, granularity, and defaults — all present. The one remaining gap is sibling routing guidance, which is a usage concern but still affects whether an agent picks this tool correctly.

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

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

Schema coverage is 67%, and the description compensates for the gap by explaining that group_by selects week versus month/day granularity and by pinning the default range when start/end are omitted. The date parameters' formats ('YYYY-MM-DD', 'today', 'yesterday') are already in the schema, so no credit there.

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

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

States a specific verb+resource (training volume summary) and enumerates exactly what the output covers: sessions, hours, distance, elevation, training load, TSS, HR-zone minutes, split by sport. The clause 'computed by this server from the activity list' plus the aggregation granularity clearly separates it from siblings like list_activities and get_day_detail.

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

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

The default window ('last 8 full ISO weeks including the current one') gives implied usage context for aggregate trend questions, but the description never says when to prefer this over get_day_detail or list_activities, nor any exclusions. Routing is left to inference from the metric list.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds the newest-first ordering, compact-row output shape and default window, but says nothing about pagination, total counts, or the fact that large ranges may be truncated by limit.

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

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

Two sentences, front-loaded with the resource and output shape, with the default scope placed second. No filler.

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

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

With an output schema present, the field enumeration is bonus rather than necessity, and the default-window note fills the main schema ambiguity. Minor gap is the absence of any note about how limit interacts with the date range.

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

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

Schema coverage is 75% and documents date formats and activity_type examples, but the description adds real value by clarifying the effective default window (last 30 days) that the null-valued date params otherwise leave ambiguous. The limit parameter's interaction with that window is unstated.

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

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

States a specific verb+resource (lists activities) and enumerates the per-row fields returned, plus sort order. It does not distinguish itself from siblings like get_activity or get_day_detail, so an agent must infer that this is the bulk-list counterpart.

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

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

'Defaults to the last 30 days' gives a useful operating context but there is no explicit when-to-use guidance or named alternative for fetching a single activity or a day's detail.

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