Server Quality Checklist

Tool Scores

• withings_get_devicesC
  2.1/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds only the minor scoping detail 'linked', but does not explain behavior such as returning a list, authentication requirements, or any caveats. For a tool with strong annotations, this adds minimal value.

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

  Conciseness2/5

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

  The description is under-specified rather than appropriately concise. A single fragment 'Your linked Withings devices.' provides almost no useful information and fails to earn its place, unlike a clear one-sentence description such as 'List the Withings devices associated with your account.'

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

  Completeness2/5

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

  With no output schema, the description bears the responsibility to explain what the tool returns. It only states possession ('your linked devices') without clarifying whether the output is a list, what fields are included, or how to interpret the result. This is inadequate even for a simple read tool.

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

  Parameters4/5

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

  There are zero parameters, so the schema fully covers all inputs. The description does not need to explain parameters, and baseline for 0 params is 4; no deduction needed.

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

  Purpose2/5

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

  The description 'Your linked Withings devices.' is essentially a restatement of the title 'Devices (Withings)' and lacks an explicit verb. It vaguely implies retrieval but does not clearly state that it lists or fetches devices, nor does it distinguish itself from sibling tools like withings_get_activity.

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

  Usage Guidelines1/5

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

  There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are provided.

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

• withings_get_goalsC
  2.8/5.0
  Behavior2/5

  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, covering the safety profile. The description adds no additional behavioral context, such as what data is returned, whether goals are current or historical, or any prerequisites. Thus it does not go 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.

  Conciseness4/5

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

  The description is a single, short phrase with no extraneous content. It is concise and front-loaded, though it could be slightly clearer as a full sentence.

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

  Completeness2/5

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

  There is no output schema to clarify return values, and the description is too minimal to be complete. It does not explicitly state that the tool retrieves goals or describe the format of the goals (e.g., current, daily, units). Given the simple nature and strong annotations, more context would be expected.

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

  Parameters4/5

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

  The input schema has zero parameters, so the base score is 4 per the guidelines. The description does not need to explain parameter meanings since there are no parameters to describe.

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

  Purpose3/5

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

  The description 'Your step/sleep/weight goals' identifies the resource (goals for steps, sleep, and weight), which distinguishes it from sibling tools like withings_get_activity. However, it lacks a verb indicating the action (e.g., 'retrieve' or 'list'), making the purpose somewhat vague and relying on the tool name for clarity.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as withings_get_activity or withings_get_sleep. The description simply states what the goals are, without explaining the use case or exclusions.

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

• withings_get_workoutsC
  2.9/5.0
  Behavior3/5

  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 that the output includes workout type, duration, calories, and HR, but it does not disclose behavioral details such as date range handling, pagination, or authentication requirements.

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

  Conciseness4/5

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

  The description is a short, single phrase with no fluff, making it easy to scan. It front-loads the core resource and key return fields. However, it is so brief that it borders on under-specification, omitting crucial input context.

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

  Completeness2/5

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

  For a tool with only two date parameters and no output schema, the description should at least mention the date range requirement. It lists output fields but entirely ignores input semantics, and it lacks usage differentiation from the many sibling 'get' tools. An agent would not know how to properly invoke this tool from the description alone.

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

  Parameters1/5

  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 for the undocumented startDate and endDate parameters. It does not mention them at all, nor does it clarify that the tool queries workouts within a date range. The parameter names are self-explanatory, but the description adds no meaningful semantics beyond the schema.

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

  Purpose4/5

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

  The description identifies the resource (workouts) and lists key attributes (type, duration, calories, HR), which clearly distinguishes it from sibling tools like withings_get_activity or withings_get_sleep. However, it is a noun phrase without an explicit verb, relying on the tool name 'get' to convey the action.

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

  Usage Guidelines3/5

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

  Usage is implied by the resource name and description: it is for logged workout data. No explicit guidance is given on when to use this tool vs alternatives, nor are any exclusions or prerequisites stated, leaving the agent to infer based on sibling tool names.

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

• withings_get_sleepA
  3.5/5.0
  Behavior3/5

  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 distinction between summary and detailed modes, which is useful, but does not disclose any other behavioral traits like rate limits or data coverage.

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

  Conciseness5/5

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

  A single, front-loaded sentence that contains no fluff. Every word contributes to conveying the tool's function and the key parameter behavior.

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

  Completeness3/5

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

  The tool is simple with three parameters and no output schema; the description covers the core choice but omits information about the response structure or additional caveats. It is minimally adequate but not comprehensive.

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

  Parameters3/5

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

  Schema coverage is 0%, so the description carries some burden. It explains the effect of the 'detailed' parameter (toggle to high-frequency phases) but does not elaborate on startDate/endDate; however, these are self-explanatory date range parameters, so the description provides marginal additional meaning.

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

  Purpose4/5

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

  The description clearly states it retrieves per-night sleep summaries or high-frequency phases, with a specific verb and resource. It distinguishes the tool from siblings by topic, though it doesn't explicitly name alternative tools.

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

  Usage Guidelines3/5

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

  The description implies when to use this tool (for sleep data) and provides guidance on using 'detailed=true' for high-frequency phases. However, it does not explicitly state when not to use it or mention alternative tools for other health metrics.

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

• withings_add_measureA
  3.7/5.0
  Behavior3/5

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

  The description adds 'Requires write access,' which is a useful prerequisite and aligns with readOnlyHint=false. However, it does not disclose other behavioral traits such as whether the operation creates a new entry, any return value, or potential side effects. Annotations already cover the safety profile, but the description adds minimal beyond that.

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

  Conciseness5/5

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

  The description is two short sentences that are front-loaded with the primary action and example, followed by a critical prerequisite. Every word contributes to the meaning, with no redundancy or filler.

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

  Completeness3/5

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

  For a simple write tool with no output schema, the description does not explain what the agent should expect on success (e.g., confirmation, status code) or any side effects. While the schema and annotations cover parameters and safety, the absence of return-value information is a notable gap, making it minimally viable.

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

  Parameters3/5

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

  All three parameters are fully described in the schema (type, value, date), with clear examples and defaults, so the baseline is 3. The description's example 'weight in kg' duplicates what the schema already states, adding little extra meaning beyond the schema.

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

  Purpose5/5

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

  The description states a clear, specific verb ('log') and resource ('body measurement'), with a concrete example ('weight in kg'). It distinguishes from the sibling get_* tools by indicating a write operation ('manually log'), 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.

  Usage Guidelines3/5

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

  The description implies the tool is for manual logging when the user wants to input a measurement, but it does not explicitly state when to use this tool versus alternatives (e.g., withings_get_measures for reading). No exclusions or alternative tools are mentioned, so usage guidance is only inferred.

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

• withings_get_activityA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds that the tool returns daily summaries for a date range, providing some behavioral context. However, it fails to mention the 'intraday' option that changes the output granularity, which is a significant behavioral trait not covered by annotations. 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.

  Conciseness5/5

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

  The description is a single concise sentence that is front-loaded with key information. Every word ('Daily steps/calories/distance/active minutes for a date range') contributes value without redundancy. It is appropriately sized for the tool's simplicity.

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

  Completeness3/5

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

  The tool is a read-only query with 3 parameters and no output schema. The description gives a high-level summary but omits the intraday mode and the response structure. While annotations cover safety, the lack of output schema and low parameter coverage means the description should clarify what the agent can expect from the return value and the effect of the intraday flag. It is minimally complete but has clear gaps.

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

  Parameters2/5

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

  Schema description coverage is only 33% (only intraday is described). The description compensates slightly by explaining that startDate and endDate form a date range, but it does not elaborate on the intraday parameter or the exact format/meaning of the parameters. Given the low coverage, the description should add more parameter-specific context, but it only provides a minimal hint.

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

  Purpose5/5

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

  The description clearly states the tool returns daily steps, calories, distance, and active minutes for a date range. This specific enumeration of metrics distinguishes it from sibling tools like get_sleep, get_workouts, and get_heart. The verb 'get' plus the resource 'activity' makes the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description implicitly establishes when to use this tool: when daily activity metrics (steps, calories, distance, active minutes) are needed. It clearly contextualizes the date-range requirement, but it does not explicitly mention alternatives or when not to use it. The clarity of the metric types serves as sufficient guidance for most cases.

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

• withings_search_capabilitiesA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description has a lighter burden. It adds the 'Use first' behavioral cue but does not describe return values or how the search behaves beyond that, which is adequate but not rich.

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

  Conciseness5/5

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

  The description is extremely concise with two short sentences that immediately convey purpose and priority. Every word earns its place, and there is no redundant filler or structured data repetition.

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

  Completeness3/5

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

  The tool is simple, and annotations provide a clear safety profile, but the description lacks details about what the search returns or how to interpret results. Given the openWorldHint and no output schema, a bit more context about the response would improve completeness, but the essential purpose is covered.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not mention the 'query' or 'limit' parameters at all. The parameter names are intuitive, but the description fails to compensate for the lack of schema documentation, leaving their exact semantics underspecified.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with a specific verb ('Find') and resource ('the right Withings tool'), distinguishing it from sibling tools that perform actual data retrieval. The phrase 'Use first' further clarifies its role as a discovery helper.

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

  Usage Guidelines4/5

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

  The instruction 'Use first' provides explicit guidance on when to invoke this tool, placing it before any other Withings sibling tool. It lacks explicit when-not-to-use or alternative recommendations, but the directive is clear and contextually sufficient for a discovery tool.

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

• withings_get_measuresA
  4.1/5.0
  Behavior4/5

  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, covering the safety profile. The description adds valuable behavioral context by listing common meastype codes and the default behavior (weight+composition), which informs the agent about expected output scope. It doesn't mention pagination or units, but that gap is 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.

  Conciseness5/5

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

  The description is two sentences: the first states the core purpose, and the second lists common codes and defaults. Every sentence earns its place, there is no redundancy, and the most important information (purpose) is front-loaded.

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

  Completeness3/5

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

  The tool has no output schema, so the description should ideally explain what the response contains (e.g., units, structure). It covers the input parameters and defaults well, but it omits return format and pagination behavior. Given the simplicity of the tool and the strong annotation profile, this is an adequate but not complete description.

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

  Parameters4/5

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

  Schema coverage is 50%: meastypes and lastUpdate have descriptions, while startDate and endDate do not. The description compensates by explaining the date-range concept and providing the numerical meastype codes, adding meaning beyond the raw schema. It doesn't fully describe all parameter nuances, but it significantly enhances understanding of how to use the parameters.

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

  Purpose5/5

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

  The description clearly identifies the tool as retrieving body measurements by type and date range, and lists common meastype codes that distinguish it from sibling tools like withings_get_activity or withings_get_sleep. The verb 'get' is inherent in the name, and the resource ('Body measurements') 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.

  Usage Guidelines3/5

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

  The description gives usage context (measurements by type/date, defaults to weight+composition) but does not explicitly state when to use this tool over sibling tools such as withings_get_activity or withings_get_sleep. The differentiation is implicit through the meastype list and the domain of body composition, but no direct alternatives or exclusions are mentioned.

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

• withings_disconnectA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds specific context by stating exactly what is removed ('stored Withings tokens') and where ('from this server'). It does not contradict annotations and provides sufficient behavioral detail beyond the structured fields.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the action 'Remove' and immediately specifies the object and destination. There is no filler or redundancy; every word earns its place.

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

  Completeness5/5

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

  Given the tool's simplicity (no parameters, no output schema, strong annotations), the description fully covers the necessary context. It states what the tool does and the scope ('this server'), making it complete for an agent to decide when and how to invoke it.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema is empty. According to the rubric, a baseline of 4 is appropriate. The description does not need to explain parameters, and it avoids adding any redundant parameter information.

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

  Purpose5/5

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

  The description clearly states the tool's verb and resource: 'Remove your stored Withings tokens from this server.' It specifies both the action (remove) and the target (tokens) and distinguishes it from sibling tools that fetch or add data. This is a specific, non-tautological purpose statement.

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

  Usage Guidelines3/5

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

  The description implies the usage context: use this tool when you want to disconnect Withings by removing stored tokens. However, it does not explicitly state when not to use it or mention alternatives. The context is clear from the name and siblings, but the guidance is not explicit.

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

• withings_statusA
  4.3/5.0
  Behavior4/5

  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 useful context by explicitly mentioning 'token freshness,' which informs the agent that the tool also checks token validity, not just link status. This goes beyond the basic annotation details and clarifies the behavioral scope.

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

  Conciseness5/5

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

  The description is a single, concise sentence that directly states the tool's purpose. It is front-loaded and contains no filler or redundant information. Every word contributes to the meaning, making it optimally concise.

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

  Completeness5/5

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

  For a tool with no parameters, no output schema, and straightforward annotations, the description is complete enough. It communicates the two key aspects of the status (link status and token freshness) without overcomplicating. The simplicity of the tool does not require additional detail, and the description fully enables correct selection and invocation.

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

  Parameters4/5

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

  The tool has zero parameters, so the schema is empty and there is nothing to document. The baseline for no parameters is 4, and the description appropriately adds no parameter-related confusion. The description correctly focuses on what the status check reports.

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

  Purpose5/5

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

  The description clearly states what the tool does: checks whether the Withings account is linked and if the token is fresh. It uses a specific resource (Withings account) and distinguishes this tool from sibling data-fetching tools (e.g., withings_get_activity) and connection-altering tools (e.g., withings_connect) by focusing on connection status.

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

  Usage Guidelines3/5

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

  The description implies this tool is for checking connection status, but it lacks explicit guidance on when to use it versus alternatives. It does not mention that it can be used before other Withings operations or that it is a read-only check. No clear 'when-not-to-use' or alternative references are provided.

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

• withings_get_heartA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds the dual-mode behavior (list by date range or fetch by signalId), which is not captured by annotations alone. It does not mention edge cases like conflicting parameters, but the core behavior is transparent.

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

  Conciseness5/5

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

  The description is a single, concise sentence (14 words) that front-loads the tool's purpose and key usage modes. No wasted words; every phrase adds value.

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

  Completeness4/5

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

  For a simple read tool with strong annotations and no output schema, the description adequately conveys the return context ('List' implies an array, 'fetch' implies a single ECG signal). It is missing clarification on parameter conflicts or required combinations, but overall it is reasonably complete for the tool's complexity.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description carries the burden. It maps startDate/endDate to the date-range list mode and signalId to the individual ECG fetch mode, adding meaning beyond the raw schema. It lacks details on parameter combinations (e.g., both date range and signalId) but effectively explains primary usage.

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

  Purpose5/5

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

  The description uses specific verbs ('List' and 'fetch') and names the resource ('heart/ECG recordings'), clearly distinguishing it from sibling tools like withings_get_activity and withings_get_sleep. It also identifies two distinct modes, making the tool's capabilities unambiguous.

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

  Usage Guidelines4/5

  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 the tool ('for a date range' vs 'by signalId'), but it does not explicitly mention alternatives or exclusions relative to sibling tools. Since the resource type is clearly heart/ECG, usage is implied but not compared against other getter tools.

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

• withings_connectA
  4.5/5.0
  Behavior4/5

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

  The description discloses the behavioral flow: it returns an authorization URL, requires user interaction in a browser, and establishes a persistent connection until disconnect/expiry. This adds depth beyond the annotations, which only hint at state-changing and external side effects. It does not explain the behavior if already connected, but that is a minor gap.

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

  Conciseness5/5

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

  The description is three concise sentences that are front-loaded with the primary action and then provide necessary steps and persistence context. Every sentence contributes relevant information with no redundancy or filler.

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

  Completeness5/5

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

  For a zero-parameter tool with no output schema, the description is complete: it explains the purpose, the returned artifact, the required user action, the effect on downstream tools, and the conditions for reuse. It fully covers the context an agent needs to invoke and understand the tool correctly.

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

  Parameters4/5

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

  The tool has zero parameters, so the description does not need to explain parameter semantics. The schema fully covers parameters (100% coverage) and there is nothing to add. Baseline 4 is appropriate for a parameterless tool.

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

  Purpose5/5

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

  The description clearly states 'Start linking YOUR Withings account' with an explicit verb and resource, and explains the OAuth flow. It distinguishes this tool from sibling data-retrieval tools and withings_disconnect by positioning it as the prerequisite setup step.

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

  Usage Guidelines4/5

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

  The description gives explicit guidance on when to use it: 'Needed once (and again only if you disconnect or the link expires).' It also implies 'use before data tools work,' but does not explicitly name any alternative tools. This is clear context with no exclusion, but lacks an explicit alternative comparison.

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