Withings MCP

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 value by explicitly stating it 'does not call Withings or expose secrets', confirming no external side effects or security risks beyond what annotations show.

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 defines the purpose, and the second clarifies constraints. Every word adds value, and 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 tool's simplicity (optional parameters, no required fields, output schema present), the description covers core purpose and safety. However, it could be more complete by mentioning the parameters or the structure of the manifest output, even though output schema exists.

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 the description fails to explain the two parameters ('client' and 'response_format') or their enums. While parameter names and defaults offer some self-evidence, the description does not clarify their purpose, which is necessary given 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 provides 'Machine-readable install, runtime and client guidance for AI agents' with a specific verb and resource. It distinguishes itself from siblings by explicitly noting it 'Does not call Withings or expose secrets', setting it apart from data retrieval or action 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 the tool is for obtaining configuration guidance but does not explicitly state when to use it over alternatives like withings_capabilities or withings_cache_status. No usage exclusions or context are provided, leaving the agent to infer from the name and 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 indicate read-only and idempotent behavior. The description adds context about enabling caching via environment variables, which is a behavioral prerequisite not captured in 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, front-loading the core purpose and adding a practical note about enabling the cache. 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?

While the tool is simple and has an output schema, the description leaves ambiguity about what the status output actually contains (e.g., enabled/disabled, size, etc.) and does not clarify behavior when cache is not enabled.

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 mention the 'response_format' parameter at all. With 0% schema description coverage, the description should compensate but fails to add any meaning beyond the schema's enum 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 verb 'Show' and resource 'optional local SQLite cache status', and distinguishes it from sibling tools which focus on other functionalities like connection status or data retrieval.

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 is provided on when to use this tool versus alternatives. The description only explains what it does and how to enable the cache, but does not specify scenarios where checking cache status is appropriate.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context about explaining data, privacy, and workflow, but it does not disclose additional behavioral traits beyond what annotations provide. 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, concise sentence that front-loads the verb 'Explain' and includes all key elements: data, privacy boundaries, workflow, and links. Every word earns its place 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?

For a simple informational tool with a single optional parameter and an output schema, the description sufficiently covers what the tool does. It could optionally mention that it is for the agent to understand capabilities, but it is already complete enough for its purpose.

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 an enum with values 'markdown' and 'json', and it is self-explanatory from its name and enum values. Although schema description coverage is 0%, the parameter is trivial, and the description does not need to elaborate further. The description adds marginal value over 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's purpose: 'Explain supported Withings data, privacy boundaries, recommended agent workflow and project links.' It uses a specific verb ('Explain') and resource ('capabilities'), and it distinguishes itself from sibling tools that focus on specific data or 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 understanding the tool's capabilities and context, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. It meets the minimum viable standard but lacks explicit 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 read-only, idempotent, non-destructive behavior. The description adds valuable insight: it explicitly states that the tool does not call Withings or expose secrets, which goes beyond the annotations to clarify what it does NOT do.

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 conveys the tool's purpose and scope. It is front-loaded and contains no verbose or redundant 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?

While the description covers the main purpose and the output schema likely handles return values, the omission of parameter semantics reduces completeness. For a tool with 0% schema description coverage, the description should explain the parameters to be fully informative.

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% for the two parameters. The description fails to explain the purpose of the 'client' and 'response_format' parameters, leaving a significant gap. The parameter names are somewhat self-explanatory, but the description should explicitly link them to the tool's behavior.

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 that the tool checks local Withings config, token file, Node version, privacy mode, cache readiness, and optional MCP client readiness, all without external calls or exposing secrets. This distinguishes it from siblings that perform API calls or other specific checks.

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 when to use this tool (checking local connection status without external calls), but does not explicitly state when not to use it or name specific alternatives. However, the context is clear enough for an AI agent to differentiate from 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 provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds 'Read-only and non-medical', which is consistent but adds minimal extra context. 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?

The description is two short sentences, front-loaded with the main action. Every word is meaningful with no 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?

The description gives a reasonable overview but lacks details on data availability handling, expected output structure (though output schema exists), and specific use cases. Adequate 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 elaborate on any of the three parameters (days, timezone, response_format). With schema coverage at 67%, the description adds no additional meaning beyond what the schema already provides.

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

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

The description clearly states the verb 'Build' and the resource 'daily summary', and specifies the data sources (activity, sleep, body/heart). It distinguishes from sibling tools like withings_list_activity and withings_weekly_summary by focusing on a consolidated 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 does not explicitly state when to use this tool versus alternatives. While it mentions 'when available', it lacks guidance on scenarios where raw data listings or weekly summaries might be more appropriate.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds that it does not call Withings APIs or expose user data, providing extra safety 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?

Two sentences: first states what it does, second clarifies what it does not. No wasted words. Front-loaded with action verb.

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 metadata inventory tool, description covers purpose, scope, and safety boundaries. Output format is presumably defined in the output schema, which is present but not shown. Complete for its intended simple use.

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 one parameter (response_format) with enum and default. Schema has 0% description coverage, and tool description does not mention the parameter. However, the parameter is self-explanatory given its name and enum 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 verb 'inventory' clearly indicates this tool returns a list/metadata. It specifies exactly what is inventoried: supported data domains, auth scope requirements, privacy boundary, and recommended first calls. This distinguishes it from sibling tools that fetch actual user data 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?

Description mentions 'recommended first calls', implying it should be used before data retrieval tools. It does not explicitly state when not to use or name alternatives, but the context of being a metadata tool makes usage 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 and destructiveHint=false. The description adds context about returning example payloads, but 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?

A single, front-loaded sentence that is clear and concise 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?

For a simple demo tool with one parameter and no output schema, the description adequately explains its purpose and value (previewing contracts). It could mention that no authentication is needed, but annotations already indicate safety.

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

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

Schema coverage is 0%, and the description does not add any meaning beyond the schema for the single parameter. The baseline is 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 clearly states what the tool does: returns realistic example payloads of three specific Withings tools. It distinguishes itself from the many sibling tools that are real API endpoints.

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 before calling real Withings APIs to preview payloads. While it doesn't explicitly say when not to use, the purpose is distinct enough 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?

Annotations indicate mutability and non-idempotence. The description adds critical behavioral context: tokens are stored locally and never returned, and the exchange uses a signed request flow. 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 well-structured sentences: the first states purpose and method, the second provides a critical usage constraint. No wasted words, all information 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?

For an OAuth token exchange tool with an output schema present, the description adequately covers the core behavior (exchange, store, no return) and the need for user-supplied code. Minor omissions (e.g., overwrite behavior for existing tokens) are acceptable given the tool's relative 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?

Schema coverage is 50%. The description adds meaning for the 'code' parameter by requiring it to come from user action, but provides no additional information for 'response_format'. It compensates partially but not fully for the missing parameter 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 uses a specific verb ('Exchange') and clearly identifies the resource ('OAuth authorization code for local tokens'). It distinguishes well from sibling tools like withings_get_auth_url (which provides the URL) and withings_revoke_access (which revokes tokens).

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 user action ('the user must complete browser OAuth') and warns agents not to invent codes. It provides clear context on when to use the tool, though it does not explicitly mention when not to use it or name 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, idempotentHint, and destructiveHint, so the description does not need to repeat these. It adds usage context but no further behavioral details 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?

Two concise sentences with no wasted words. Front-loaded with the core action and usage context.

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 existence of an output schema and annotations, the description is minimally adequate. It covers the initial step of OAuth but does not elaborate on next steps or the output format. Sufficient for a simple tool 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% (moderate), but the description provides no additional parameter meaning. The input schema already has descriptions for state and scopes, yet response_format has only enum/default without description, and the description does not compensate for this missing info.

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 Withings OAuth authorization URL' with a specific verb and resource, and distinguishes it from siblings by noting 'Use this first when no local token exists.'

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 by specifying 'Use this first when no local token exists,' implying when to use it and suggesting an ordering relative to other tools like withings_exchange_code. However, it does not explicitly name 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the permission requirement (user.activity scope), which is useful but minimal. It does not disclose pagination behavior, data freshness, or any edge cases, so it adds some value beyond annotations but not rich context.

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

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

The description is extremely concise—two sentences with no fluff. The purpose is front-loaded and the scope requirement is valuable. However, given the tool's complexity, a bit more context could be warranted, but the brevity is not a flaw in itself.

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 8 parameters and many sibling list tools, this description is inadequate. It doesn't explain what 'daily activity summaries' entail, how pagination works, or how it differs from other list tools. The output schema covers return values, but the tool's role and selection criteria are missing, leaving a significant gap.

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

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

Schema coverage is 88%, so the schema already documents most parameters in detail. The description adds nothing about parameters, such as how 'after' and 'before' work or what 'privacy_mode' does. With high coverage, the baseline of 3 is appropriate; the description neither helps nor hurts.

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 the verb 'List' and the resource 'Withings daily activity summaries', which is clear and specific. It distinguishes from siblings like list_workouts and list_sleep by naming 'activity', though it doesn't explicitly contrast with them. 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 (user.activity scope) but gives no guidance on when to choose this tool over alternatives like list_workouts or list_body_measures. There is no explicit context for typical use cases or exclusions, leaving the agent to infer when this tool is appropriate.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds the scope requirement and a safety disclaimer, which is useful context beyond annotations. However, it does not mention pagination behavior, privacy_mode handling, or return format, though these are partially covered by the schema. Given the annotation coverage, a 3 is appropriate.

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 no fluff. The core purpose is front-loaded, followed by two essential caveats. 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 rich schema (8 parameters, all described, output schema present) and strong annotations, the description is sufficient for an agent to understand the tool's purpose and call it correctly. It misses a bit of detail on output format or privacy, but those are in the schema. Overall, it's complete enough for the tool's complexity.

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 most parameters are already described. The description itself adds no parameter-specific details beyond what the schema provides. Baseline 3 is correct because the schema does the heavy lifting.

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

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

The description states a specific verb ('List'), a specific resource ('Withings punctual measurements'), and gives concrete examples ('weight and body composition'). This clearly distinguishes it from sibling tools like withings_list_activity or withings_list_sleep.

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 only mentions a prerequisite (requires user.metrics scope) and a disclaimer (not medical advice), but gives no guidance on when to choose this tool over alternatives. It does not explicitly mention sibling tools or conditions for preferring one over another.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond annotations: the 'Requires user.metrics scope' auth requirement and the 'where available' caveat indicating that heart data may not always be present. It also includes a 'Not medical advice' disclaimer. These go beyond the structured metadata, though it does not detail pagination or rate-limit behavior, which are minor given the 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?

The description is three sentences with zero waste. The purpose is front-loaded, and the auth requirement and disclaimer follow. Every sentence earns its place; it is appropriately sized for a list tool with rich schema metadata.

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 8 parameters and an output schema, and annotations cover safety, so the description need not repeat those. However, it lacks explicit usage guidance relative to sibling tools (e.g., when to choose heart records over sleep or activity lists) and does not mention pagination behavior beyond what schema hints imply. The description is minimal but adequate given the structured metadata; still, the missing usage context leaves a gap for a tool with many siblings.

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% (7 of 8 parameters have descriptions), so the schema already documents the parameters thoroughly. The description adds no parameter-specific information, which is acceptable given the high coverage. Per the rubric, baseline is 3 when schema coverage is high, and the description does not compensate beyond that.

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 ('List') and resource ('Withings heart records'), and adds the qualifier 'where available' to indicate conditional availability. It clearly differentiates from sibling list tools like withings_list_body_measures and withings_list_activity by naming the specific data type. 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 clear context: it requires the user.metrics scope and notes that heart records may not always be available. However, it does not explicitly state when to use this tool over alternatives (e.g., for heart rate data specifically) nor when not to use it. With many sibling list tools, more explicit routing would be helpful, but the scope requirement gives some usage 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, and destructiveHint false, covering the safety profile. The description adds useful context beyond annotations: the required 'user.activity' scope, the caveat that data may not always be available ('where available'), and a medical disclaimer. This provides meaningful behavioral insight without contradicting 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 extremely concise, consisting of three short sentences that front-load the primary purpose, then add the scope requirement and a disclaimer. There is zero fluff; every sentence earns its place.

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

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

With an output schema present and high schema coverage, the description does not need to explain return formats or parameters. It covers the essential purpose, scope prerequisite, and data availability caveat. It lacks explicit sibling differentiation, but that is minor given the schema's richness 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?

Schema description coverage is 88%, so the schema already documents all parameters thoroughly (e.g., 'after' and 'before' explain conversion to epoch). The tool description adds no parameter-level information, which is acceptable given the high schema coverage. 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 states a specific verb ('List'), resource ('detailed Withings sleep data'), and a condition ('where available'). It clearly distinguishes from the sibling tool withings_list_sleep_summary by emphasizing 'detailed', making the tool's purpose 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 usage through the phrase 'where available' and mentions a required scope, but it does not explicitly state when to use this tool over alternatives like withings_list_sleep_summary or when not to use it. No exclusion or alternative routing 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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the scope requirement and a disclaimer, which is useful but minimal. It does not disclose any additional behavioral traits (e.g., how privacy_mode works, pagination behavior) 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?

Two sentences with zero fluff. The purpose, scope, and disclaimer are front-loaded and each 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 has 8 parameters, an output schema, and many sibling tools, the description is quite sparse. It does not explain how this differs from withings_list_sleep or when to use it, and it leaves the meaning of 'common sleep fields' undefined. However, the schema and output schema carry substantial information, so it is not severely incomplete, but it could do more to orient the agent.

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

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

Schema description coverage is 88%, so the schema already documents all parameters in detail. The description adds no parameter-specific meaning, so it rests at the baseline 3 for high 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?

States a specific verb and resource ('List Withings sleep summaries'), which is clear. However, it does not differentiate from sibling tools like withings_list_sleep or withings_list_workouts; the name and description imply a summary variant but without explicit distinction, so it loses a point.

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 only notes the required scope ('user.activity') and a disclaimer ('Not medical advice'), but provides no guidance on when to choose this tool over alternatives, no exclusions, and no context about whether to prefer this over withings_list_sleep or other list 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, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the authentication requirement of 'user.activity scope', which is useful and not in the annotations. However, it does not describe pagination behavior or return format details, though an output schema exists to cover that.

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 that states the core action and a key requirement with no fluff. It is appropriately concise for a list tool, though it omits usage context, which is a completeness issue rather than a conciseness problem.

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 list tool with an output schema and well-documented parameters, the description is minimally adequate. It does not explicitly mention pagination or date filtering, but these are covered in the schema. Given the tool has 8 parameters and no required fields, a bit more context on how to combine them could help, but it is not severely 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 88%, meaning most parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what the schema already provides, so it does not compensate for the small uncovered portion. Given the high schema coverage, 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 states a clear action ('List') and a specific resource ('Withings workouts'), distinguishing it from sibling tools that handle other data types like activity or sleep. It is unambiguous about what the tool retrieves, though it does not elaborate on the content of a workout beyond the name.

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

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

No guidance is provided on when to use this tool versus alternatives such as withings_list_activity or withings_daily_summary. The only contextual hint is the required scope, which is a prerequisite, not a usage scenario. There is no mention of typical use cases, exclusions, or when to prefer another 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=true, destructiveHint=false, and idempotentHint=true. The description reinforces with 'Read-only — does NOT persist anything' and adds cross-connector sharing behavior, providing useful context 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?

Three front-loaded sentences with zero wasted words: the first states core functionality and read-only nature, the second provides pairing instructions, and the third adds cross-connector 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?

Given the tool's moderate complexity (2 optional params, no output schema), the description adequately covers the return type (11-question flow, profile state, missing fields) and side effects (read-only, cross-connector). It lacks detail on the exact structure of the response but is sufficient for an AI agent to understand what to expect.

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 50% schema description coverage (locale has description, response_format does not), the description does not add any parameter-specific information. The schema already covers the enum values and defaults, so the description offers no additional value for parameter semantics, meeting the baseline for this coverage level.

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 returns the 11-question onboarding flow plus current profile state and missing fields, using the verb 'Return'. It distinguishes itself from siblings by specifying pairing with withings_profile_update and cross-connector profile sharing, making its purpose unmistakable.

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 explicit usage guidance: 'Pair with withings_profile_update once the user answers.' It also implies when to use (to get onboarding flow and profile) and alludes to alternatives via sibling context. However, it does not explicitly state when not to use or list alternatives, which would raise the score to 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the behavioral guarantee of not revealing secret values, and lists the categories of information returned, which adds 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?

Single sentence, front-loaded with the key purpose, no unnecessary words. Every part 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?

With output schema present and annotations, the description is minimally viable but does not explain what 'local privacy, cache, token-path, env-presence posture' entails. A brief expansion would improve understanding for new users.

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% for the only parameter (response_format). The description does not mention this parameter or explain that it controls output format (markdown vs json). The agent must infer from the enum and default alone, which is insufficient.

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' without revealing secrets. The verb 'Return' specifies output, and the scope is distinct from sibling tools like withings_cache_status or withings_profile_get.

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 vs alternatives like withings_cache_status. The description implies a privacy-focused use case but does not provide when-to-use or when-not-to-use 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?

Adds value beyond annotations by specifying file location and confirming absence of secrets, complementing readOnlyHint 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 focused sentences, front-loaded with action, followed by content and safety note; 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?

Adequate for a simple read-only tool with one parameter; lists returned fields but omits structure details or error scenarios.

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?

Description does not mention the response_format parameter despite 0% schema coverage, leaving agents to infer from the enum and default.

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 reads a specific file and returns specific fields, distinguishing it from write/update siblings like withings_profile_update.

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 through 'Read the shared Delx Wellness profile' but does not explicitly compare to siblings or state 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?

Adds significant behavioral context beyond annotations: describes that secret-like fields are rejected at write time and that the operation requires explicit user intent. Annotations only indicate non-read-only and non-destructive, so description fills gaps.

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?

Concise and well-structured: front-loaded with action and path, followed by conditions, restrictions, and use cases. No superfluous sentences.

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 all key aspects: what it does, required parameters, behavioral constraints, and typical use cases. No output schema exists, so return value description is not needed. Complete enough for a write operation.

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 beyond the input schema by explaining that the patch is partial and lists the top-level keys. Also clarifies the required condition for explicit_user_intent. Schema coverage is 67%, and description compensates well.

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 persists a partial patch to a specific file, with an explicit verb and resource. Lists the categories of fields that can be updated, distinguishing it from sibling tools like withings_profile_get which is read-only.

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 the condition that explicit_user_intent must be true, but does not explicitly guide when to use this tool versus alternatives (e.g., when to create vs update vs other operations).

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 value by highlighting that the walkthrough adapts to environment variables and token presence, which is useful behavioral 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?

Two sentences front-load the key information (purpose and usage). Could potentially be more concise by removing parenthetical questions, but overall it's 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 is a walkthrough with no output schema, the description adequately conveys its purpose and adaptability. However, it could be improved by briefly describing what the walkthrough returns or how the response format parameter affects it.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not mention the only parameter (response_format) at all. The parameter has a default and enum, but no guidance on its meaning or use.

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 3-step setup walkthrough for connecting Withings, with a verb (walkthrough) and specific resource (setup with Withings). It distinguishes from siblings by specifying it's the first call for setup queries.

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 Withings?"' and mentions it adapts to current state, providing clear when-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 indicate destructiveness (destructiveHint: true), and the description adds context by specifying that it deletes the local token file and that it only clears local access (not full API revocation). This provides valuable behavioral insight 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, covering key points: the action, its scope (local-only), and the gating condition. No extraneous information, highly 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 two parameters (one with enum), destructive nature, and presence of an output schema, the description covers the main behavioral aspects and the gating condition. It does not explain return values, but the output schema likely covers that, so the description is nearly complete.

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

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

Schema description coverage is 50%, with only explicit_user_intent having a description. The tool description reinforces the gating role of explicit_user_intent but does not address the response_format parameter. Therefore, it partially compensates for the missing schema description.

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 ('Delete the local Withings token file') and the specific resource, distinguishing it from sibling tools like 'withings_connection_status' or 'withings_cache_status'. It also clarifies the limitation of local-only clearing, making its purpose 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 the gating by explicit_user_intent but does not provide explicit guidance on when to use this tool versus alternatives. It notes that revocation support varies, but no alternatives or conditions for use are stated beyond requiring user intent.

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, idempotentHint, etc. The description adds non-medical disclaimer and summarizes the content, providing extra behavioral context 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 brief (two sentences) and front-loaded with the main purpose. No unnecessary words, though it could be slightly more structured with bullet 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 presence of output schema and annotations, the description is adequate but lacks guidance on when to prefer this over related siblings. It does not explain how the scorecard is generated or any limitations.

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 all four parameters having descriptions. The tool description does not add further parameter-specific details, 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 clearly states it builds a weekly scorecard including sleep, activity, body measures, bottlenecks, and actions. It uses a specific verb 'build' and resource 'weekly scorecard', distinguishing it from daily summary or 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?

The description mentions 'Read-only and non-medical' but does not explicitly state when to use this tool over alternatives like withings_daily_summary. No guidance on when not to use or preferred contexts.

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 annotations already declare readOnlyHint, openWorldHint, idempotentHint as true, and destructiveHint as false, covering the safety profile. The description adds the context of normalization but does not disclose any additional behavioral traits beyond what the annotations provide. 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 a single sentence of 14 words, front-loaded with the key verb 'Normalize'. Every word is meaningful, with no filler or redundant information. It achieves 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 complexity (normalization, 6 parameters, output schema present), the description is brief. It does not explain what the shared wellness_context shape contains, but an output schema exists to document returns. The tool's role among many siblings is somewhat clear but could be more complete regarding when to choose this normalization tool over raw data retrieval.

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 description does not provide any parameter-level information; it does not mention or explain parameters like notes, soreness, injury_flags, or response_format. The value added over the schema is minimal, and the low coverage demands more compensation.

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 'Normalize' and identifies the resource 'Withings sleep and activity load' and the target 'shared wellness_context shape'. It clearly distinguishes this tool from sibling tools that retrieve raw data (e.g., withings_list_sleep, withings_list_activity) or summaries (e.g., withings_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 hints at the use case ('for recommendation engines') but does not provide explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it. Sibling tools like withings_weekly_summary or withings_list_sleep are not mentioned for differentiation.

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