Google Health Fitbit MCP

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

The description adds behavioral context beyond annotations by clarifying the tool does not call Google Health APIs and does not expose secrets. Annotations already indicate read-only, idempotent, and non-destructive behavior. The description confirms these traits and adds specific safety guarantees, complementing the annotations 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 concise sentence that is front-loaded with essential information. Every word contributes to understanding the tool's purpose and safety. There is no unnecessary text.

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 (two optional parameters with enums, output schema present), the description is complete enough. It covers purpose, safety, and non-interaction with Google Health. The rich annotations and output schema provide the remaining context.

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 enums and defaults for both parameters (client, response_format), but schema description coverage is 0%. The tool description does not explain the meaning of these parameters or how they affect the manifest output. The enums give some context, but the description adds no additional clarity beyond what is already in the schema.

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

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

The description clearly states the tool provides machine-readable install, runtime, and client guidance for AI agents. It distinguishes itself from sibling tools that interact with Google Health data by explicitly stating it does not call Google Health or expose secrets. The purpose is specific 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 implies use for setup or configuration guidance but does not explicitly state when to use this tool versus alternatives like google_health_quickstart or google_health_onboarding. No when-not or exclusion criteria are provided. Usage context is only implicit.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the cache is a local SQLite cache, which is helpful context. However, it does not disclose any additional behavioral traits 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?

The description is a single sentence that front-loads the core purpose ('Show optional local SQLite cache status') and includes necessary usage hints. No wasted words.

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

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

Given the tool's simplicity (one optional parameter, read-only, output schema exists), the description is mostly complete. It could mention that the output format is controlled by the parameter, but that is implicit.

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

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

Schema description coverage is 0%, meaning the description adds no meaning to the single parameter (response_format). The parameter has an enum, but the description does not explain its purpose or values, relying entirely on the schema.

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

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

The description clearly states the tool shows optional local SQLite cache status. It uses a specific verb ('Show') and resource ('cache status'), distinguishing it from sibling tools like google_health_connection_status. However, it could be more precise about what 'status' entails (e.g., enabled, size).

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

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

The description provides clear context for when to use this tool: it is relevant only if the cache is enabled via environment variables. It does not explicitly state when not to use it or list alternatives, but the condition is clearly implied.

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

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

Description aligns with annotations (readOnlyHint, idempotentHint, destructiveHint). Adds useful context about beta status and privacy boundaries 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?

Single sentence, efficient and front-loaded. Slightly too brief for a capabilities overview but acceptable.

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?

Adequately covers the tool's role given the presence of an output schema. Explains what the tool does without needing to detail return values.

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 has one parameter (response_format) with 0% description coverage. The description does not mention this parameter or its effect, failing to compensate for the lack of 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 the tool's purpose: explaining supported health data, privacy boundaries, beta status, and recommended workflow. It effectively distinguishes itself from sibling tools that perform data retrieval or setup tasks.

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

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

Implies usage before interacting with other tools to understand scope. No explicit when-not-to-use or alternatives, but context is clear for an introductory tool.

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. The description adds critical context: no Google API calls, no secrets exposure, and checks specific local items. This goes 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?

The description is a single, efficient sentence that front-loads the action verb 'Check' and lists all relevant items without unnecessary 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 read-only diagnostic tool with an output schema, the description covers the state space comprehensively: local config, token, Node version, privacy mode, cache, and MCP client readiness. The output schema likely handles return structure, so no further detail needed.

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 2 parameters (client, response_format) with enums and defaults, but schema description coverage is 0%. The description does not explain any parameter meaning or behavior. While the parameters are simple, the description fails to add value for parameter semantics.

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 configuration, token file, Node version, privacy mode, cache readiness, and optional MCP client readiness. It emphasizes that no Google APIs are called and no secrets are exposed, distinguishing it from sibling tools like google_health_capabilities or google_health_cache_status.

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 local health checks without external calls. It does not explicitly state when not to use or compare to alternatives, but the sibling context shows distinct purposes, making usage relatively 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 indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that it aggregates over civil days, which is consistent, but does not reveal additional behavioral traits 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 extremely concise: two short sentences that front-load the purpose and examples with no unnecessary 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?

Given the tool's complexity (9 parameters, 3 enums, pagination), the description is too brief. It omits details on date range semantics, window_size_days effect, pagination, and privacy options, leaving the agent under-informed.

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 only 33% schema description coverage, the description should compensate but does not explain key parameters like start_date, end_date, window_size_days, or pagination. It only indirectly references the data_type parameter through examples.

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 aggregates a data type over civil days, with examples like steps and distance. However, it does not distinguish itself from related sibling tools like google_health_rollup or google_health_daily_summary.

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

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

The description suggests it is useful for common health metrics, but it does not specify when to use this tool versus alternatives, nor does it mention prerequisites or 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 cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds 'beta' and 'non-medical', informing agents of reliability and scope. This adds value beyond 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 two concise segments, each earning its place. It front-loads the action and constraints efficiently with 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?

Given the tool has an output schema (not shown but indicated as present), the description does not need to detail return values. It covers input purpose, data sources, and important constraints. The simplicity of the tool (3 optional params) makes this 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 coverage is low (33%), and the description adds no parameter details. While parameters are simple, the description should compensate for low coverage but does not. The schema provides some info for timezone and response_format, but the description adds nothing.

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 builds a 'practical daily summary' from 'Google Health rollups and reconciled streams', with read-only, beta, and non-medical qualifiers. This is a specific verb+resource that distinguishes it from sibling tools like google_health_daily_rollup and google_health_weekly_summary.

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

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

While no explicit alternative guide is given, the description implicitly tells when to use it: for a summarized daily view from available rollups and reconciled streams. The 'beta, non-medical' note provides context but no direct when-not-to guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint false. The description adds valuable context that the tool operates without calling Google APIs, informing the agent of no network side effects or latency. 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?

The description is a single sentence that is front-loaded with the core action and key outputs. Every word adds value with no redundancy or wasted space.

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

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

Given an output schema exists, the description does not need to explain return values. It lists the included information (data types, auth scopes, privacy modes, recommendations), which is sufficient for an inventory tool. Could mention the output format, but the output schema likely covers that.

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

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

The schema has one optional param with 0% description coverage. The description does not mention the param, but the param (response_format) is self-explanatory from its enum. The low coverage would normally require compensation, but the trivial nature of the param makes this acceptable. Score 3 as minimal but adequate.

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

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

The description clearly states it inventories supported Google Health data types, auth scopes, privacy modes, and recommended first calls. However, it does not explicitly differentiate from similar sibling tools like google_health_data_type_coverage, although the additional items (auth scopes, privacy modes, recommendations) provide implicit distinction.

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

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

The description hints at usage by noting 'without calling Google APIs' and 'recommended first calls', suggesting it is a safe, informational starting point. However, it lacks explicit when-to-use, when-not-to-use, or alternatives among the many sibling 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 and idempotentHint=true. The description adds value by stating that live mode returns only redacted status and point-count buckets, never raw health payloads, which is behavioral context beyond annotations. No contradictions.

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, front-loading the core purpose and mode distinction without any redundant or irrelevant information. Every sentence serves a clear purpose.

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 complexity (5 parameters, low schema coverage, and an output schema), the description is adequate but lacks context such as prerequisites for live mode (OAuth setup) and how the output is structured despite the output schema. It does not fully guide the agent on when to use each mode.

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 40%, but the schema itself provides descriptions for all parameters, including enum lists and patterns. The tool description does not add meaning beyond what the schema already offers, so it meets the baseline but does not compensate for 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 builds a data-type coverage plan or runs live read-only checks, specifying that live mode returns only redacted status. It differentiates from sibling tools like google_health_list_data_types by emphasizing coverage planning and the non-raw nature of live output, though it does not explicitly name alternatives.

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 two usage modes but does not provide explicit guidance on when to use this tool versus siblings, such as google_health_list_data_types for listing types or google_health_get_data_point for raw data. No when-not or alternative suggestions are included.

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?

Adds context beyond annotations by specifying it returns example payloads, consistent with readOnlyHint.

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, front-loaded sentence with no wasted words.

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

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

Complete for a demo tool with few parameters and annotations; no output schema needed.

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 has 0% description coverage and description does not mention the one parameter, though the parameter name and enum are self-explanatory.

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 example payloads of specific real APIs, distinguishing it from sibling tools that return actual 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?

Implies use before calling real APIs, but lacks explicit when-not-to-use or alternative selection 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?

Discloses that tokens are stored locally with 0600 permissions and never returned. This adds valuable context beyond annotations (readOnlyHint=false, destructiveHint=false) 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?

Two sentences clearly stating purpose, behavioral details, and usage constraint. 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?

Describes the main action, side effects, and usage constraint. The output schema exists to cover return values. Could mention what happens after tokens are stored (e.g., other tools use them) but overall complete for a simple tool.

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

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

Schema coverage is only 50% (code has description, response_format lacks one). Description adds no parameter details, so it does not compensate for the missing description in the schema.

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

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

Description clearly states the verb 'Exchange' and the resource 'Google OAuth authorization code for local tokens'. It distinguishes from all siblings as no other tool performs this specific exchange. Includes behavioral and usage constraints.

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 that the tool requires explicit user intent and agents must not call autonomously. This provides strong usage guidance, though alternatives are not mentioned because no sibling does the same thing.

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 convey readOnlyHint, idempotentHint, and destructiveHint. The description adds minimal behavioral detail beyond the usage guidance and the obvious URL generation. It does not elaborate on the OAuth flow, redirect, or user interaction required.

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 highly concise, consisting of two short sentences that each serve a distinct purpose: stating the tool's function and providing usage guidance. No extraneous information is present.

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 simplicity of the tool (generating an OAuth URL with three parameters) and the presence of an output schema, the description is largely complete. It could be slightly improved by indicating that this is the first step in a two-step OAuth flow, but it is 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?

With 67% schema description coverage, the input schema already explains two of three parameters. The description does not add any extra semantics or constraints beyond the schema, so it meets the baseline for this dimension.

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 generates a Google OAuth authorization URL for the Google Health API. It directly describes the verb and resource, and while it doesn't explicitly distinguish from sibling tools, the distinction is clear given the presence of google_health_exchange_code for the next 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 provides clear context for when to invoke the tool, though it lacks mention of when not to use it or alternatives (e.g., skipping if token already exists).

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. Description adds critical context: only works for data types with 'get' in official_operations, and explains privacy_mode override defaults. 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 sentences, front-loaded with purpose and examples, then qualification about supported data types. No wasted words.

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

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

For a tool with 4 params, output schema, and clear annotations, the description covers purpose, usage, data type constraints, id format, and optional privacy override. Complete without being verbose.

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%, with good params docs. Description adds value by clarifying that data_point_id accepts full resource name from previous responses, which is not fully explicit in schema. For data_type, it references list_data_types for dynamic validation.

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 'Fetch one data point by id' with examples (sleep session, exercise, weight entry), distinguishing it from sibling list/reconcile tools. The verb 'get' and resource 'data point' are specific.

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 advises using this tool after list/reconcile to fetch a specific entry. Mentions prerequisite to check data type support via google_health_list_data_types, and accepts both bare id and full resource name, 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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds no additional behavioral details beyond confirming it retrieves identity mapping, which is consistent but not additive.

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 concise sentences with no extraneous words. It is front-loaded with the core action. However, the structure could benefit from a brief note on the meaning of 'identity mapping' to reduce ambiguity.

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 2 optional parameters, comprehensive annotations, and an output schema (not shown but indicated). The description provides a minimal but functional overview. It does not explain the return format (covered by output schema) or when to use this versus identity-related siblings (e.g., google_health_get_profile), leaving some gap in completeness.

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 privacy_mode has a description; response_format lacks one). The tool description does not mention or clarify the parameters, leaving the agent to infer meaning from the schema alone. With low coverage, the description should compensate but fails to do so.

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 the Google Health identity mapping for the authenticated user and explicitly mentions a specific use case (Fitbit-to-Google migrations), distinguishing it from sibling tools that handle data points, profiles, or settings.

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

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

The description gives a concrete usage scenario (Fitbit-to-Google migrations), which implies when to use the tool. However, it does not explicitly exclude other use cases or compare with alternative tools like google_health_get_profile, though the sibling list is large and diverse.

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 and idempotentHint. The description adds value by specifying the exact scope needed and labeling the operation as 'non-diagnostic', which provides practical safety guidance beyond the structured hints.

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 only two sentences with no redundant words. The first sentence immediately states the core action, and the second provides essential context. Every sentence earns its place.

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

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

The description covers the tool's primary function and a critical requirement (scope). With an output schema existing, return value documentation is not needed. Minor omission: no mention of when to use the privacy_mode or response_format parameters, but those are self-explanatory from the 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?

The description provides no additional information about the two parameters beyond what is already documented in the input schema. Since the schema descriptions cover both parameters adequately, 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 states the verb 'Get', the resource 'irregular rhythm notification (IRN) engagement status', and specifies the concrete data point 'whether the AFib detection feature is enabled'. This distinguishes it from sibling tools like google_health_get_profile by targeting a specific health feature.

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 mentions the required scope and setup command, which guides credential preparation. However, it does not contrast with alternative tools or state when not to use it, leaving some ambiguity in context of the sibling list.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is clear. The description adds the authentication scope requirement, which is useful but not extensive. 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—two short sentences with no unnecessary words. It front-loads the action and resource, and every sentence adds value.

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

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

Given the tool's simplicity, rich annotations, and the presence of an output schema, the description covers the core behavioral context (auth scope) adequately. Minor gaps like error handling or return format are mitigated by other structured fields.

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 both parameters ('privacy_mode' and 'response_format'), so schema coverage is high. The description does not add any additional meaning beyond what the schema already provides, warranting a baseline score of 3.

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 'Get authenticated user profile details from Google Health', clearly specifying the action (get) and the resource (user profile). The title reinforces this. Although sibling tools like 'google_health_get_identity' and 'google_health_profile_get' exist, the description's direct language distinguishes it effectively.

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 'Requires profile scope', a key prerequisite, but offers no guidance on when to use this tool over alternatives like 'google_health_profile_get' or 'google_health_get_identity'. No exclusions or contextual use cases are 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 indicate read-only, idempotent, non-destructive behavior. Description adds the context that a settings scope is required, which is useful beyond annotations. No contradictions.

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 clear, front-loaded sentences with no wasted words. Efficiently conveys purpose and a key 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 an output schema exists and annotations cover safety, the description briefly mentions scope and examples, which is adequate for a simple read tool. Could mention pagination or limits but not necessary.

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 low (50%) and the description does not add any parameter details beyond what the schema already provides. The description fails to compensate for missing 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?

Description clearly states the tool retrieves authenticated user settings (units and timezone), uses a specific verb ('get') and resource ('settings'), and distinguishes from sibling tools like get_profile or get_identity.

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 retrieving user settings but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or comparisons 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 indicate readOnly, idempotent, and non-destructive. The description adds context about kebab-case data types but does not elaborate on pagination, filtering behavior, or response details. Minimal added value 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 extremely concise (two sentences) and front-loaded with the key action and resource. Every word adds value, with 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?

Given the presence of a full output schema and comprehensive annotations, the description sufficiently covers the tool's purpose and key usage detail (kebab-case). The minimal description is complete enough for an experienced user.

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%, and the description provides minimal additional meaning (e.g., emphasizing kebab-case). The schema itself describes most parameters adequately. The description does not significantly compensate for the uncovered 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 uses a specific verb 'Query' and resource 'data points for a Google Health data type', clearly distinguishing it from siblings like 'get_data_point' (single) and 'list_data_types' (types only). Examples (e.g., 'steps') further clarify.

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?

While the description implies usage for querying data points of a given type, it lacks explicit guidance on when to use this vs. alternatives like 'get_data_point' or 'daily_summary'. No when-not-to-use or alternative recommendations are 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 indicate read-only and idempotent, but description adds critical context: 'Static metadata; does not call Google APIs.' This informs agents about zero latency and no side effects 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?

Three sentences, each with distinct value: output content, usage guidance, and behavioral note. No filler words. Front-loaded with the main purpose.

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

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

The tool is simple with one optional parameter and output schema exists, so description is complete: explains output (slugs with metadata), usage context, and that it's static. No gaps for a lookup tool.

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

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

Schema coverage is 0%, so description should explain the single parameter. While the parameter name and enum values are self-explanatory, the description does not explicitly mention that response_format controls output type. Baseline of 3 is appropriate as no misinformation, but lacks direct clarification.

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 uses specific verb 'List' and identifies resource 'canonical kebab-case data_type slugs' with clear attributes (unit, OAuth scope, supported verbs). Explicitly distinguishes from sibling tools like list_data_points by stating 'Call this before...'.

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 when to use ('before list_data_points, reconcile_data_points, daily_rollup or rollup') and why ('to choose a valid data_type instead of guessing a slug'). Lacks explicit when-not-to-use, but context is 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=true, idempotentHint=true, and destructiveHint=false, fully describing the safety profile. The description adds the redundant 'Read-only' and the scope 'authenticated account', which adds minimal new behavioral context. It 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 two sentences with no superfluous text. It front-loads the core purpose and immediately follows with a practical use case. Every word earns its place, making it highly efficient for an agent to parse.

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

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

Given the tool's simplicity (list with pagination and optional parameters) and the presence of an output schema, the description provides the core purpose and one use case but omits details on pagination, parameter behavior, and how privacy_mode or response_format affect output. The low schema coverage exacerbates this gap.

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

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

The input schema has 4 parameters with only 25% description coverage (just privacy_mode). The description does not mention any parameter, their defaults, or usage. The agent must rely entirely on the schema, which lacks sufficient documentation for page_size, page_token, and response_format. This is a significant gap.

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

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

The description specifies the verb 'List' and the resource 'devices paired to the authenticated Google Health account' with concrete examples (Fitbit trackers, Pixel Watches). This clearly distinguishes the tool from siblings like list_data_points and list_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 provides a clear use case ('is my watch syncing?' and identifying device-data associations). However, it does not explicitly warn against using this tool when other operations are needed, nor does it mention any exclusion criteria. The context is helpful but lacks contrast with 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it is read-only and does not persist, reinforcing the safety profile. Also discloses cross-connector profile sharing, a key behavioral detail 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?

Two sentences, front-loaded with purpose and read-only note, then pairing guidance and cross-connector context. Efficient, no extraneous text. Every sentence adds value.

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

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

No output schema, but description explains return value (onboarding flow, profile state, missing fields). Also covers cross-connector sharing and required pairing. With 2 optional params and clear intent, the description is sufficiently complete for agent understanding.

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% (2 params both with schema descriptions). Description does not add additional parameter semantics beyond what the input schema already provides (locale defaults, response_format enum). Baseline score of 3 is appropriate as the schema carries the burden.

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 the tool returns the 11-question onboarding flow, current profile state, and missing fields. It explicitly notes read-only behavior. Distinguishes from siblings like google_health_profile_get (profile only) and google_health_profile_update (update) through pairing guidance.

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 explicitly pairs with google_health_profile_update once answers are provided, giving clear usage context. It also notes cross-connector profile sharing, helping agents understand integration. Lacks explicit when-not-to-use, but pairing guidance is strong.

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 read-only and idempotent. Description adds value by clarifying that no secret values are revealed, which is critical for an audit tool. Provides specific items audited: privacy, cache, token-path, env-presence.

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 key info. Some jargon ('env-presence posture') slightly reduces clarity, but overall 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?

With a single optional parameter and annotations present, the description is adequate but lacks elaboration on what 'posture' entails or how the output is structured. Could 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?

The only parameter (response_format) has 0% schema description coverage. The description does not mention or explain this parameter, missing an opportunity to clarify output options.

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 returns privacy, cache, token-path, and env-presence posture without revealing secrets. Verb 'Return' and resource 'posture' are specific. Distinguishes from sibling tools like cache_status or connection_status because it focuses on privacy audit.

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 like cache_status or data_inventory. No exclusions or context 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, idempotentHint, and destructiveHint=false. The description adds valuable context: 'NEVER contains OAuth tokens or API secrets,' which is a behavioral guarantee beyond the annotations. No contradictions.

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 serving a distinct purpose: the first states the action and source, the second lists returned content, and the third provides a security assurance. 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?

The tool is simple (one optional param, no output schema, read-only). The description covers the core functionality and safety, but it lacks guidance on the response format parameter and usage context relative to siblings. This leaves some gaps for an agent to fully understand tool invocation.

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

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

The schema has one parameter (response_format) with 0% description coverage. The description does not mention this parameter at all, leaving the agent unaware that it can request markdown or json output and the default behavior. For a tool with low schema coverage, the description should compensate but does not.

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 a shared Wellness profile from a specific file path and enumerates the contents (preferred name, goals, devices, etc.). It distinguishes this from sibling tools like `google_health_get_profile` by specifying 'Wellness profile' and the file location.

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 does not provide explicit guidance on when to use this tool versus alternatives. It mentions 'Read-only' but does not compare with sibling tools such as `google_health_get_profile` or explain scenarios for choosing this over others.

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 key behaviors beyond annotations: requires explicit user intent, rejects secret-like fields. Annotations are consistent. Does not detail side effects or return format, but adequate.

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

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

Two compact sentences: first states action, second adds constraints and use-cases. No redundancy, 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?

Covers purpose, constraints, and allowed fields. No output schema but description outlines expected usage. Could mention return value, but sufficient given 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?

Adds meaning by listing patch top-level keys (profile, goals, devices, etc.) beyond schema's minimal 'partial patch' description. Response_format and intent param are clear from 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 it persists a partial patch to a specific file, with listed fields like preferred name, goals, etc. This distinguishes it from read-only siblings like google_health_get_profile.

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 conditions: requires explicit_user_intent=true and rejects secret fields. However, it does not directly contrast with sibling tools or specify when not to use.

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 stating that the walkthrough adapts to current state (env vars, token presence). This behavioral trait is not covered by annotations, which already correctly indicate read-only, idempotent, non-destructive behavior.

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

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

Two sentences, front-loaded with the primary purpose and then additional context. Every sentence is informative and efficient with no wasted words.

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

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

Given the simple input schema (one optional parameter) and no output schema, the description provides sufficient context for an agent to decide when to call and what to expect. Minor gap: no mention of response_format parameter, but overall complete for a quickstart walkthrough tool.

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

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

Schema description coverage is 0%, so the description should compensate for the parameter. However, the description does not mention the optional response_format parameter at all, leaving the agent without guidance on how to use it.

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's a personalized setup walkthrough, specifies it adapts to current state, and explicitly tells when to call it ('how do I connect Google Health?'). It distinguishes itself as the entry point among many sibling tools.

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

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

The description explicitly says 'Call this first when the user asks...', providing clear when-to-use guidance. It doesn't explicitly mention when not to use or alternatives, but the context is sufficient for the intended use case.

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 destructiveHint=false, so the description need not repeat safety. It adds 'reconciled stream' context but does not disclose further behavioral traits like performance or limits. Baseline score given annotation coverage.

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 very concise (two sentence fragments) with no wasted words. However, it could be slightly more informative without harming 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 7 parameters and the existence of an output schema, the description is insufficient. It does not explain key concepts like reconciliation, pagination, or the meaning of privacy_mode and response_format. Multiple sibling tools exist, but context for selection is lacking.

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 only 43%, with several parameters having minimal descriptions. The tool description adds no parameter semantics; it does not mention any parameters or their usage. Thus fails to 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?

Description clearly states 'Read a reconciled stream for one data type across sources' using specific verb and resource. It distinguishes from sibling tools like list_data_points (which lists individual points) and get_data_point (single point). Also mentions supported data source families.

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

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

Implies usage for reconciled data across sources and lists supported data source families. However, does not explicitly provide when-to-use vs alternatives like list_data_points or get_data_point, nor when to avoid.

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 mark destructiveHint=true and readOnlyHint=false. The description adds that the local token file is deleted, which is useful behavioral context. It also reinforces the need for explicit user intent, addressing safety. However, it does not describe post-revocation effects like requiring re-authentication.

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: first states the action, second provides usage guard. No unnecessary words, front-loaded with the core behavior. Extremely 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 simplicity (one optional param, output schema exists, annotations cover destructiveness), the description covers purpose, usage restriction, and immediate effect. Could mention irreversibility or need for re-authentication, but overall sufficient for safe invocation.

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

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

Schema description coverage is 0%, but only one optional parameter (response_format) exists, which is self-explanatory from its name and enum. The description does not reference this parameter or add any meaning beyond the schema. While trivial, it fails to compensate for the lack of 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 'Revoke the current Google OAuth grant and delete the local token file', indicating the exact action and resource. Among sibling tools focused on authentication setup or data retrieval, this is the only revoke tool, distinguishing it clearly.

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 Google Health' and 'Gated: requires explicit user intent — agents must not call this autonomously', providing clear conditions for use and when to avoid 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 indicate read-only and idempotent behavior. The description adds little beyond the verb 'aggregate', not explaining what 'physical-time rollup' entails or how results are structured.

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 is concise but arguably too brief for a tool with 9 parameters. It is straightforward but lacks structural elements like examples or lists.

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 complexity (9 parameters, output schema, many siblings), the description is insufficient. It does not explain the rollup concept, differentiate from daily_rollup, or provide usage context.

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 provides descriptions for 56% of parameters. The description does not add any additional parameter-level meaning or clarify ambiguous fields like window_size or privacy_mode.

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?

Specifies verb 'aggregate' and resource 'data type over physical time intervals', clearly indicating the action and scope. However, it does not explicitly differentiate from closely related siblings like google_health_daily_rollup.

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 like daily_rollup or daily_summary. No prerequisites or situational context 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 provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds beta status, non-medical disclaimer, and missing-data awareness, enhancing transparency 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?

Single sentence includes all key aspects without redundancy. Very 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?

Output schema exists so return values are covered. Description covers purpose, data types, and behavioral traits. Could mention output format or comparison window usage, but overall 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 coverage is 75%, so baseline is 3. Description does not explain any parameters beyond what schema provides, adding no extra meaning.

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 specifies the tool builds a weekly scorecard covering activity, sleep, heart context, and missing-data awareness. It differentiates from siblings like daily_summary by specifying weekly scope and heart 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?

Description implies usage for weekly reviews but does not explicitly state when to use vs alternatives like daily_summary or rollup. No exclusions or alternatives 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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false. The description adds the normalization step but no further behavioral traits (e.g., what happens with missing data, performance). It 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 a single concise 16-word sentence with clear verb and resource. It is front-loaded and contains no unnecessary information. However, it could be slightly more structured to separate purpose from usage.

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 6 parameters (no required), an output schema (explaining return values), and rich annotations, the description is adequate but minimal. It does not explain the 'normalize' operation or how this tool fits into the broader workflow with siblings. Additional context would improve completeness.

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 only 33% (2 of 6 parameters have descriptions). The tool description does not mention any parameter meanings or usage, leaving 4 parameters undocumented in both schema and description. Defaults exist but without semantic context.

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 (Normalize), the resource (Google Health activity/sleep context), and the target (shared wellness_context shape for recommendation engines). It differentiates from siblings by focusing on normalization and a specific output format.

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 use for recommendation engines but provides no explicit guidance on when to choose this tool over alternatives among the many siblings, nor any conditions or exclusions.

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