Fitbit MCP

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable context by explicitly stating the tool does not call Fitbit or expose secrets, reinforcing safety and no side effects beyond what annotations provide.

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, front-loaded with purpose and key constraint. No unnecessary information; 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?

Given the presence of an output schema and simple enum parameters, the description is adequate but minimal. It misses guidance on parameter selection and output contents, though the output schema may partially compensate. Still, for a manifest tool, more completeness is expected.

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% (no parameter descriptions in schema). The description does not explain the meaning or usage of the two parameters (client and response_format). It relies solely on enum values, which are insufficient for an AI agent to understand parameter purpose.

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

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

The description clearly states the tool provides machine-readable guidance for AI agents, using a specific verb-resource pair. It explicitly distinguishes from siblings by noting it does not call Fitbit or expose secrets, setting it apart from data-fetching tools.

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

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

The description implies usage for setup or configuration, and the 'does not call Fitbit' caveat suggests when not to use, but there is no explicit guidance on when to prefer this tool over siblings or alternatives. It lacks a clear 'when to use' statement.

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 idempotentHint=true, covering safety and idempotency. The description adds that it shows 'optional local SQLite cache status', which is consistent but does not add significant new behavioral detail.

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, clear sentences with no filler. Information is front-loaded and 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 simple status tool with one optional parameter and an output schema, the description is somewhat complete. However, it lacks details about when the cache is considered 'enabled' and does not guide the agent on interpreting the status.

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 explain parameter semantics. It does not mention the only parameter 'response_format' or its purpose, leaving the agent without guidance.

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

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

The description clearly states 'Show optional local SQLite cache status', using a specific verb and resource. It is distinct from sibling tools which focus on data retrieval or management.

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 tells when to use the tool (when cache is enabled) by specifying how to enable it. However, it does not explicitly mention when not to use it or provide alternatives.

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 state readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds meaningful context about the content of the explanation (data, privacy, workflow), which helps the agent understand the tool's output beyond safety annotations.

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

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

The description is a single, front-loaded sentence covering all key aspects without redundant words, achieving maximum conciseness.

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

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

Given the tool's simple meta-purpose, the existence of output schema, and annotations covering safety, the description provides sufficient context for an agent to understand what the tool returns and how it fits into the 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?

The only parameter response_format is self-explanatory from the schema enum, and the description does not mention it. With schema coverage at 0%, the description adds no value for this parameter, but since it's optional and well-defined, a baseline of 3 is appropriate.

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

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

The description uses a specific verb 'Explain' and lists clear topics (supported data, privacy boundaries, workflow, project links), clearly distinguishing it from data-retrieval sibling tools like fitbit_get_activity or fitbit_get_sleep_day.

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

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

The description implies this tool is for initial orientation, but does not provide explicit when-to-use or when-not-to-use guidance or mention alternative 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, idempotentHint=true. The description adds value by detailing what is checked (config, token, Node version, etc.) and explicitly stating it does not call Fitbit or expose secrets, providing safety context beyond annotations.

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

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

The description is a single long sentence that lists multiple items, which is somewhat concise but could be better structured with bullet points or clearer separation of concepts.

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?

Despite having an output schema, the description does not explain what the output contains or how to interpret results. The two optional parameters are undocumented, and no guidance on typical use cases is provided.

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

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

Schema description coverage is 0%, yet the description does not explain the 'client' or 'response_format' parameters, their options, or how they affect behavior. This leaves agents without guidance on selecting values.

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

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

The description clearly states the tool checks local Fitbit config, token file, Node version, privacy mode, cache readiness, and optional MCP client readiness without calling Fitbit or exposing secrets. This distinguishes it from sibling tools that fetch data or perform actions.

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

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

The description implies usage for pre-flight checks before making API calls, noting it avoids external calls and secret exposure. However, it does not explicitly state when to use or not use this tool versus alternatives like other status 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?

The description adds context beyond annotations: it confirms read-only and non-medical nature, and specifies which data types are included ('when available'). This aligns with annotations (readOnlyHint=true, destructiveHint=false). However, it could mention rate limits or data availability dependencies.

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 concise with two sentences, front-loading the purpose and key limitations. Minimal redundancy with annotations. Could be slightly more structured (e.g., bullet points) but remains efficient.

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

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

Given the tool's multi-source summary nature and the presence of an output schema, the description adequately conveys the overall function and constraints. However, it lacks details on what the summary includes (e.g., averages, trends) and does not mention pagination or data staleness.

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

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

The input schema covers 67% of parameters (days and timezone have descriptions). The description does not provide additional meaning beyond what the schema already offers. The response_format parameter lacks a description in the schema, but the description does not compensate either.

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

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

The description clearly states it builds a practical daily summary from multiple Fitbit data sources (activity, sleep, heart-rate, HRV, weight), which distinguishes it from sibling tools that fetch individual data types. However, it does not explicitly differentiate from fitbit_weekly_summary, which might cause confusion about the timeframe.

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

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

The description implies usage for obtaining a consolidated daily overview, but does not provide explicit guidance on when to use this tool versus individual data fetchers or the weekly summary. No alternatives or exclusions are mentioned.

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 the tool as read-only, non-destructive, and idempotent. The description adds value by clarifying it does not call external APIs or expose user data, which reinforces its safe behavioral profile.

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 extremely concise: two sentences that immediately convey the tool's purpose and safety traits. No unnecessary words 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 the tool's simplicity (one optional parameter, clear purpose), the description covers the core needs. However, it lacks any mention of the output format parameter, which would be helpful for an agent to know how to request the desired format.

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 description provides no explanation for the single parameter 'response_format', despite the schema having 0% description coverage. The parameter has clear enum values, but the description should at least mention that the output can be requested in different formats (markdown or json).

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

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

The description clearly states the tool inventories supported Fitbit data domains, auth scope requirements, privacy boundary, and recommended first calls. It also distinguishes itself from siblings that actually retrieve data by explicitly saying it does not call Fitbit APIs or expose user data.

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

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

The description implies the tool should be used for understanding supported data domains and auth requirements before making actual data calls, with the phrase 'recommended first calls'. However, it does not explicitly state when not to use this tool or provide alternative tools for specific cases.

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

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

The description adds value beyond annotations by disclosing that it returns example payloads (not real data) and specifies which endpoints are demonstrated. Annotations already indicate readOnly and idempotent, but the description enriches understanding.

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

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

The description is a single sentence that efficiently communicates purpose, target endpoints, and usage context. No redundant words.

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

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

For a demo tool with no output schema, the description provides essential context about what it returns and when to use it. It does not explain the response_format parameter or give example output, but the tool's purpose is modest and well-served by the description.

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

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

Schema description coverage is 0%, so description should compensate. However, it does not mention the 'response_format' parameter (enum, default 'markdown'), leaving its role implicit. While the parameter is simple, the description fails to clarify how the output format affects the demo payloads.

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

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

The description clearly states the tool returns realistic example payloads for three specific endpoints, distinguishing it from sibling tools that make real API calls. It uses specific verb 'returns' and resource names.

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

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

The description explicitly says 'before calling real Fitbit APIs', implying it is for preview/exploration. While it does not name alternatives, the context of sibling tools that are real API calls provides differentiation.

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?

Discloses that tokens are stored locally with 0600 permissions and never returned, adding behavioral context beyond annotations that only indicate non-read-only and non-destructive.

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 with no wasted words, front-loading the purpose and then adding behavioral and usage constraints.

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?

Covers purpose, behavior, security, and user involvement, sufficient for an authentication tool with annotations and output schema present.

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

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

Schema already describes 'code' parameter as an authorization code or redirect URL; description adds no further parameter-specific detail. Baseline 3 with schema coverage approximately 50%.

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?

Clearly states 'Exchange a Fitbit OAuth authorization code for local tokens,' specifying the action and resource. Distinguishes from sibling data retrieval and other 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?

Explicitly requires explicit user action and warns agents not to invent codes, providing clear when-to-use and when-not-to-use 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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so description does not need to restate these. It adds 'Requires activity scope', giving permission context. No contradictions with annotations.

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

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

Single sentence, no filler, front-loaded with verb and resource. 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?

With output schema present and annotations covering safety, the description is sufficient for a simple get-by-id operation. However, it could briefly mention output format or privacy defaults to be more 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 75% (3 of 4 params documented). Description adds no new parameter-level meaning beyond referencing 'by id'. The baseline is met; no additional value.

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?

Description clearly states verb (Get), resource (detailed Fitbit activity log), and method (by id), distinguishing it from other Fitbit tools like sleep or heart logs. The purpose 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?

Description implies usage when you have an activity ID, but does not explicitly contrast with sibling tools like fitbit_list_activities or fitbit_get_activity_day, nor provide when-not guidance. Usage context is clear but lacks exclusion criteria.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds the scope requirement. No contradictions. Could mention rate limits or caching but annotations suffice.

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?

Single sentence, front-loaded with purpose, no wasted words. Efficient and clear.

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 output schema present and rich annotations, description covers the essential: returns daily activity summary, goals, distances, and scope requirement. No mention of date range limits, but still sufficient for most agents.

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

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

Schema coverage is 67% (2 of 3 params described). Description adds minimal parameter info beyond mentioning date. The privacy_mode and response_format parameters are not elaborated, but schema descriptions exist for two. Baseline 3 is appropriate.

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?

Description specifies verb 'Get', resource 'daily activity summary, goals and distances', and temporal constraint 'for a date'. Clearly distinguishes from sibling tools like fitbit_get_sleep_day or fitbit_get_activity.

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?

Mentions 'Requires activity scope' as a prerequisite, but does not discuss when to use this tool versus alternatives like fitbit_daily_summary or fitbit_get_activity, or 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover safety and idempotence. The description adds the purpose ('Generate a Fitbit OAuth authorization URL') but does not provide additional behavioral context beyond what annotations convey. No contradictions with annotations.

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

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

The description is extremely concise with two sentences. The first sentence states the core action, and the second provides a critical usage condition. There is no redundant or extraneous text, and the key 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?

Given that an output schema exists (mentioned in context), the description covers the essential: generating the URL and when to use it. It does not detail the redirect flow or token exchange sequence, but for an OAuth URL generation tool, it is reasonably complete for a knowledgeable 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?

Schema description coverage is 67% (2 of 3 parameters have schema descriptions). The tool description does not add any parameter-level information; it only states the overall purpose. Since the schema already documents the parameters adequately, the description provides no extra semantic value for parameters.

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

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

The description clearly states 'Generate a Fitbit OAuth authorization URL' with a specific verb and resource. It also adds usage context ('Use this first when no local token exists'), which distinguishes it from sibling tools like fitbit_exchange_code that handle the token exchange step.

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 includes explicit guidance: 'Use this first when no local token exists.' This clearly indicates when to use the tool. However, it does not list alternatives or explicitly state when not to use it beyond the implied condition.

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 indicate read-only and idempotent behavior. The description adds valuable context: the scope requirement and a medical disclaimer, which supplements the annotations without contradiction.

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 extremely concise with three short sentences. The main purpose is front-loaded, and there is no redundant or extraneous information.

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

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

Given the simple tool with rich annotations and an output schema, the description covers the essential purpose, scope requirement, and disclaimer. It could mention the default date or privacy mode but is largely sufficient.

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 67%, and the description does not add additional parameter-level details. The schema already defines the parameters with descriptions, so the description's value is neutral.

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

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

The description clearly states the verb 'Get' and the resource 'breathing-rate summary' for a specific date. The sibling tools are for different metrics like heart rate or sleep, so this tool is well distinguished.

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 mentions that data is available only when Fitbit provides it and requires the heartrate scope, but it does not explicitly discuss when to use this tool versus alternatives or provide exclusion criteria.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds the 'nutrition scope' requirement and implicitly suggests that the tool retrieves food data. It does not contradict annotations and adds minimal behavioral context beyond what the schema and annotations provide.

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 extremely concise: two sentences with no wasted words. The first sentence captures the purpose, and the second adds a critical requirement. 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?

Given the tool's simplicity and the presence of good annotations and an output schema, the description is minimally adequate. It states what the tool does and a prerequisite. However, it does not explain what 'food logs' contain (e.g., meals, nutrients), which could help an agent understand the returned data. For a straightforward retrieval tool, this is acceptable but not rich.

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 67% (2 of 3 parameters have descriptions). The tool description does not add any parameter meaning beyond what the schema provides. The schema already describes 'date' and 'privacy_mode' adequately; 'response_format' lacks a description. Since coverage is neither high nor low, the baseline score of 3 is appropriate.

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

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

The description clearly specifies the verb 'Get', the resource 'food logs', and the context 'for a date'. It also mentions the required scope 'nutrition scope'. This distinguishes it from sibling tools like fitbit_get_sleep_day by the resource claimed. However, it does not elaborate on what constitutes 'food logs' (e.g., meals, nutrients), leaving some ambiguity.

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 the requirement for 'nutrition scope', indicating when the tool is callable. However, it provides no guidance on when to prefer this tool over siblings, nor does it specify when not to use it. The usage context is implied but not 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?

The description adds little beyond the annotations, which already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The only additional note is 'Not medical advice,' which is a disclaimer rather than behavioral insight.

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 wasted words. Purpose and key requirement are stated immediately.

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 tool with annotations and an output schema, the description is adequate but lacks guidance on usage alternatives and parameter details. It is minimally viable but could be improved.

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 description does not explain any parameters; the schema covers 67% of parameters (with enums and defaults), but the description adds no extra meaning. Baseline would be 3 for high coverage, but 67% is moderate and the description fails to compensate.

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?

Description clearly states it retrieves daily heart-rate zones and resting heart rate, with a specific verb and resource. While it doesn't explicitly distinguish from siblings like fitbit_get_heart_intraday, the purpose 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 description provides a prerequisite ('Requires heartrate scope') but offers no guidance on when to use this tool versus alternatives (e.g., intraday) or when not to use it. No explicit usage context is given.

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

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

Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds meaningful context beyond these: it requires a specific auth scope ('heartrate'), warns about third-party approval, and includes a 'Not medical advice' disclaimer. These are valuable behavioral traits not exposed by annotations, though it doesn't detail response size or pagination (covered by output schema).

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

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

The description is three sentences, each earning its place: purpose, usage guidance, and access/disclaimer. It is front-loaded with the core purpose and delivers high information density without fluff.

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, idempotent data-fetching tool with a rich output schema and strong annotations, the description covers purpose, usage alternatives, auth requirements, and a disclaimer. It doesn't mention rate limits or exact response structure, but the output schema and annotations cover those aspects, making it adequately complete without being 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 67% (4 of 6 parameters have descriptions). The description itself does not elaborate on parameters; however, the two undocumented parameters (detail_level and response_format) have self-explanatory enums. The description adds no meaning beyond the schema, so a baseline score of 3 is appropriate given moderate coverage.

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

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

The description states a specific verb and resource: 'Get raw heart-rate intraday samples for a date.' It clearly differentiates from sibling tools by explicitly naming fitbit_heart_series as the preferred alternative for agent work, leaving no ambiguity about this tool's purpose.

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 explicit guidance on when to use this tool versus alternatives: 'For agent work prefer fitbit_heart_series (agent-safe-series/v1 with hard point caps and exact stats).' It also notes access limitations ('Personal apps can access their own intraday data; third-party apps may require Fitbit approval'), giving clear contextual usage boundaries.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds behavioral context about required scope and device support, plus the non-medical disclaimer. No contradiction with annotations.

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

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

Two short, efficient sentences. The first sentence states the purpose, the second adds constraints. No wasted words or redundant information.

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

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

Given the presence of detailed annotations and an output schema (not shown), the description covers essential context: purpose, prerequisites, disclaimer. It lacks explanation of return values, but the output schema likely covers that. Adequate for a simple tool with few parameters.

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 description does not add any parameter meaning beyond the input schema. Schema covers 2 of 3 parameters with descriptions (date and privacy_mode), but the third parameter (response_format) lacks a schema description and is not mentioned in the tool description. The description fails to compensate for this gap.

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

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

The description clearly states 'Get HRV summary for a date' with a specific verb and resource. The name and title align, and the mention of HRV distinguishes it from sibling tools like fitbit_get_sleep_day or fitbit_get_heart_day.

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

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

The description provides prerequisites (heartrate scope, supported device/data) and a disclaimer (not medical advice), giving the agent context for when to use the tool. It lacks explicit alternatives or when-not-to-use guidance, but the prerequisites are clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the requirement for the 'profile' OAuth scope, which is useful context beyond the annotations. However, it does not disclose any other behavioral traits such as rate limits or data freshness.

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

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

The description is extremely concise at two short sentences. Every sentence adds value: the first states the core purpose, the second states a key prerequisite. No filler or redundant content.

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 tool with comprehensive annotations and an output schema, the description is mostly adequate. However, it omits clarification of the sibling 'fitbit_profile_get' tool and does not elaborate on parameter behavior, which leaves some gaps in a complete picture.

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?

With 67% schema coverage (2 of 3 parameters have descriptions), the description adds no parameter information whatsoever. It fails to explain the 'response_format' parameter, which lacks a schema description, and does not clarify defaults or usage of any parameter.

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

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

The description clearly identifies the tool as retrieving the authenticated Fitbit profile, using specific verb 'Get' and resource 'Fitbit user profile'. However, it does not distinguish from the sibling 'fitbit_profile_get', which has a very similar name and purpose.

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 mentions 'Requires profile scope' as a prerequisite but provides no guidance on when to use this tool over alternatives like 'fitbit_profile_get' or other profile-related tools. No explicit usage context 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the sleep scope requirement and a disclaimer, but does not elaborate on rate limits, data freshness, or response pagination.

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 concise sentences with no extraneous information. The key purpose, scope requirement, and disclaimer are communicated effectively and immediately.

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 tool with good annotations and an output schema (not shown), the description is sufficient. However, it could briefly differentiate from the many sibling get_*_day tools to avoid confusion.

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

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

The input schema provides detailed descriptions for all three parameters (date, privacy_mode, response_format), achieving high coverage. The description adds no additional parameter semantics beyond the schema, so baseline 3 is appropriate.

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 'Get sleep logs and stages for a date' uses a specific verb (Get) and resource (sleep logs and stages) for a given date, clearly distinguishing it from sibling tools like fitbit_list_sleep or fitbit_get_heart_day.

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 mentions the required 'sleep scope' and includes a disclaimer 'Not medical advice', but does not provide explicit guidance on when to use this tool vs alternatives like fitbit_list_sleep for historical logs.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds value by disclosing the required auth scope ('heartrate scope') and a disclaimer about medical advice, which provides context beyond annotations. It does not elaborate on error handling or output details, which is acceptable given the annotations.

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

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

The description is exceptionally concise: three sentences that front-load the core action ('Get SpO2 summary for a date when available'), state a prerequisite, and add a necessary disclaimer. There is no wasted text, and 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?

Given the tool's simplicity (3 optional parameters, output schema present, rich annotations), the description covers the essential functional, behavioral, and prerequisite information. It does not explain what happens when data is unavailable or detail the return structure, but those gaps are partially filled by the schema and annotations.

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

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

The input schema already describes two out of three parameters (date and privacy_mode) with sufficient detail, achieving 67% schema description coverage. The tool description does not add additional meaning beyond what is already in the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states it retrieves a SpO2 summary for a specific date, using the verb 'Get' and specifying the resource. It mentions data availability ('when available'), which adds clarity. However, it does not explicitly distinguish this tool from sibling tools like fitbit_get_heart_day, making it a 4 rather than 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 provides minimal usage guidance: it notes the required scope ('Requires heartrate scope') and a disclaimer ('Not medical advice'), but it does not specify when to use this tool versus alternatives, nor does it mention prerequisites or caveats like checking data availability first.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the important behavioral detail 'Requires nutrition scope', which informs the agent about authorization needs beyond what annotations 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?

Description is extremely concise: two sentences, front-loaded with purpose, then requirement. No unnecessary words. 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?

Given that an output schema exists, the description appropriately omits return value details. However, it lacks usage guidance and context among sibling tools. The scope requirement is useful but the description feels minimal. Adequate but incomplete.

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 description does not add any parameter-specific meaning beyond what the input schema provides. Schema descriptions cover date and privacy_mode, but response_format lacks a description; the description offers no additional insight into any parameter.

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?

Description clearly states 'Get water logs for a date', using a specific verb and resource. This distinguishes it from sibling tools like fitbit_get_sleep_day or fitbit_get_heart_day.

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 alternatives is provided. The only additional info is 'Requires nutrition scope', which is a prerequisite, not a usage context or comparison with siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not required to repeat safety. It adds the authentication requirement ('Requires weight scope') and a disclaimer ('Not medical advice'), which are useful but minimal. The description does not contradict annotations.

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

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

The description is extremely concise: one sentence for purpose followed by two necessary statements. Every sentence adds value with no redundancy or filler.

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

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

For a relatively simple tool with three parameters and an output schema (not shown), the description covers the core purpose and a key prerequisite (scope). It does not explain return values, but the presence of an output schema mitigates this. It is adequately complete for an AI agent to use 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?

The input schema already describes all three parameters with details (date format, privacy_mode enums, response_format). The description adds no additional parameter meaning. Given schema coverage is 67% and the schema is descriptive, baseline 3 is appropriate.

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

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

The description clearly states 'Get weight logs for a date,' specifying the verb and resource, and the tool name itself indicates the data type (weight) and time granularity (day). Among siblings like fitbit_get_sleep_day and fitbit_get_heart_day, it is uniquely identifiable. The short description is sufficient and 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 description mentions 'Requires weight scope,' which gives a prerequisite but does not explicitly state when to use this tool versus alternatives like fitbit_daily_summary or fitbit_weekly_summary that may also include weight data. No when-not or situational guidance is provided.

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

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

Annotations already declare readOnly, openWorld, and idempotent hints. The description supplements with behavioral specifics: bounded series, 500-point cap, agent-safe-series/v1 contract, and a 'Not medical advice' disclaimer. It does not contradict annotations; slight deduction for not disclosing potential response-size limits beyond the cap, though the cap itself is useful.

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

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

The description is three sentences, with each sentence adding meaningful information: the core capability, guidance on alternatives, and the shared contract plus disclaimer. It is front-loaded with the primary purpose and contains 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 read-only series tool with an output schema, the description covers the primary purpose, the 500-point cap, preference ordering, and cross-platform compatibility. It could mention response formatting or the exact output type, but the output schema exists and fills those gaps. Overall quite 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 88%, so the baseline is 3. The description reinforces that the series is downsampled and capped at 500 points, which relates to max_points and resolution_seconds, but it does not add per-parameter semantics that the schema already provides. Since the schema handles parameter documentation, a 3 is appropriate.

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

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

The description clearly identifies the tool as a bounded heart-rate time-series for a civil day, with exact stats on full-resolution samples and a downsampled series capped at 500 points. It distinguishes itself from fitbit_get_heart_day by emphasizing the 'shape of HR over the day' and references a shared series contract.

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 instructs to prefer fitbit_get_heart_day or daily summary first, and to use this tool only when the shape of HR over the day is needed. Naming concrete alternatives and providing a clear when-to-use condition fully satisfies this dimension.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the tool supports cursor, pagination, and privacy modes, which aligns with schema parameters. It does not contradict annotations and provides some behavioral context, but does not disclose additional traits like rate limits or data freshness.

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

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

The description is extremely concise: two sentences that immediately convey the core purpose and key capabilities. Every sentence adds value, and the most important information (the action) is front-loaded. No redundant or vague phrases.

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 9 parameters and an output schema, the description is minimal but covers the main features. However, it omits important context such as default sorting order, behavior when both 'after' and 'before' are provided (schema says mutually exclusive, but description should confirm), or pagination limits. The presence of an output schema reduces the need to describe return values, but some behavioral details are 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 89%, so the schema already documents parameters well. The description mentions cursor, pagination, and privacy modes but does not add new meaning beyond what is in the schema. For example, it does not explain the difference between 'after' and 'before' or the effect of 'privacy_mode' beyond the schema's own descriptions. Baseline of 3 is appropriate.

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

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

The description clearly states the verb 'List' and the resource 'Fitbit activity logs', making the purpose obvious. It also mentions supported features like cursor, pagination, and privacy modes. However, it does not explicitly differentiate from sibling tools like fitbit_get_activity or fitbit_get_activity_day, though the name implies a listing action.

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 notes the required scope ('Requires activity scope') but provides no guidance on when to use this tool versus alternatives like fitbit_get_activity_day or fitbit_list_sleep. There is no mention of scenarios where this tool is inappropriate or when another tool should be preferred.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds the authorization context ('settings scope'), which goes beyond annotations. No additional behavioral traits (e.g., return format) are described, but annotations cover safety well.

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

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

The description is a single sentence with no wasted words. It is front-loaded with the main purpose and efficiently states the requirement.

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

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

Given the presence of an output schema and the simple nature of listing devices, the description is fairly complete. It lacks mention of potential nuances like pagination or device types, but these are likely handled by schema/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 67% (2 out of 3 parameters have descriptions). The description does not add any parameter meaning beyond the schema; it remains at the baseline for moderate coverage.

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 explicitly states 'List devices connected to the authenticated Fitbit account,' which clearly identifies the action (list) and resource (devices). It distinguishes from sibling tools like fitbit_list_activities or fitbit_list_sleep, which target different data types.

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 mentions a prerequisite ('Requires settings scope'), but does not specify when to use this tool versus alternatives or provide any exclusions. Usage is implied but not explicitly guided.

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 idempotentHint=true. Description adds 'Requires sleep scope' and 'Not medical advice', which are minor. No contradiction. For a read-only tool, the behavioral context is sufficient but not enhanced beyond annotations.

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

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

Three sentences: purpose, features, requirement. Front-loaded and efficient. Could be slightly more structured, but no waste.

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 9 parameters, high schema coverage, and an output schema, the description covers key aspects (cursors, pagination, privacy, scope). Missing details on explicit_user_intent and response_format are minor given the structured schema and 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 coverage is high (89%), so baseline 3. Description groups parameters as 'before/after cursor, pagination and privacy modes', providing a high-level overview but not adding significant detail beyond schema descriptions.

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

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

The description clearly states 'List Fitbit sleep logs', a specific verb+resource. It mentions features like cursor, pagination, privacy modes, distinguishing it from siblings like fitbit_get_sleep_day (single day).

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

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

The description implies listing vs single-day via features but lacks explicit when-to-use or when-not-to-use. 'Requires sleep scope' is a prerequisite, but no exclusion criteria or alternatives 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?

Description starts with 'Read-only' and lists return items, but lacks details on authentication requirements or potential errors. Annotations already cover safety, so the description adds moderate value.

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 'Read-only', no fluff. Every sentence provides necessary information efficiently.

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 lack of output schema, the description adequately covers what the tool returns and when to use it. Minor gaps in structural details, but sufficient for agent usage.

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 50% and the description clarifies locale options but does not explain the response_format parameter. The description adds some value but not enough to fully compensate for the coverage gap.

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

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

The description clearly states the tool returns the 11-question Delx Wellness onboarding flow, shared profile, missing fields, and a hint. It distinguishes from sibling tools that fetch specific health metrics or perform other actions.

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 specifies usage when starting a fresh wellness session and lists fields to fill out, providing strong context. It does not explicitly mention when not to use it, but no sibling tool overlaps.

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 idempotentHint=true, indicating safe read-only behavior. The description adds context by specifying it returns local privacy, cache, token-path, and env-presence posture without revealing secrets, which goes beyond the annotations by clarifying the scope and safety guarantee.

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

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

The description is a single sentence that front-loads the key information: what the tool returns and a critical constraint (no secret values). Every word serves a purpose, and there is 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?

The tool has one optional parameter and an output schema. The description explains the core purpose and a safety guarantee, which is sufficient for a simple audit tool. However, it could improve by briefly noting the output format option (markdown/json) or clarifying that it is safe to call repeatedly. Overall, it is nearly complete given the tool's simplicity.

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

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

The input schema has 0% description coverage, meaning no parameter descriptions are provided. The description does not mention the 'response_format' parameter or its enum values (markdown, json). Although the parameter name and enum are self-explanatory, the description fails to compensate for the lack of schema descriptions, which is a gap given the low coverage.

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

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

The description clearly states the tool returns local privacy, cache, token-path, and env-presence posture while explicitly noting it does not reveal secret values. This distinguishes it from siblings like fitbit_cache_status, which focus on specific aspects. The verb 'Return' and specific nouns give a precise purpose.

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

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

The description implies the tool should be used for auditing privacy posture without exposing secrets, but it does not explicitly state when to use it over alternatives like fitbit_cache_status or fitbit_connection_status. No when-not-to-use or prerequisite guidance is provided.

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 idempotentHint=true. The description adds valuable context by explaining the profile contains only onboarding input and never OAuth tokens, API keys, or biomarkers, enhancing transparency beyond the annotations.

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

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

The description is two sentences long, front-loaded with the action and scope, and each sentence adds distinct value. No unnecessary words; perfectly concise.

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

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

Given the tool's simplicity (one optional param, no output schema, rich annotations), the description covers the main aspects: what is read, sharing context, and safety. It lacks only an explanation of the response_format parameter, but overall it is adequate.

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

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

The input schema has one parameter (response_format) with no description in schema (0% coverage). The tool description does not mention this parameter, so it adds no meaning beyond the schema. While the schema provides enum and default, the description should have clarified the parameter's purpose.

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

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

The description clearly states the tool reads the 'canonical Delx Wellness profile' shared with other wellness MCP connectors, distinguishing it from sibling tools that access specific Fitbit metrics. It specifies the resource and action, avoiding tautology.

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

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

The description implies usage context by mentioning the profile is shared across wellness connectors, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The guidance is clear but not comprehensive.

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?

Beyond annotations (which are minimal), the description adds critical behavioral context: the need for user intent and filtering of sensitive fields. However, it doesn't detail merge behavior or success/error responses.

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 succinct sentences with no fluff; the first sentence establishes the core purpose immediately.

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 write tool with three parameters and no output schema, the description adequately covers safety and data sensitivity, though it omits mention of return values or errors.

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?

While the schema covers 67% of parameters with descriptions, the description adds value by explaining that the patch is partial and that secret-like fields are rejected, which is not in 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 clearly states the action ('persist a partial patch') and the resource ('canonical Delx Wellness profile'), which distinguishes it from sibling tools that are mostly read-only or auth-related.

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

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

The description explicitly requires explicit_user_intent=true after user confirmation and specifies rejection of secret-like fields, but does not mention alternatives or when not to use among siblings.

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

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

Discloses adaptive behavior based on current state (env vars, token), which adds value beyond annotations that already indicate read-only, idempotent, non-destructive nature.

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 with zero wasted words; purpose is front-loaded and efficiently conveys key points.

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

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

Given the tool's simplicity (one optional parameter, no output schema) and good annotations, the description fully covers when and why to use it.

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

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

Only parameter (response_format) is not described in the description; schema coverage is 0% and description does not compensate for this lack of parameter documentation.

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?

Clearly states it's a personalized 3-step setup walkthrough for connecting Fitbit, specific verb+resource and distinguishes from data retrieval siblings.

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

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

Explicitly says 'Call this first when the user asks how do I connect Fitbit?' providing clear context, though no explicit when-not or alternatives are stated; sibling differentiation implies alternatives.

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 indicate destructiveHint=true and readOnlyHint=false. The description adds the specific detail of deleting the local token file, which is useful but not a major extension beyond the hints. No contradiction.

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 concise sentences covering purpose and usage. Front-loaded with the core action. No redundant 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?

With annotations and output schema present, the description covers essential context for a destructive tool. Could note consequences after revocation, but overall adequate.

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 50% (only explicit_user_intent has a description). The description adds context for explicit_user_intent but does not explain response_format. Baseline 3 for moderate coverage; limited additional value.

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

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

The description clearly states the action (revoke OAuth grant and delete token file) and the resource (Fitbit access). No sibling tools perform revocation, so it distinguishes well.

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 states 'Use only when the user explicitly wants to disconnect Fitbit' and references the required 'explicit_user_intent' parameter. Provides clear context for appropriate invocation.

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 provide safety hints (readOnly, idempotent, non-destructive). Description adds that it is read-only and non-medical, plus lists the metrics included. This provides useful behavioral context beyond the annotations.

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

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

Extremely concise: one sentence stating purpose and content, plus a short disclaimer. No filler. Front-loaded with the key phrase 'weekly Fitbit scorecard'.

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

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

Given the rich annotations and existing output schema, the description covers the core functionality well. Missing mention of the comparison feature (compare_days) or response format options, but these are captured in the input 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 already describes 3 out of 4 parameters (75% coverage). The description does not elaborate on parameter usage or constraints beyond what schema provides. No additional semantics added.

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?

Description explicitly states it builds a weekly scorecard with specific health metrics: activity, sleep, heart-rate, HRV availability, bottlenecks, and actions. Clearly distinguishes from sibling tools like fitbit_daily_summary (daily) and fitbit_wellness_context (general context).

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 alternatives. Does not mention that it provides a summary vs detailed daily data, or when to choose this over fitbit_daily_summary or fitbit_wellness_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 indicate read-only, idempotent, non-destructive behavior. The description adds the target output shape (wellness_context) and purpose (recommendation engines), but does not disclose additional behavioral traits like error handling or limitations.

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

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

The description is a single sentence that conveys the core purpose without any wasted words. It is front-loaded and efficient.

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

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

Given the tool has six parameters and an output schema, the description is too brief. It does not explain what the wellness_context shape is or how the parameters affect normalization. The tool's complexity warrants more detail to fully guide an 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?

With schema description coverage at only 33%, the description should compensate by explaining parameters. It only implicitly relates 'days' to the lookback window, but leaves the other four parameters (notes, soreness, injury_flags, response_format) completely unexplained, failing to add meaning beyond the sparse 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 clearly states the tool's action: 'Normalize Fitbit sleep and activity load into the shared wellness_context shape for recommendation engines.' It uses specific verbs and nouns, and distinguishes itself from sibling tools that retrieve raw data rather than normalizing 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?

No explicit guidance on when to use this tool versus alternatives like fitbit_get_sleep_day or other retrieval tools. There is no mention of prerequisites, context, or 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.