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

With no annotations, the description carries the behavioral disclosure burden. It does disclose that the operation returns a list of activity summaries and explains pagination semantics. However, it omits any mention of authentication prerequisites, session requirements, rate limits, or side effects—though 'list' implies a read-only operation.

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 two sentences with no superfluous content. It front-loads the purpose, then efficiently covers parameter semantics and return contents. The trailing 'etc.' is minor and acceptable given the output schema.

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 only two optional parameters and an output schema, so the core pagination and return-value context is adequately covered. However, the absence of annotations combined with a likely authentication dependency—suggested by sibling tools like garmin_login and garmin_resume_session—leaves a meaningful gap. An agent would benefit from knowing whether a session must be established before calling this tool.

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 0%, but the description fully compensates by defining both parameters: 'start: index to start from, limit: max number to return.' This adds meaningful semantics that the raw input schema lacks.

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 starts with a clear verb and resource: 'List activities from Garmin Connect.' It identifies the tool's core purpose and the returned fields, making it distinct from likely siblings like garmin_activity_details. However, it does not explicitly name or contrast any sibling, so it falls short of full differentiation.

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 intended use is implied by 'List activities' and the start/limit pagination parameters, so an agent can infer this is for browsing activity summaries. But the description provides no explicit guidance on when to choose this tool over alternatives like garmin_activity_details, garmin_activity_types, or garmin_daily_summary.

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?

No annotations are present, so the description carries the full burden. It clearly conveys a read-only lookup and lists what the response includes, but it does not mention authentication/session dependencies or error behavior. Adding those would strengthen transparency.

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 three short sentences with no filler. The main action is front-loaded, the return contents are summarized compactly, and the prerequisite workflow is stated in the final sentence.

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?

For a single-parameter read tool with an output schema, the description covers what the tool returns and how to obtain the required ID. It could mention authentication prerequisites, but the workflow and output schema make the definition reasonably complete.

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 input schema has no parameter descriptions (0% coverage), but the description adds meaning by identifying activity_id as the lookup key and pointing to garmin_activities as the source for valid values. It does not explain the integer/string format nuance, but for a single obvious ID this is acceptable.

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 opens with a specific verb and resource: 'Get full details for one activity by ID,' and clarifies scope by listing activity types and included data (summary, splits, metadata). This makes it easy to distinguish from sibling tools like garmin_activities or garmin_daily_summary.

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 description explicitly tells the agent to use garmin_activities first to obtain valid activity_id values, which is a clear prerequisite and usage flow. It does not enumerate exclusion conditions against every sibling, but the by-ID detail scope makes those unnecessary.

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?

No annotations are present, so the description carries the full disclosure burden. It correctly conveys a read-only catalog enumeration, which is self-evident from 'List all ... with type IDs and keys.' However, it doesn't disclose whether authentication is required or describe any limits or output shape beyond the fields mentioned — adequate for a simple lookup but not rich.

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 front-loaded sentence that names the verb, resource, examples, and output fields with zero filler. Every clause 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?

For a zero-parameter catalog lookup, the description combined with the existing output schema is nearly complete. The only notable gap is the absence of any statement about auth or session requirements on a tool that sits alongside garmin_login, but this is a minor omission for such a simple operation.

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 has zero parameters and 100% schema coverage, so the baseline is 4. The description adds value by specifying what returned entries contain (type IDs and keys), which orients the agent even though there is nothing to configure on input.

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 ('List'), a clear resource ('Garmin activity types'), and the expected output fields (type IDs and keys). The examples (running, cycling, strength_training) make the scope self-evident. It doesn't explicitly disambiguate from siblings like garmin_activities or garmin_activity_details, but the catalog-vs-records distinction is implicit in 'activity types ... with type IDs and keys.'

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 guidance on when to use this lookup versus sibling tools such as garmin_activities (the user's actual activity log) or garmin_activity_details. No mention of prerequisites such as login, even though a garmin_login sibling exists.

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?

There are no annotations, so the description carries the full behavioral burden. It transparently reveals that this is a raw arbitrary-path passthrough and documents GET/POST plus optional body. However, it omits important behavioral context such as authentication requirements, error behavior, and the potential side effects of a POST to an arbitrary endpoint.

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 compact and front-loaded: first sentence states the core purpose, second sentence gives the usage rule, and the parameter lines add just enough detail. No wasted words.

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 output schema covers return-value structure, and the description covers path, method, and body. However, for an arbitrary raw API tool, it should at least mention prerequisites like an active Garmin session/login and the absence of endpoint validation, both of which matter for correct invocation.

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 0%, so the description must compensate, and it does. It provides concrete path examples, states valid methods (GET or POST), and explains that body is an optional JSON string for POST. This adds meaningful semantics beyond the raw schema fields.

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 the tool's specific verb and resource: 'Call the Garmin Connect API at an arbitrary path.' It also differentiates itself from the specialized sibling tools by explicitly positioning itself as the fallback for 'endpoints not wrapped by other tools,' so an agent can distinguish when to use this tool.

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 description gives an explicit usage rule: use for endpoints not wrapped by other tools. This provides a clear when/when-not boundary. It doesn't name specific sibling alternatives, but the rule itself covers all the specialized siblings as a category.

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?

With no annotations, the description carries the behavioral burden. It clearly states that the tool returns both local and UTC datetime variables and gives a concrete format example (YYYY-MM-DD). It does not explicitly mention side effects, but 'Return' and the utility framing make it evident this is a read-only operation.

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. The core behavior is stated first, followed by practical usage guidance. Every sentence 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?

For a zero-parameter tool with an output schema and a focused purpose, this description is complete. It explains what the tool returns, the relevant time scopes (local and UTC), and how the result should be used.

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?

There are zero parameters, so the schema carries no burden and the baseline is 4. The description adds useful supporting meaning by showing how the returned values are meant to be consumed, including the YYYY-MM-DD format pattern for day/sleep/weight tools.

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 uses a specific verb ('Return') with a clear resource ('current date and time variables (local and UTC)'). It also positions the tool as a date/time utility for other Garmin tools, making it easy to distinguish from data-heavy siblings like garmin_daily_summary or garmin_activities.

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?

It explicitly states when to use the tool: 'Use for building date ranges or passing today's date to other Garmin tools'. It does not discuss exclusions or alternatives, but for a simple utility tool with no obvious sibling competitor, this is clear context.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. The verb 'Get' implies a read-only operation, and the output list communicates what is returned, but the description does not mention prerequisites such as login/session state, timezone semantics, or what happens when no data exists for the day.

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 efficient sentence that front-loads the tool's purpose and then lists the returned metrics. The biomarker list is long but compact and each item is relevant; the parameter guidance is appended clearly.

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 output schema covers return structure, and the description covers the day parameter format, so the core call is clear. However, the description omits usage routing among siblings and session prerequisites, which are relevant given the nearby garmin_login and garmin_resume_session 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 0%, but the description adds the 'day: YYYY-MM-DD' format, giving the only parameter the meaning that the schema alone lacks. It does not specify allowed date ranges or timezone handling, but for a single simple parameter this is adequate.

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 uses a specific verb ('Get') and a clear resource ('one-day wellness summary'), then enumerates the covered biomarkers. This makes it immediately distinguishable from siblings like garmin_activities, garmin_resting_heart_rate, and garmin_summary_report.

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 phrase 'one-day' implies the tool is for a single-day summary, but the description gives no explicit when-to-use guidance or exclusions. It does not name any sibling alternative or explain when to prefer garmin_stats or garmin_summary_report instead.

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?

With no annotations provided, the description carries the full behavioral disclosure burden. It does a good job explaining mode-dependent behavior, date defaults, range limits, and data_type-specific restrictions. It does not mention session/auth requirements, rate limits, or error behavior, but the read-only nature and core behavioral modes are well disclosed.

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 well structured: a one-line purpose, parameter definitions, mode explanation, a relevant constraint note, and useful examples. Each component earns its place, and the most important operational distinction (single-day vs. list) is clearly highlighted.

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?

Given the output schema, return values do not need to be described, and the input parameters and behavioral modes are thoroughly covered. The only notable gap is the absence of any mention of session/auth prerequisites, especially since garmin_login and garmin_resume_session are 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 0%, so the description must fully compensate, and it does. Every parameter is explained with format, defaults, and behavior: data_type enumerates valid values, 'day' specifies single-day mode, and end_date/days define list-mode range. Examples further clarify realistic usage.

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 the action ('Fetch detailed health data') and the resource ('Garmin Connect'), and the data_type list defines the scope of what this tool returns. It is distinguishable from siblings by its focus on sleep, hrv, weight, and body battery data, though it does not explicitly contrast itself with sibling tools.

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 description provides clear operational guidance: single-day mode when 'day' is provided, list mode when omitted, default values for end_date and days, and the constraint that body_battery_events and body_battery_stress only support single-day mode. It does not mention alternatives or when to prefer another Garmin tool, so it stops short of a 5.

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?

No annotations exist, so the description carries the full burden. It clearly discloses the side effect of sending an email, the required SMTP credentials, SSL/STARTTLS behavior, and the HTML/plain-text fallback. This is substantial behavioral context for a sending tool.

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 organized into a purpose line, parameter list, environment variables, and content scope, making it scannable. The only weak point is the trailing all-caps 'FOCUS MORE...' sentence, which is vague and not actionable for tool selection or invocation.

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?

For a tool that connects to SMTP and sends email, the description covers parameters, env prerequisites, content coverage, and message format. It does not explain return values, but an output schema exists and can cover that; no critical call-blocking information is obviously missing.

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 input schema only provides types and defaults, but the description fully documents all four parameters: period options and default, end_date format and default, comma-separated recipients, and subject behavior. It also maps defaults to SMTP_TO, which the schema cannot express.

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 uses a specific action ('Generate a Garmin summary report and email it via SMTP') and names the resource and delivery mechanism. The email/summary content list and SMTP framing distinguish it from sibling reporting tools like garmin_summary_report, even though no sibling is named 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?

The description provides prerequisites (SMTP env vars) and parameter defaults, so an agent knows how to invoke it correctly. However, it gives no explicit guidance about when to prefer this tool over siblings such as garmin_summary_report or garmin_daily_summary; usage context is implied 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It explicitly discloses the key side effect: saving the session to a given path, with a default of ~/.garth, and explains the consequence for later session reuse.

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 no wasted words. The first states the core action, and the second adds the essential side effect and default path. It is well front-loaded and easy to parse.

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?

For a simple login tool, the description covers the key operational details: credentials, session persistence, default path, and the path to later session reuse. The presence of an output schema means return-value details are not required in the description.

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 0%, so the description must compensate. It mentions email and password, and adds meaning to session_path by explaining the default path (~/.garth), which clarifies the schema's empty string default. The params are simple enough that this is sufficient.

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 states a specific verb ('Log in'), the target system ('Garmin Connect'), and the required credentials ('email and password'). It also differentiates itself from siblings like garmin_resume_session by explaining that the session is saved for later reuse.

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 description clearly implies when to use this tool: as the initial authentication step before using resume_session. It does not spell out 'use this when no session exists,' but the saved-session note gives an agent enough context to choose it correctly.

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?

With no annotations, the description carries the full disclosure burden. 'Fetch' indicates a read operation and the metric list scopes the behavior, but the description does not mention required authentication/session, rate limits, error behavior, or what happens when Garmin data is unavailable.

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 first sentence conveys the core purpose, followed by a compact parameter reference and three illustrative examples. There is no filler or repetition; every sentence contributes useful 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?

The tool has no annotations but does have an output schema, so return-value details are already covered. The description is complete for selecting parameters and forming calls, though it leaves minor gaps around Garmin session prerequisites and how this compares to sibling stat 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 0%, yet the description fully compensates by documenting all four parameters: metric values, period choices/default, end_date format/default, and count meaning/default. The examples further clarify valid combinations.

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 opens with a specific action and resource: 'Fetch daily or weekly stat series from Garmin Connect,' and it enumerates the supported metrics. It clearly conveys what the tool does, but it does not explicitly differentiate it from sibling tools like garmin_stats or garmin_daily_summary.

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 description provides clear invocation context: metric choices, period default, end_date format/default, and count default, reinforced by three concrete examples. It does not list exclusions or alternative sibling tools, but the usage context is explicit enough for correct selection in most cases.

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?

With no annotations provided, the description carries the full disclosure burden. It does disclose return content (daily RHR plus an optional 7-day average) and the metricId 60 convention, both genuinely beyond the schema. However, it stays silent on prerequisites (e.g., whether garmin_login must precede a call), error behavior, and what actually triggers the 7-day average.

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 dense sentences with zero redundancy: purpose first, then date format/default, then return format and metricId. Every sentence earns its place and the tool is easy to scan.

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 presence of an output schema lowers the burden for explaining return values, and the two optional parameters are simple types. But the description leaves a real gap on what days controls and never hints that a login/session (sibling tools garmin_login and garmin_resume_session exist) is likely a prerequisite. Adequate, but an agent must guess on these points.

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 0%, so the description must compensate. It fully specifies end_date's format (YYYY-MM-DD) and default (today), but the days parameter's meaning is only implied via “optional 7-day average” and the schema's default of 7. Whether days=7 produces the average or days sets an arbitrary window is never clarified.

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?

"Get resting heart rate (RHR) for one or more days" pairs a specific verb with a precise resource and scope, and the metricId 60 detail adds useful domain specificity. However, it never names or contrasts with overlapping siblings like garmin_daily_summary or garmin_data, so an agent must infer the boundary rather than having it stated.

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 description implies when to use this tool (whenever RHR is needed) and gives operational guidance (“end_date: YYYY-MM-DD or omit for today”), but it provides no explicit when-not-to-use direction or named alternatives among the 16 siblings. Selection guidance is left entirely to inference.

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?

With no annotations, the description carries the burden of behavioral disclosure. It usefully states that the tool loads a session from disk, uses a default path, and makes other tools authenticated. However, it does not describe side effects such as whether it overwrites the current in-memory session, validates session freshness, or what happens if the session file is missing or expired.

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 two short sentences with no filler. The core action is front-loaded, and the usage context plus default path are stated efficiently. Every sentence 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?

The tool is simple: one optional parameter, no annotations, and an output schema exists. The description covers the main purpose, when to use it, and the default path. It could be more complete by mentioning the fallback to garmin_login when no valid session is saved, but the description is adequate for a tool of this complexity.

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 schema provides only a string parameter with a default of empty string and 0% description coverage, so the description must compensate. It adds the meaningful detail that the default path is ~/.garth, which likely corresponds to session_path, but it does not explicitly describe the parameter's meaning or format. This is partial compensation for the schema gap.

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 the action: resume a previously saved Garmin session from disk. It identifies the resource (saved session) and the tool's role in authenticating subsequent calls. It does not explicitly contrast itself with garmin_login, but the phrase 'previously saved session from disk' makes the distinction reasonably clear.

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 description explicitly instructs to use this tool (or set GARTH_SESSION_PATH) before calling other tools, which gives clear operational context. It identifies an alternative setup method but does not explicitly describe when not to use it, such as when no saved session exists or when a fresh login is needed.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It explains the kinds of operations and their parameter requirements, but it does not explicitly state whether the tool is read-only, what it returns, or how it handles null or misaligned inputs. The presence of an output schema reduces the return-format gap, but side-effect behavior is still implicit.

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 well organized with general parameters, operation-specific parameters, and examples. It is longer than average, but every section earns its place given the tool's 10 parameters and 6 operation modes, with no redundant 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?

For a tool with this many operations and parameters, the description is nearly complete: it covers all parameters, per-operation requirements, defaults, and realistic examples. It could additionally clarify null-value handling and the relationship between labels and values, but the output schema covers return expectations.

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 0%, so the description must compensate, and it does thoroughly. Every parameter in the schema is explained with operation-specific meaning, required status, defaults, and valid choices. The examples further clarify how to combine parameters for different analyses.

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 the tool performs statistical analysis on numeric data and enumerates the six supported operations. It is easy to understand what the tool does, but it does not explicitly distinguish itself from overlapping siblings such as garmin_metric, garmin_data, or garmin_viz.

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 description gives useful operation-specific usage guidance, including required parameters and defaults, plus examples. However, it never states when to prefer this tool over alternatives or when not to use it, leaving sibling differentiation to inference.

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?

With no annotations provided, the description must disclose behavioral traits itself, and it does usefully list the returned metric categories and period semantics. However, it does not mention whether an authenticated Garmin session is required, which is relevant given the garmin_login and garmin_resume_session siblings, nor does it state side effects; this appears to be a read-only report operation but that is not explicit.

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 compact and front-loaded: purpose first, then parameter semantics, then output scope. The metric list is somewhat long but earns its place by communicating exactly what the summary contains, with no meaningless 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?

Parameter semantics and output scope are well covered, and the presence of an output schema reduces the need to explain return values. Still, the description lacks explicit guidance on session/authentication requirements and does not differentiate this tool from similarly named sibling tools like garmin_daily_summary or garmin_stats.

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 0%, and the JSON schema provides no enum constraints, but the description fully documents both parameters: period with four explicit values and end_date with format and default behavior. This adds critical meaning beyond the structured schema.

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 states a specific verb and resource: 'Generate a comprehensive summary of all essential biomarkers and activity stats,' and elaborates with a concrete list of included metrics and period options. However, it does not explicitly distinguish itself from sibling tools such as garmin_daily_summary or garmin_stats, so some overlap risk remains.

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 description provides clear parameter usage for period and end_date, including allowed period values and the default end date, which gives an implied use context. It does not explicitly explain when to choose this tool over garmin_daily_summary, garmin_stats, or other siblings, nor does it state any exclusion criteria.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation through the verb 'Get,' but it does not mention authentication requirements, whether an active session is needed, or any other behavioral context like rate limits or data freshness.

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, front-loaded sentence with the core action and resource stated first, followed by a compact parenthetical of example fields. Every word earns its place with no redundancy or 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?

The tool has no parameters and an output schema exists, so return values are already specified elsewhere. However, the description does not mention the likely prerequisite of being logged in, nor does it clarify the boundary with user_settings, leaving minor but real gaps for an agent deciding how to use it.

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 input schema is empty and schema description coverage is 100%, so there are no parameters to document. The description adds useful context by framing the tool as operating on the current user's profile, making it clear that no arguments are required.

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 the action ('Get') and the resource ('current user's Garmin Connect profile'), with concrete examples like display name, timezone, and activities. It is clear and distinct from a generic stats or settings tool, though it does not explicitly differentiate itself from siblings such as garmin_user_settings.

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?

There is no guidance on when to use this tool versus alternatives like garmin_user_settings, garmin_stats, or garmin_daily_summary. The description implies it is for retrieving the current user's profile, but it offers no context, exclusions, or alternative routing.

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?

No annotations are provided, so the description carries the disclosure burden. 'Get' conveys a read-only operation, and 'settings' indicates non-destructive behavior, but authentication/session prerequisites are not mentioned. It adds some behavioral context but not enough for full transparency.

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 front-loaded sentence with no wasted words. The verb and object appear immediately, and the parenthetical is the only elaboration.

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?

For a no-parameter read tool with an output schema present, the description covers the core purpose and scope. The only meaningful gap is the unstated requirement that a user session must already exist via tools like garmin_login or garmin_resume_session.

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 input schema has zero parameters, so the baseline is 4 and there are no parameters to document. The parenthetical about units and preferences adds useful context about what the returned settings 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 states a specific verb ('Get') and resource ('current user's Garmin Connect settings') with clarifying examples ('units, preferences'). It is clear, but it does not explicitly differentiate from sibling tools such as garmin_user_profile, so it falls just short of full sibling distinction.

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 description signals its context—use when the current user's settings or preferences are needed—but it provides no explicit when-not-to-use guidance or named alternatives. Usage is implied rather than specified.

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?

With no annotations, the description carries the behavioral disclosure burden. It explicitly says the tool renders a chart, returns the image inline, and provides a saved file path—covering the key behavioral outcomes. It does not discuss side effects like file overwriting, but for a visualization tool this 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?

The description is lengthy but every section earns its place: purpose first, then common params, type-specific params, and concrete examples. The grouped, scannable structure makes it easy for an agent to find the relevant chart-type details without wading through irrelevant 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?

Given 12 parameters and 7 chart types, the description is remarkably complete: it covers all parameter combinations, provides default behavior for bins, and gives example calls for every chart type. The output schema covers return-value structure, so no critical invocation detail is missing.

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 0%, so the description must compensate fully, and it does. It documents every parameter, distinguishes common from type-specific params, and clarifies how x, y, matrix, y_series, and labels apply per chart type. The examples further resolve ambiguity that the schema alone cannot.

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 states a specific verb ('Render a chart') and resource, and clarifies the output format (inline image plus saved file path). It is clearly distinct from sibling data-retrieval tools like garmin_data or garmin_stats, so an agent can tell exactly what this tool is for.

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 description gives clear context for when to use the tool—whenever a chart image is needed—and explains the supported chart types and their parameter requirements. It does not explicitly name alternatives or exclusion conditions, but the purpose is distinct enough among siblings that usage is unambiguous.

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