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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely useful semantics beyond that: missing values are not zero (a real interpretation pitfall), the end date is exclusive, and a failed domain is surfaced explicitly rather than silently dropped.

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

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

Three dense sentences with the resource and range front-loaded and no filler. Terms like 'server-reconciled' and 'raw rollup fields' are compact but slightly jargon-heavy for an unprimed agent.

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 reasonably explains what comes back (raw rollup fields), how to read missing data, and how failures appear. It does not address return shape, pagination, or units, which is the remaining gap for a data-fetch tool.

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

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

Schema description coverage is 0%, so the description has to carry the burden, and it does partially: it defines the valid span (1-14 days) and that endDate is exclusive, which the bare regex pattern does not convey. It omits the YYYY-MM-DD format and whether the range is inclusive of startDate, leaving minor gaps.

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 wearable activity) with its scope (1-14 civil days) and output character (raw rollup fields). It does not explicitly distinguish itself from siblings like fitbit_summary or fitbit_read, so the agent must infer which one to pick.

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 1-14 day limit and end-exclusive semantics imply the valid usage envelope, but there is no explicit when-to-use guidance or named alternative such as fitbit_summary or fitbit_compare. Usage is only inferable from the constraints given.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false and a closed (non-open-world) scope. The description usefully clarifies the *extent* of that destruction — it only discards a local draft and never touches Google-side records — which is real context beyond the flags. It stops short of covering failure modes (e.g. canceling an already-committed preview) or required auth.

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 compact sentence with the action front-loaded and the critical non-effect ('does not delete Google records') trailing it. Nothing is wasted and no filler precedes the useful information.

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

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

For a low-complexity, single-parameter mutation with annotations covering the safety profile and no output schema, the description covers purpose and blast radius adequately. It is still incomplete on the two things an agent most needs: where operationId comes from and what state the draft is left in after cancellation.

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

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

Schema description coverage is 0% and the description never mentions the single required parameter. An agent gets no hint that operationId is the handle produced by a prior preview call, nor what an invalid/stale id means — the only guidance is the JSON-schema UUID pattern, which is necessary but not sufficient for correct invocation.

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 object ('Cancel an untouched local preview') and immediately bounds the effect ('does not delete Google records'), which implicitly separates it from the delete-oriented sibling fitbit_remove. It does not name a sibling outright, but the scope 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?

The qualifier 'untouched' implies when this tool applies (a preview that has not been committed or modified) and the negation implies when it does not (when you actually want to remove Google records). However, no alternative tool is named and no prerequisite such as 'use the operationId returned by fitbit_preview_meal/preview_water' is given, so routing is left to inference.

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

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

Annotations declare destructive/openWorld/idempotent but not the retry nuance. The description explains that reusing an operation ID will not blindly replay an uncertain item, and clarifies return semantics ('per-item states', 'verified means read-back succeeded') with no output schema present – substantive behavior 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?

Three tightly packed sentences that front-load the core action before retry semantics and return states. Every sentence earns its place, though the final clause is slightly telegraphic.

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 destructive, open-world write tool with no output schema and 0% schema description coverage, the description supplies purpose, precondition, retry safety, and return-state meaning. It omits failure/partial-application handling and the confirm semantics, so it is strong 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?

Schema description coverage is 0% and neither parameter is documented in the schema, so the description must carry the load. It references the 'operation ID' retry behavior and implies the confirm flag via 'explicit user intent', but never explains the required confirm=true or the UUID format, leaving gaps.

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 ('Save') and resource ('an existing reviewed preview'), which distinguishes it from the preview_meal/preview_water siblings and from fitbit_operation. It does not explicitly name a sibling, so it stops short of full differentiation.

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

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

'after explicit user intent' gives a clear precondition for invocation, tying it to a prior reviewed preview. No alternatives or when-not-to-use conditions are named (e.g., use fitbit_cancel_draft instead), so it lacks 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 establish read-only, non-destructive, open-world behavior, so the bar is lower. The description adds genuine value beyond them: it discloses the computation method (paired-day means plus coverage) and explicitly disclaims inventing a medical/recovery score, which is meaningful framing for a health-metrics tool.

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

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

Three short sentences, front-loaded with the core purpose and method. No filler; the disclaimer sentence earns its place by preempting a wrong expectation about output.

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 and no parameter descriptions, the description covers the concept and default window behavior but leaves the domains filter, output shape, and the exact pairing semantics of explicit previous dates unexplained. Adequate, not 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 0% across 5 parameters, so the description must carry the load. It explains the non-obvious default pairing logic for previousStartDate/previousEndDate (same length as the primary window), which is the most semantically tricky part, but says nothing about the domains parameter or the date format.

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 action (compare) and resource (equal calendar windows) with the method stated (code-calculated paired-day means and coverage). It is reasonably distinct from generic siblings like fitbit_summary or fitbit_read, though it never explicitly names what it is not.

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

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

"Defaults to the preceding window of the same length" implies the intended comparison workflow, but there is no explicit when-to-use statement, no prerequisite, and no pointer to an alternative sibling tool for adjacent tasks.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description contributes only the 'paired' qualifier, which usefully narrows scope but adds nothing about auth requirements, pagination, or what 'metadata' comprises.

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

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

A single front-loaded sentence with no filler; every word earns its place.

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

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

For a trivial zero-argument read with annotations covering the safety profile, the description is minimally sufficient, but 'metadata' is never unpacked and no output schema exists to compensate. An agent knows how to call it but not what fields come back.

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

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

The tool takes zero parameters, which is the baseline-4 case. The description correctly implies a no-argument call that returns all paired devices.

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

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

The description states a specific verb ('Read') and resource ('paired device metadata'), which clearly identifies the target object. It does not name or contrast with any sibling, but the 'devices' resource is distinct enough from fitbit_activity, fitbit_summary, and the write siblings that an agent can place 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the twelve siblings. The agent must infer that this is the tool for enumerating paired hardware, with nothing in the text confirming that or ruling out related tools.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful safety directive about not resubmitting uncertain writes, but says nothing about what state values are returned or how to interpret them.

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 tool's purpose. The second sentence is closer to a policy caution than a description of the tool, but it is brief and adds real decision value.

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 is adequate but thin: it never describes the possible operation states an agent would act on, nor that the tool is the intended follow-up to fitbit_commit/preview writes. Annotations carry the safety burden, so this is a moderate gap rather than a critical one.

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 is a single operationId parameter with 0% schema description coverage; the schema only supplies a UUID format and pattern. The description's reference to an 'operation' gives indirect semantics for the ID, but it never explains where the operationId comes from (presumably a prior write) or what to do if it is unknown.

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: 'Inspect the persisted state of a meal/water operation.' An agent can tell this is a status/state-read tool rather than a mutation. It does not, however, distinguish itself from the sibling fitbit_status, which an agent might reasonably confuse it with.

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?

'Never silently resubmit uncertain writes' implies the usage context: check this after a write whose outcome is unknown (e.g. a timeout). The trigger is implied rather than explicit, and no alternatives or when-not-to-use conditions are named.

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 cover mutation/safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower. The description still adds real value by clarifying the write is local/non-persisted and warning that photo-based estimates are approximate, which the annotations do not convey.

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?

Four short sentences, front-loaded with the scope constraint, and each carries distinct information. 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?

Given 4 required params at 0% schema coverage, no output schema, and a draft/commit workflow, the description covers the critical unit-of-measure caveat and the review-before-save obligation. It stops short of explaining the requestId idempotency key or the mealType enum, so it is not 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 description coverage is 0%, so the description must carry parameter meaning. It adds a genuinely important semantic ('values apply to the whole dish portion, not per 100g'), references date/offset and assumptions, and names the K/P/F/C fields, but leaves requestId and mealType unexplained. Partial compensation only.

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 ('Create a local meal draft') and the capitalized 'ONLY' explicitly scopes the operation as non-persistent, distinguishing it from the commit step in the sibling set (fitbit_commit, fitbit_cancel_draft). An agent can tell what this 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?

Implies a downstream save step via 'Review ... before saving' and signals this is a draft rather than a finalized entry, but it never names the alternative (e.g., fitbit_commit) or states when to choose preview vs commit. Usage is inferable from the 'ONLY' phrasing 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds important context beyond annotations: the result is a 'local draft ONLY' and should be reviewed before saving, clarifying that this is a temporary write-like step rather than immediate persistence. It does not discuss auth or rate limits, but those are not implied by the tool's scope.

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

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

The description is two short, front-loaded sentences with no waste. The key constraint ('local draft ONLY') and the intended review step are both stated compactly.

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

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

The description covers the draft-creation purpose and review step, and annotations cover safety and idempotency. But for a three-parameter workflow tool, it omits the role of requestId and does not explicitly connect the draft to sibling commit/cancel operations, leaving the agent to infer the two-phase workflow.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'volume' (mapping to milliliters) and 'date/time with offset' (mapping to at), partly clarifying two of three required parameters. However, it says nothing about requestId, which is required and likely used for idempotency/deduplication, leaving a significant gap.

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

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

The description states a specific verb ('Create') and resource ('local water draft') with scope ('ONLY'), and the phrase 'before saving' distinguishes it from a commit/persist sibling. An agent can immediately tell this is a preview/draft-creation tool rather than a save or read tool.

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

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

It gives clear context: use this to create a local draft, then review volume and date/time with offset before saving. That implies the tool is for pre-commit review and should be followed by a save operation, but it does not explicitly name the alternative tool (e.g., fitbit_commit) or state when not to use it.

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 cover read-only/non-destructive, and the description adds important behavioral details: raw samples may overlap and must not be summed, 500-point limit per call, and pagination continuation via nextPageToken. This goes beyond annotations meaningfully, though auth/permissions aren't mentioned.

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 information-dense sentences with no filler: date semantics, sleep grouping, sample overlap warning, and pagination are front-loaded and each earns its place.

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

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

For a read tool with no output schema, the description covers date range, endDate exclusivity, sleep grouping, overlapping samples, and pagination. It doesn't describe return structure, but 500-point and continuation guidance are sufficient 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 coverage is 0%, so the description must compensate. It explains endDate exclusivity, the 1–14 day range, sleep-by-wake-date semantics, and how to use pageToken with the same type/dates. The type enum is left to schema, but key parameter behaviors are clarified.

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

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

The description states a specific verb (read) and resource (Fitbit data across 1–14 civil days), with scope details (endDate exclusive, sleep grouped by wake date). It doesn't explicitly contrast against siblings like fitbit_summary or fitbit_activity, but the purpose is clear.

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

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

Usage is implied by the date range and pagination instructions, but there's no explicit when-to-use versus alternatives (e.g., fitbit_summary). The 1–14 day constraint is a helpful boundary, but no exclusions or sibling routing are given.

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

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

Annotations already declare destructiveHint/idempotentHint/readOnly=false, but the description adds real behavioral context on top: it refuses uncertain records, verifies deletion afterward, and warns that the macro-correction path is not atomic. Those guardrails and the non-atomicity caveat are exactly the kind of detail an agent cannot derive from the annotation block.

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 sentences, front-loaded with the scope restriction and confirmation requirement before the less-common macro workflow. Dense but every clause carries information; 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 destructive, non-output-schema tool this covers the essentials: safety guardrail, verification behavior, and the non-atomic workflow caveat. The residual gap is that parameter contracts for operationId/confirm are left to the schema, which itself carries no descriptions.

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 0%, so the description must carry the parameter burden. 'After explicit user intent' implicitly maps to the confirm const-true flag, and 'created by this operation' hints that operationId must reference the originating operation, but neither parameter's format or exact contract is explained.

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 (remove) plus a tightly scoped resource ('only the known Google records created by this operation'), which distinguishes it from siblings like fitbit_cancel_draft or fitbit_commit. It never names an alternative tool, so the differentiation is inferred from scope rather than explicit routing.

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?

Gives a clear precondition ('after explicit user intent') and a concrete workflow for the manual-food macro case (remove old records, then review and save a new preview). It stops short of naming which sibling to use instead in other situations, so no true when-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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and closed-world, so the safety profile is covered. The description adds the idempotency/retry contract, which is real behavioral value, but says nothing about the ID's format, lifetime, or how it is consumed downstream.

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 action and immediately followed by the retry rule. Nothing is wasted and there is 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 no-param, no-output-schema generator, the description covers what the UUID is for and how to reuse it across retries, which is the essential contract. It stops short of stating where the ID is passed next (e.g., into a commit call), leaving minor workflow inference to the agent.

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 per the rubric the baseline is 4. No parameter semantics are needed and the schema is trivially complete.

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 output ('Generate a UUID') scoped to 'one new meal/water draft', which links it to the draft workflow implied by siblings like fitbit_preview_meal and fitbit_commit. It does not explicitly name a sibling it is distinct from, so it falls 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?

Gives concrete caller guidance: reuse the same ID on retries, allocate a new ID for a new occurrence. That resolves the main ambiguity for an ID generator. No explicit when-not-to-use or alternative mentioned, so not a 5.

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

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

Annotations already establish this as a safe, non-destructive, closed-world read, so the bar is lower. The description still adds real behavioral context beyond them: the warning that declared support does not guarantee data availability on the device, and an explicit statement that credentials are not returned, which is security-relevant for a connection-status tool.

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

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

Three short, front-loaded sentences with no filler; the return content comes first and the caveats follow. Slightly telegraphic phrasing, but every sentence earns its place.

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

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

With no parameters, no output schema, and annotations covering the safety profile, this is a low-complexity diagnostic call and the description covers the essentials: what it returns and the two important caveats. It does not enumerate the returned fields, but that is a minor gap at this complexity level.

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 per the baseline the schema carries no parameter burden and the description has nothing to compensate for. No parameter information is needed or missing.

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

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

The description names the resource ('local connection metadata and implemented types'), which tells an agent roughly what comes back, but it is a bare noun phrase with no verb and no statement of what the tool actually does. It also does not distinguish itself from near siblings like fitbit_devices or fitbit_operation, so the purpose is only implied rather than stated.

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

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

There is no statement of when to call this versus fitbit_devices, fitbit_operation, or fitbit_read. The caveat 'declared support is not proof of data availability on this device' is a data-quality warning, not usage guidance, and no prerequisites or exclusions are given.

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

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

Goes well past the annotations (readOnly/openWorld/non-destructive) by disclosing the 1-14 day window, end-exclusive interval semantics, wake-date grouping for sleep, explicit surfacing of missing/conflicting/partial/failed data, and the rule that totals are null unless every requested day is observed. Those aggregation and data-quality semantics materially change how results should be interpreted.

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?

Four short sentences, each carrying distinct information with no filler, and the core scope is front-loaded. It is dense but not padded; minor jargon ('civil days', 'reconciles wearable sources') slightly raises parsing cost.

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 readOnly annotations covering the safety profile and no output schema to defer to, the description supplies the semantics an agent actually needs: interval rules, data-quality guarantees, and the null-totals condition. The only meaningful gap is that the domains selector and resulting response shape are 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 coverage is 0% and the description does explain the two date parameters (range limit, end-exclusive behavior), which compensates for the most important ones. The domains parameter and its activity/sleep/heart enum are not mentioned at all, so coverage of the three parameters is only partial.

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 deliverable: normalized daily health metrics plus period statistics over a bounded date range, which is clearly distinct from raw-read siblings like fitbit_activity or fitbit_read. It never names a sibling or explicitly contrasts itself, so an agent must infer the boundary.

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 description of outputs ('daily health metrics and period statistics for 1-14 civil days'); there is no when-to-use statement, no exclusion, and no pointer to fitbit_activity or fitbit_compare as alternatives. Adequate for a capable agent but leaves routing to inference.

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