Fitbit MCP by usefulapi

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

The readOnlyHint annotation already establishes this as a safe read, so the bar is lower. The description adds the underlying REST route (GET /1/user/-/activities/goals/{period}.json), which confirms read semantics, but says nothing about auth, rate limits, or whether goals can be absent for a period.

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 substantive content front-loaded; nothing is padded. The raw REST path is arguably noise for an agent caller, which keeps this just short of a 5.

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 tool with no output schema, the description usefully enumerates the returned goal fields and the two periods, so an agent knows what to expect. Missing only edge-case behavior (e.g., absent goals), which is minor here.

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 enum parameter is fully documented, so the baseline is 3. The description restates the same 'daily or weekly' options 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 fields returned (steps/distance/calories/active-minutes) plus the two valid periods. It clearly distinguishes this from siblings like fitbit_daily_activity_summary, which reports actuals rather than goals, though it never names an alternative explicitly.

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

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

There is no statement of when to use this tool versus alternatives such as fitbit_daily_activity_summary or fitbit_lifetime_stats. The only usage signal is the required period parameter, which is already in the schema, so the agent gets no routing guidance.

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 declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral value beyond that: the 1095-day maximum range, which is a genuine invocation constraint, plus the underlying REST endpoint for traceability. It omits pagination/return-format detail, but the cap and read-only nature are the key facts.

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 sentences, front-loaded with the purpose, then the constraint, then the endpoint reference. No filler, though the raw REST path is slightly redundant for an agent that will not call it 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, three-parameter tool with full schema coverage and no output schema, the description supplies the purpose, an example, and the range cap. Return format is unspecified, but a time-series tool does not strictly require it 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 100%, and the parameters carry patterns, enums and semantics already. The description's example ('daily steps for a week') lightly reinforces how resource/dates combine, but adds no syntax beyond what the schema already documents. Baseline 3 applies.

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

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

States a specific verb+resource (activity metric time series over a date range) with a concrete example ('daily steps for a week'), which tells an agent exactly what it returns. It distinguishes itself implicitly from fitbit_daily_activity_summary by emphasizing a date-range series, though it doesn't name that 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?

Provides context (date-range series, example of a week) and a hard constraint (max 1095 days), but never says when to prefer this over fitbit_daily_activity_summary or fitbit_lifetime_stats. Usage is implied rather than directed.

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 description carries a lower burden. It adds the REST endpoint, confirming the data source and that it is a non-mutating GET, but says nothing about return shape, empty results, or data availability caveats.

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, front-loaded sentences with no filler; the resource scope comes first. The REST path in the second sentence is somewhat redundant metadata but is compact and aids cross-referencing with Fitbit docs.

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 with a readOnly annotation, the definition is nearly sufficient. However, there is no output schema, and the description does not indicate that the response is a collection of intraday entries with timestamps and values, leaving the return shape to inference.

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 'date' parameter whose format and 'today' alias are fully documented in the schema pattern. The description adds no syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

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

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

Names a specific resource (body fat percentage log entries) scoped to a date, and the REST path confirms it is a read of the body fat endpoint. It is distinguishable from siblings like fitbit_weight_log by resource, but never explicitly routes the agent between the two similar body-metric log 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, no statement of prerequisites (e.g., that data only exists when a body-fat-capable scale is synced), and no mention of alternatives such as fitbit_weight_log. Usage is only implied by the resource name.

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 read. The description adds the underlying REST endpoint (GET /1/user/-/br/date/...) for traceability, but discloses nothing extra about response shape, aggregation behavior, or data availability windows. With annotations carrying the safety profile, this is an adequate-but-thin addition.

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 front-loaded. The REST endpoint string is arguably redundant for an LLM caller but is compact and does not bury the core statement.

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?

There is no output schema, so the description carries some burden for describing what a 'breathing rate summary' returns (e.g., daily value, standard deviation, intraday breakdown), and it does not. The core contract — what it does and how to call it — is complete, but return-shape expectations are left unstated.

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 patterns in the schema. The description restates the date/range duality without adding syntax or semantics beyond what the schema provides, which is the expected baseline.

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-less but precise resource: 'Breathing (respiratory) rate summary for a date or range,' which is unambiguous and distinct from the sibling data domains (sleep, heart rate, spo2, hrv). It does not explicitly contrast itself with siblings, but the resource is specific enough that an agent can select it.

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 invocation modes, but there is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives or when a range is preferred over a single day. The agent must infer usage from the parameter names.

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 with no side effects, so the description carries a lighter burden. It adds the concrete REST path (GET /1/user/-/cardioscore/date/...), which is mild context, but it says nothing about behavior when no cardio score exists for a date, whether data is device-dependent, or what the returned payload contains.

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: the first front-loads the purpose and scope, the second gives 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?

With no output schema, the description ideally would sketch the return shape (intraday values, ranges, units), which it only partially does via 'VO2 max estimate.' For a simple two-parameter read-only tool with full schema coverage it is serviceable but leaves the agent guessing about response content and empty-result 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?

Schema description coverage is 100%, so both parameters (date, endDate) are already fully documented with their yyyy-MM-dd/'today' patterns. The description only restates that the input is 'a date or range,' adding no format or semantic detail beyond the schema, which is the expected baseline 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 names a specific resource (cardio fitness score / VO2 max estimate) and its scope (a date or range), so an agent knows exactly what data comes back. It does not, however, distinguish itself from any sibling health metric tool (hrv, heart_rate, spo2), relying on the resource name alone to differentiate.

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 mention of prerequisites (e.g., needing a Fitbit account or device that computes VO2 max), and no routing to alternatives. The phrase 'for a date or range' describes input shape rather than a usage condition, leaving an agent to infer when this tool is appropriate.

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

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

The readOnlyHint annotation already establishes this as a safe read. The description adds the endpoint path and the field set returned, plus implicit 'today' support via schema, but says nothing about rate limits, auth, or pagination. With annotations covering the safety profile, this is an adequate but not rich disclosure.

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: the resource and returned fields come first, and the REST endpoint is appended as a compact reference. No filler.

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

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

With no output schema, the enumeration of returned metrics (steps, distance, floors, calories, active minutes, logged activities) usefully compensates, and the required date format is clear. What is missing is any note on how logged activities are structured or on response size, but for a simple single-date read tool this is nearly 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 description coverage is 100% and there is only one parameter, whose format and 'today' alias are fully documented in the schema. The phrase 'for a date' adds nothing beyond that, 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?

The description names a specific resource and scope ('Daily activity summary for a date') and enumerates the returned metrics, so an agent knows exactly what this returns. It does not explicitly contrast itself with fitbit_activity_time_series or other siblings, which is the only thing keeping it from 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?

Usage is only implied: the date-based single-day framing and the REST path suggest using this for one day versus the time-series sibling for ranges. There is no explicit when-to-use, when-not-to-use, or named alternative.

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 and the description need not restate it. The description adds useful context by naming the exact upstream endpoint and the returned content, but says nothing about auth requirements, rate limits, or empty-day behavior. Adequate 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?

One front-loaded sentence plus the endpoint reference — no filler, no redundancy. The resource and its contents come first, which is exactly the information an agent needs to route correctly.

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?

There is no output schema, so the description carries the return-value burden — it does so at a high level by naming logged foods and nutrition totals with calories/macros. It stops short of describing response shape or empty-day handling, which leaves a small gap for a tool with no output schema.

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 date parameter is fully documented in the schema (yyyy-MM-dd or 'today'). The description's 'for a date' phrasing adds no format or constraint 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 (for a date), and enumerates what it returns (logged foods plus daily nutrition totals/calories/macros). This distinguishes it clearly from siblings like fitbit_water_log and fitbit_weight_log without needing to open any 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 date-scoped framing, and the inclusion of the underlying REST path (GET /1/user/-/foods/log/date/{date}.json) makes the read intent obvious. However, it never states when to use this versus alternatives (e.g., other date-scoped logs) or any prerequisites, so guidance is minimal.

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 structurally. The description adds the underlying REST call (GET /1/user/-/devices.json) and the shape of the returned entries, but says nothing about auth/user scoping ('-' placeholder) or rate limiting. Useful context, but not rich beyond the annotation.

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 sentence with the purpose front-loaded, followed by a compact endpoint reference. No filler, no 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, zero-parameter listing tool with no output schema, the description covers purpose and hints at the return contents. It omits any note on what happens with unauthorised or absent devices, so it is complete enough but not exhaustive.

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 there is no parameter semantics to explain; the baseline for a no-arg tool is 4. The description correctly implies no filtering options are available.

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 (the user's Fitbit devices/trackers), and even names the returned fields (battery, last sync, version). It is unmistakable against siblings like fitbit_get_profile or fitbit_heart_rate, which all concern health metrics rather than hardware.

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 by the resource name: an agent can infer this is for enumerating paired devices. There is no explicit when-to-use/when-not-to-use statement, and no alternatives named. For a zero-parameter, no-alternative tool this is the minimum viable level.

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 genuine context by enumerating the profile fields and pinning the tool to a specific REST endpoint, but it says nothing about authentication requirements, 'current user' resolution semantics, or error behavior.

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

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

Two sentences, front-loaded with the resource and its contents, with the REST endpoint appended as a compact spec anchor. No filler, though the raw endpoint line is borderline redundant with the tool 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?

With no output schema, the description carries the burden of describing return values, which it does by listing the profile fields (name, age, gender, height, timezone, member since, avatar, etc.). For a no-parameter read tool this is essentially sufficient; only auth/error behavior is unaddressed.

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 no parameters, so the baseline is 4. The description correctly frames the target as 'the current user', making clear no user identifier is accepted, and there are no parameter semantics left to document.

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 exact resource (the current user's Fitbit profile) and enumerates the returned fields, so an agent can tell it apart from siblings like fitbit_get_devices or fitbit_activity_goals. The verb is only implied by the name/title, and there is no explicit statement of scope relative to other profile-adjacent tools, keeping it just 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?

There is no statement of when to use this tool, when not to, or what alternative to prefer. The API endpoint mapping (GET /1/user/-/profile.json) is documentation, not usage guidance. Its trivial zero-argument nature makes usage obvious, but that is inference, not guidance.

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 establishes the safe-read profile, and the description adds value beyond it: the shape of the returned data (resting HR plus time-in-zone) and the REST endpoint it wraps. It does not mention auth/scopes or rate limits, keeping it below 5, but it is a solid supplement to the annotation.

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-loading what the tool returns before the parameter rule. The raw REST path is arguably redundant for an agent and slightly pads the entry, but nothing else is wasted.

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

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

With no output schema, the description carries the return-value burden and does so briefly (resting HR and per-zone time). All three parameters are fully documented in the schema and the read-only annotation covers safety, so an agent has what it needs to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents date, period, and endDate including the period-vs-endDate precedence. The description restates the same date+period/date+endDate rule without adding format or edge-case detail, 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 ('Heart-rate time series') and names the concrete payload ('resting HR and time in each HR zone'), which lets an agent distinguish it from fitbit_hrv and fitbit_cardio_score. It stops short of explicitly naming those siblings as alternatives, so it is clear but not sibling-differentiated at the 5 level.

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 invocation guidance ('Give a single date + period, OR a date + endDate range'), which tells the agent how to combine parameters. It does not say when to prefer this tool over fitbit_hrv, fitbit_cardio_score, or fitbit_daily_activity_summary, and gives no exclusions, so usage is implied rather than explicit.

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 safe-read profile is covered. The description adds the underlying REST endpoint (GET /1/user/-/hrv/date/...), which implies a plain read with no side effects, but discloses no rate limits, auth requirements, or data-availability caveats beyond what the annotation says.

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, and the endpoint reference is tight enough to be useful for cross-referencing. No filler or repetition.

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 two-parameter read tool whose annotations carry the safety profile and whose schema fully documents inputs, this is nearly sufficient. The one remaining gap is that no output schema exists, so the shape of the returned HRV summary is never described.

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

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

Schema description coverage is 100%, so the schema already documents both parameters, their formats, and which is optional. The description's 'for a date or range' only restates that optionality and adds no format, boundary, or default semantics 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 (heart rate variability / HRV) and scope (a date or a range), which distinguishes it from the sibling fitbit_heart_rate and fitbit_sleep_log. The retrieval verb is implicit in 'summary' rather than stated, and it does not explicitly contrast itself with fitbit_heart_rate, so it falls just 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 description states that a date or range can be given but offers no when-to-use guidance, no exclusions, and no mention of alternatives such as fitbit_heart_rate or fitbit_cardio_score. An agent must infer from the name alone when this tool is the right choice.

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 useful context by naming the underlying REST endpoint (GET /1/user/-/activities.json), but discloses nothing about auth requirements, aggregation period definition, or freshness of the 'lifetime' totals.

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 filler: the metric scope is front-loaded and the endpoint provenance is a compact second clause. Nothing could be removed without losing information.

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

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

For a no-param, read-only aggregate tool with no output schema, the description adequately covers scope and enumerates the returned metric families. It stops short of describing the response shape or whether 'best-ever' and lifetime totals are returned together.

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 no parameter documentation is needed; the baseline for a param-free tool is 4. The description confirms the absence of inputs by implying a single fixed aggregate query.

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 specifically that this returns lifetime and best-ever activity statistics (total steps, distance, floors, personal bests), which is clearly distinct from the daily/time-series siblings like fitbit_daily_activity_summary. It lacks an explicit verb and never names a sibling, but the 'lifetime/best-ever' scope makes the resource 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?

Usage is only implied: the 'lifetime and best-ever' framing signals this is the aggregate view versus the daily or time-series tools, but there is no explicit when-to-use statement, no exclusions, and no named alternative. An agent can infer intent but is given no routing guidance.

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 does add one meaningful semantic fact beyond the annotations: values are relative to a personal baseline, which affects interpretation. It says nothing about return shape, units, or rate limits, so the added value is modest.

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, front-loaded sentences with no padding; the purpose leads and the parentheses keep the scope qualifier tight. The trailing raw REST path is slightly redundant for an agent choosing a tool, which keeps it from a 5.

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 two-parameter read tool with readOnlyHint provided and no output schema, the description covers what the tool returns conceptually (baseline-relative skin temperature) and how to scope it. Only minor gaps remain around return format and auth requirements.

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 (date and endDate) are already fully documented with pattern and required/optional status. The description restates the date-or-range concept but adds no format or syntax 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?

Names a specific resource (skin temperature) with a clear verb-less scope statement covering both single date and range, and the endpoint path makes the operation unambiguous. It distinguishes itself from siblings by resource subject (the other sibling names cover heart rate, HRV, SpO2, etc.), though it does not explicitly call out any sibling.

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

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

Usage is implied by "for a date or range" and the required/optional date semantics, which is enough to know how to invoke it. However, there is no explicit when-to-use guidance versus other Fitbit metrics, no statement of prerequisites (auth, scopes), and no 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?

readOnlyHint=true already establishes the safe-read profile, so the bar is lower. The description usefully adds the return shape and the underlying REST call, but says nothing about auth requirements, rate limits, or how large ranges are handled beyond what the schema states. Adequate, 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 compact sentences. The functional scope leads, the returned fields follow, and the endpoint reference is tucked at the end — no filler and nothing front-loaded incorrectly.

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 compensates by naming the returned fields, and it covers both single-date and range invocation. It is complete for a two-parameter read tool, though it omits any note on response structure or paging for long ranges.

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 date/endDate formats and the max 100-day range are already documented in the schema. The description echoes 'date (or date range)' without adding syntax or edge-case meaning, which matches the baseline-3 expectation 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?

States a specific verb+resource ('Sleep logs for a date or date range') and enumerates the payload (stages/levels, duration, efficiency, start/end times), which cleanly separates it from siblings like fitbit_hrv, fitbit_breathing_rate, or fitbit_activity_time_series. The REST endpoint mapping pins down exactly which data source it hits.

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 name and the date/date-range scope, but there is no explicit when-to-use guidance and no alternatives named. An agent can infer the intent, but nothing steers it away from a sibling tool if the request is ambiguous (e.g., a general 'health today' query).

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 establishes this is a safe read, and the GET endpoint mapping corroborates that. The description adds no behavioral context beyond the annotations: no note on data availability, rate limits, or that a range request returns per-day entries.

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, with the endpoint as supporting detail. 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 simple two-param read tool with full schema coverage and readOnly annotations, the description covers what is needed to invoke it correctly. Since there is no output schema, a brief note on the returned summary's shape would be the only 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%, so both parameters (date, endDate) are already fully documented with format and required/optional status. The description's 'date or range' phrasing adds no syntax or semantic 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 resource (blood oxygen saturation / SpO2) and the operation (summary for a date or range), with the exact Fitbit REST endpoint mapping. An agent can distinguish it from siblings such as fitbit_heart_rate, fitbit_hrv, and fitbit_breathing_rate purely from 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 how to select single-date vs range usage, but there are no explicit when-to-use/when-not conditions or named alternatives. Usage is inferable but not 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 declares this is a safe read, so the description's disclosure burden is low, but it adds essentially nothing beyond the raw REST path. It does not describe auth requirements, rate limits, or what the log actually returns.

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 and no padding. The REST path is arguably extraneous but costs little space.

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?

A single-parameter read tool with no output schema, so the description should hint at the shape of the returned log (entries, totals). It omits this, though the tool's simplicity limits how much 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% and the sole 'date' parameter is fully documented with its format and 'today' option in the schema. The description only restates 'for a date', so the baseline 3 applies.

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

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

States a specific verb+resource: retrieving the water intake log for a given date. It is clear this is the water counterpart to fitbit_food_log, but the description never explicitly contrasts itself with that sibling, leaving the differentiation implicit.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as fitbit_food_log. The agent must infer that this is the read-only water lookup 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the underlying Fitbit REST path, which is useful provenance, but says nothing about pagination, empty-result behavior, or authentication needs.

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 endpoint URL is arguably redundant, but it costs little and the whole definition is compact with no wasted prose.

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 annotations covering safety and no output schema, the description supplies enough to invoke correctly. The only minor gap is that the returned entry shape is not described, though no output schema exists to relieve 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?

Schema description coverage is 100% and the single 'date' parameter is fully documented in the schema (yyyy-MM-dd or 'today'). The description adds no format or semantic detail beyond 'for a date,' 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 the resource and scope precisely: 'Body weight log entries for a date,' which is clearly distinct from siblings like fitbit_body_fat_log, fitbit_water_log, and fitbit_food_log. The REST endpoint reference reinforces the exact operation, though there is no explicit verb or direct sibling routing statement.

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 tool versus the many similarly-shaped log siblings (body_fat_log, water_log, food_log). The date scope is implied by the name, but the description never states conditions, prerequisites, or alternatives.

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