fitbit

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

Annotations already declare readOnlyHint=true, so the safety profile is covered externally. The description adds only the REST endpoint mapping, which is useful for orientation but does not disclose return shape, pagination, or rate-limit behavior beyond what the annotation implies.

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 data description front-loaded and the REST reference trailing. Every clause is relevant, though the REST path adds marginal value for an agent that cannot call HTTP directly.

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 read-only, single-enum-parameter tool with no output schema, the description gives enough to select and invoke it correctly. The only real gap is the absence of routing guidance against the many sibling activity 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?

Sole parameter 'period' is fully documented in the schema (100% coverage) including its enum values, so the schema does the heavy lifting. The description merely restates 'daily or weekly period' and adds no syntax or format detail beyond the 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 names the specific resource (the user's activity goals) and enumerates the goal types (steps/distance/calories/active-minutes) and periods, so an agent knows exactly what data comes back. It is clear, though it does not explicitly contrast itself with neighbors like fitbit_daily_activity_summary or the time-series 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?

There is no when-to-use guidance and no mention of alternatives, despite a crowded sibling set of activity-related tools. Usage is only implied by the resource description, which leaves the agent to infer when this beats fitbit_daily_activity_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?

readOnlyHint=true already covers the safety profile, so the bar is lower. The description adds a genuine constraint (max 1095 days) and the underlying REST route, but says nothing about pagination, rate limits, or result ordering.

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 compact clauses with zero filler: scope+example, hard limit, and exact route. Front-loaded with the operation and its constraint.

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?

No output schema exists, but 'time series' plus the REST route conveys the return shape well enough for a 3-param, fully-documented read tool. Only the precise response structure is left implicit.

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 resource enum, date patterns and 'today' handling are already documented. The description's REST path echoes the parameters but adds no new per-parameter meaning, 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 (fetch) and resource (activity metric time series over a date range), with a concrete example ('daily steps for a week'). It is reasonably distinguishable from siblings like fitbit_daily_activity_summary by emphasizing a multi-day range, though it never names or contrasts a sibling 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?

Usage is only implied: it is a range-based metric fetch, and the max-1095-days limit hints at scope. There is no explicit when-to-use vs alternatives (e.g. daily summary vs time series vs lifetime stats) and no stated exclusions.

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=true, so safety is covered. The description adds the underlying REST endpoint (GET /1/user/-/body/log/fat/date/{date}.json), reinforcing the read semantics, but discloses nothing about return format, empty-result behavior, or units beyond what annotations and schema supply.

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 short sentences, front-loaded with the resource and scope. The REST path sentence is mildly redundant with the name/title but is compact and earns some value as an endpoint reference.

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 single-parameter read tool with safety covered by annotations and format covered by the schema, the description is largely sufficient. It omits any hint about the returned entry structure, but with no output schema the burden there is low.

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% with a single required date parameter that already documents the yyyy-MM-dd or 'today' format via pattern. The description adds no parameter detail beyond the schema, so the baseline of 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?

The description states a specific resource (body fat percentage log entries) scoped to a date, which distinguishes it from sibling log tools like fitbit_weight_log or fitbit_water_log. The verb is only implicit (retrieval via GET), but the mapping 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?

There is no explicit when-to-use guidance or routing to alternatives. The agent must infer that this tool is for body fat data specifically versus the many other Fitbit log siblings; nothing is said about when-not to use it or which sibling covers adjacent metrics.

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?

readOnlyHint=true already declares this a safe read. The description adds only the raw Fitbit REST path, which conveys no behavioral context such as data availability, latency, or what an empty response means. It does not contradict the annotation but contributes nothing beyond structured fields.

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 short sentences, front-loaded with the purpose before the API detail. Every phrase carries weight, though the REST path is largely redundant with the tool's name.

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 read-only metric fetch with fully documented params and no output schema, the definition is nearly sufficient. The main gap is the absence of any guidance on interpreting or using the returned breathing-rate data.

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 both parameters are already documented with format and optionality; the baseline applies. The description does not add any format or edge-case meaning beyond the 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?

States a specific verb and resource: a breathing (respiratory) rate summary, scoped to a date or range. An agent can tell what it returns, but it does not differentiate itself from the other metric siblings (heart_rate, hrv, spo2) beyond the resource name.

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 'for a date or range' implies the input shape but gives no when-to-use versus alternatives guidance. There is no indication of when to prefer this over fitbit_hrv or fitbit_skin_temperature, and no prerequisites or exclusions are 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=true, so safety is covered. The description adds the upstream REST path and confirms a JSON read, but discloses nothing further about rate limits, empty/missing data on days without a score, or what the returned estimate looks like.

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 metric and its scope come first, and the endpoint reference is secondary. Every clause carries 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?

For a two-parameter read-only metric lookup with annotation-covered safety and full schema coverage, nothing essential to calling it is missing. Since there is no output schema, a brief note on what the score response contains would have closed the remaining gap.

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%, with both 'date' and 'endDate' documented including format and optionality, so the baseline is 3. The description only restates that a range is possible and adds no format or edge-case detail beyond the 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?

Names a specific resource and metric ('Cardio fitness score (VO2 max estimate)') plus the supported access patterns (single date or range), which cleanly separates it from siblings like fitbit_heart_rate and fitbit_hrv. It does not explicitly name or contrast with any sibling, so it stops short of a 5.

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 'for a date or range' implies the two call modes (single date vs. date+endDate) but never states when to prefer one over the other, nor any alternatives or prerequisites. Usage is inferable rather than spelled out.

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?

The readOnlyHint annotation already establishes this is a safe read, so the description's burden is lower. It adds the underlying Fitbit REST path, which is genuinely useful for an agent reasoning about upstream behavior, but says nothing about auth requirements, rate limits, or how missing/partial days are handled.

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 tightly packed clauses with the resource and scoping constraint front-loaded and no filler. The trailing REST endpoint is slightly redundant but still informational rather than wasteful.

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 no output schema, the description usefully enumerates the returned metrics (steps, distance, floors, calories, active minutes, logged activities), which is exactly the information an agent would otherwise lack. It is nearly complete for a single-parameter read tool, missing only failure/empty-day handling.

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 the single required 'date' parameter is fully documented (format plus 'today'), so the schema carries the burden. The description's 'for a date' adds no syntax or constraint detail beyond that, making the baseline 3 correct.

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 (daily activity summary) scoped to a single date and enumerates the returned metrics, so the agent knows exactly what this tool retrieves. It distinguishes itself implicitly from siblings like fitbit_activity_time_series by the 'for a date' framing, but 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?

Usage is implied by the single-day scoping ('for a date'), which contrasts with the time-series sibling, but the description offers no explicit when-to-use/when-not guidance or named alternatives. An agent can infer intent but receives no routing help.

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=true, so the safety profile is covered. The description usefully discloses return content (logged foods, calorie/macro totals) but says nothing about auth requirements, rate limits, empty-day behavior, or historical limits.

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 compact clauses: purpose/return content first, REST endpoint second. No filler, and the useful information is front-loaded.

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 no output schema, the description carries the burden of describing return values, and it does so (logged foods and daily totals). Only minor gaps remain around edge cases like days with no logged food.

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 the single date parameter is fully documented with pattern and 'today' handling. The description adds no syntax or format detail beyond the schema, 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 resource (food/nutrition log) and scope (per date), and names what it returns — logged foods plus daily nutrition totals. Clearly distinguishable from siblings like fitbit_water_log and fitbit_weight_log.

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 date-scoped framing implies retrieval usage, but there is no explicit when-to-use, when-not, or routing to related tools (e.g. water log for hydration). Usage 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds useful context by naming the return fields and the underlying REST endpoint, but says nothing about pagination, rate limits, or behavior when the account has no devices. With annotations covering safety, the added value is moderate.

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 purpose and returned fields front-loaded; the REST endpoint reference is compact and non-redundant. 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?

For a parameterless read with no output schema, the description supplies the key return fields an agent would otherwise lack. It is essentially complete, with only minor gaps around pagination or empty-account behavior.

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, so there is nothing for the description to disambiguate. Baseline 4 applies; the description cannot add or detract meaningfully here.

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) and resource (Fitbit devices/trackers), and enumerates the returned content (battery, last sync, version). It is clearly distinguishable from all siblings, which are metric/log endpoints, so an agent can tell what it does without opening the schema.

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 by the resource – list the account's registered devices – but there is no explicit when-to-use or when-not-to-use guidance, and no named alternative. Since no sibling covers device enumeration, there is no real alternative to route to, keeping this merely adequate.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating call. The description adds useful context by enumerating the returned fields and citing the underlying REST endpoint, but says nothing about auth requirements, rate limits, or whether the profile can ever be empty.

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: resource identity first, then the field list and endpoint reference. Nothing is redundant and no sentence 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 no output schema, the description appropriately compensates by listing what the profile contains. It is nearly complete, lacking only incidental details such as auth scope or whether the response can be cached, which are minor for a zero-param read.

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, so the baseline is 4. The description correctly implies no input is required by framing this as fetching 'the current user's' profile ('- ' in the REST path), but there is no schema-level content for it to add to.

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 (get) and resource (the current user's Fitbit profile), and enumerates the fields returned (name, age, gender, height, timezone, member since, avatar). This differentiates it from all sibling tools, which are activity/sleep/body-data logs rather than account metadata, though it does not name a sibling 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?

Usage is implied rather than stated: an agent infers this is the tool for account/profile metadata. There is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives, but for a zero-parameter metadata read the alternatives space is narrow.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds that results are a time series and gives the underlying REST endpoint, but discloses nothing about rate limits, auth scope, or response shape.

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 clauses: what it returns, how to parameterize it, and the underlying REST path. The key calling rule is front-loaded with zero 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 3-param read tool with full schema coverage and a readOnlyHint, this is nearly complete — the agent knows the resource, the inputs, and the two mutual-exclusive modes. Only the absence of any note on returned granularity/pagination keeps it from a 5.

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 baseline is 3; the schema already documents date, the period enum, its default, and that endDate overrides period. The description restates the period/endDate exclusivity rather than adding format or edge-case detail.

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 (heart-rate time series) and enumerates the concrete contents (resting HR, time in each HR zone). It is also clearly distinguishable from the closest sibling, fitbit_hrv, which covers variability rather than HR zones.

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 disambiguates the two calling modes — 'single date + period, OR a date + endDate range' — which is exactly the decision an agent must make before invoking. It stops short of naming an alternative tool or when-not-to-use, but the parameter-mode guidance is concrete.

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?

readOnlyHint=true is already supplied by annotations, and the REST GET endpoint reinforces the read-only nature. Beyond that, it discloses no return shape, pagination, quota, or data-availability context, which for a read tool is acceptable 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?

Two tight sentences, front-loaded with the resource and purpose, followed by the underlying endpoint. 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?

For a read-only metric tool with full parameter coverage and annotations covering safety, the description supplies enough to call it correctly. It does not describe the returned HRV fields, but no output schema is required and this is a minor gap.

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%, with both date and endDate fully documented including format and optionality. The description adds only the notion that endDate enables a range, so baseline 3 applies where the schema does the heavy lifting.

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 resource (Heart rate variability / HRV) and action (summary) with clear scope (a date or range). It is distinguishable from siblings like fitbit_heart_rate or fitbit_breathing_rate by its unique metric. It stops short of explicitly contrasting with siblings, hence a 4.

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 'for a date or range' implies the calling context (single-day vs range queries), but there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. Usage is only implied.

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?

The readOnlyHint annotation already establishes this as a safe, non-mutating read, so the description's burden is reduced. It adds the underlying REST path (GET /1/user/-/activities.json) and confirms the scope is lifetime/aggregate rather than a time window, but says nothing about auth requirements, rate limits, caching, or how 'lifetime' is bounded for a given account.

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 compact sentences, front-loaded with the what before the implementation detail. The trailing REST endpoint reference is of limited value to an agent deciding whether to call the tool, which keeps this just short of a 5, but nothing is padded or redundant.

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 no output schema, the description carries the job of indicating what comes back, and it does so by listing the statistic families (steps, distance, floors, personal bests). For a parameterless read tool that is close to sufficient; a note on whether results are keyed per-account or include timestamps would make it fully 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 tool takes zero parameters, so there is nothing for the description to disambiguate and the schema cannot be under-documented. Baseline credit applies; the description correctly signals that no filtering or date input is expected.

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 verb+resource combination — 'Lifetime and best-ever activity statistics' — and enumerates the metric families (total steps, distance, floors; personal bests). It is clear what the tool returns. However, it never distinguishes itself from the closest sibling, fitbit_daily_activity_summary, other than by the word 'lifetime', leaving the agent to infer the 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?

Usage is only implied: 'lifetime and best-ever ... total' suggests one should call this for all-time aggregates rather than a bounded window, which is meaningful against siblings like fitbit_activity_time_series. But there is no explicit when-to-use, when-not-to-use, or named alternative, so selection still requires 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds the genuinely useful behavioral note that values are 'relative to baseline' (not absolute readings), but omits return format, data availability, or rate-limit context.

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 compact sentences, front-loaded with the resource and the baseline qualifier. The trailing REST endpoint reference is arguably redundant for an agent but is short and does not obscure the meaning.

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 read-only fetch with a fully documented schema and no output schema, the description covers resource, scope, and the baseline-relative semantics. It could note empty-data behavior, but nothing essential for calling the tool 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 100%, with both 'date' and 'endDate' fully documented including format and optionality, so the baseline is 3. The description adds no parameter 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?

States a specific resource (skin temperature) and scope (for a date or range), and adds the important qualifier 'relative to baseline' that distinguishes what the value means. It does not explicitly differentiate from sibling metric tools, but each sibling covers a distinct metric so confusion is unlikely.

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 'for a date or range' hints at usage, but there is no explicit when-to-use, when-not-to-use, or reference to any alternative tool. The agent must infer context from the name alone.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the Fitbit REST endpoint and scope (single date vs range), but says nothing about rate limits, pagination, or error behavior for the API path.

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 tightly packed sentences with zero filler; the payload description is front-loaded and the REST endpoint is relegated to a supporting clause.

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 no output schema, the description usefully enumerates what a sleep log contains, which compensates for the missing return schema. Only rate-limit and pagination behavior remain unstated, which is minor for a read-only log 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 100% and the schema documents both parameters including the max 100-day range constraint. The description's 'date (or date range)' maps to the two params but adds no format or constraint detail beyond the schema, so 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 and resource ('Sleep logs for a date') and enumerates the returned fields (stages/levels, duration, efficiency, start/end). The sleep resource is naturally distinct from the activity, heart-rate, and weight siblings, 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 parenthetical '(or date range)' implies the two calling modes, but there is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as other time-series sleep tools. Usage 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 declare readOnlyHint=true, so the read-only nature is covered. The REST endpoint syntax adds mild confirmation that this is a GET, but the description says nothing about response shape, data granularity, or availability limits beyond the annotation baseline.

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 short sentences, resource and scope front-loaded, with zero filler. The REST endpoint string is optional reference material that adds minor length without harm.

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 read-only summary tool with full schema coverage and no output schema to explain, the description covers the essentials. It leaves the choice between single-date and range queries and the nature of the returned summary unaddressed, which is a modest but real gap.

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%, with both 'date' and 'endDate' documented with formats and required/optional status in the schema. The description's URL template echoes the same date/endDate structure but adds no format or edge-case detail beyond the schema, 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 resource (blood oxygen saturation / SpO2) and scope (summary for a date or range), plus the exact REST endpoint backing it. The resource is unmistakably distinct from siblings like fitbit_heart_rate, fitbit_hrv, and fitbit_breathing_rate.

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 'for a date or range' implies how to choose between the single-date and ranged call, but there is no explicit when-to-use guidance, no mention of which sibling to prefer for other oxygen-adjacent metrics, and no prerequisites 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?

The readOnlyHint annotation already establishes this is a safe read, so the description is not carrying the safety burden. It adds the concrete endpoint (GET .../date/{date}.json), which hints the '-' segment is the authenticated user, but says nothing about what the response contains or whether an empty day returns an error.

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 short sentences with the purpose front-loaded before the endpoint reference. Efficient, though the raw REST path is arguably redundant scaffolding for an agent that only needs the semantic intent.

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 trivial one-parameter read tool whose safety profile is covered by annotations and whose parameter is fully described in the schema, the description is essentially sufficient. Only the missing guidance on date/response behavior keeps it from being fully 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?

Schema coverage is 100% and the single date parameter is fully documented (yyyy-MM-dd or 'today'), so the baseline is 3. The description only restates the same date concept via the URL template and adds no format or edge-case detail beyond the 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?

States the resource (water intake log) and scope (for a date), and the REST endpoint confirms it is a retrieval. It distinguishes itself from the many other *_log siblings (food_log, sleep_log, weight_log) by naming the water resource, though it never explicitly frames the verb as 'retrieve' vs 'create'.

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 versus fitbit_food_log or the other log tools, no mention of date-range constraints, and no note that this requires an authenticated user ('-' placeholder is unexplained). The agent must infer usage entirely from 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?

Annotations already declare readOnlyHint=true, and the embedded REST verb GET corroborates a safe read. The description adds the date-scoped nature of the call but says nothing about volume, pagination, or whether multiple entries per day are possible.

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 short sentences, front-loaded with what is returned, followed by the endpoint for reference. No filler and nothing redundant.

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 one-parameter read-only lookup with annotations covering safety and the schema covering the date format, this is nearly complete. The only minor gap is that return shape is only implied by the phrase 'log entries'.

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 the pattern/enum value 'today' is fully documented in the schema, so the description provides no meaning beyond it. Baseline 3 applies when the schema does the heavy lifting.

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 resource and scope: weight log entries for a given date, resolved via a named REST endpoint. An agent can distinguish it from fitbit_body_fat_log and fitbit_water_log by the resource noun, though it never names those siblings 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g. body fat or water logs). The date parameter implies a single-day lookup, but the agent must infer that on its own.

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