Server Quality Checklist

Tool Scores

• withings_get_activityA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description fully explains behavior: default uses cache, optional live fetch from API, returns sorted daily data with specific fields. It lacks mention of rate limits or auth, but those are secondary for a read tool. Overall, it provides sufficient behavioral context.

  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 well-structured: summary, default behavior, arguments with defaults, return format, exclusion. It is concise but not overly terse—each sentence adds value. Could be slightly tighter, but effective.

  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?

  Given the tool has 3 optional params, cache mechanism, and an output schema (so return values are documented there), the description covers prerequisites, usage, and alternatives. It lacks error handling notes, but for this simple tool, it is complete enough.

  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 compensates by explaining start_date format ('YYYY-MM-DD', 'YYYY-MM', or '30d') and default (last 30 days), end_date format and default (today), and live boolean meaning. This adds value 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 clearly states it gets daily activity summaries with specific metrics (steps, distance, calories, active time). It distinguishes from withings_get_workouts by explicitly stating 'Not for workout sessions -- use withings_get_workouts instead.' The verb 'get' and resource 'activity' are clear.

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

  Usage Guidelines5/5

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

  Explicitly says 'Run withings_sync first to populate the cache.' and 'Not for workout sessions -- use withings_get_workouts instead.' This provides clear when-to-use and when-not-to-use guidance with a named alternative.

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

• withings_get_devicesA
  4.6/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses that the tool fetches live data and returns device type, model, battery level, and last session date. This is sufficient for a non-destructive tool with no parameters, though additional details on authentication or rate limits could be beneficial.

  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 short sentences, front-loaded with the purpose. Every sentence adds value, and there is no redundancy or wasted words.

  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 no parameters and the presence of an output schema (not shown but indicated), the description is complete. It covers the purpose, behavior, and return fields adequately.

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

  Parameters5/5

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

  There are no parameters (0 params, 100% schema coverage). The description adds value by detailing what the return includes (battery level, firmware info), which goes beyond the empty schema. Baseline for 0 params is 4, and the added context warrants a 5.

  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 it gets connected Withings devices with battery and firmware info. The verb 'Get' and resource 'connected Withings devices' are specific, and it distinguishes itself from sibling tools that focus on other data types like activity or sleep.

  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?

  It notes that the data is 'Always fetched live from the Withings API,' implying when to use this tool (for live device status). However, it does not explicitly mention when not to use it or suggest alternatives, though the sibling names naturally guide usage.

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

• withings_get_workoutsA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description bears full responsibility for behavior. It clearly states it returns data 'sorted by date with type, duration, calories, distance, and heart rate data' and explains the default cache vs. live API behavior. It does not mention potential side effects (e.g., API rate limits), but as a read-only operation with no mutation, this is sufficient for transparency.

  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 well-structured with a summary, an 'Args' section, and a return/exclusion note. It is front-loaded with the purpose. The category list is long but necessary for completeness. Minor redundancy (repeating 'from cache' in both the first line and the 'live' description) could be trimmed, but overall it is appropriately concise.

  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?

  Given that an output schema exists (not shown here), the description need not enumerate return fields in detail, but it does mention the return content. It covers prerequisites, parameter semantics, and the scope limitation. It is complete enough for an agent to know when and how to invoke the tool without ambiguity.

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

  Parameters5/5

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

  Although the input schema provides no descriptions (0% coverage), the description text thoroughly explains each parameter. It specifies date formats ('YYYY-MM-DD', 'YYYY-MM', or '90d'), defaults ('last 90 days', 'today'), the category filter case-insensitivity and the full list of options, and the 'live' flag's effect. This adds meaningful semantics beyond the bare 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 clearly states the tool's purpose: 'Get workout sessions (type, duration, HR, calories).' It also explicitly distinguishes itself from the sibling tool by noting 'Not for daily step/activity totals -- use withings_get_activity.' The verb 'Get' and the resource 'workout sessions' are 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 Guidelines5/5

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

  The description provides explicit when-not guidance ('Not for daily step/activity totals') and names the alternative tool. It also gives a prerequisite: 'Run withings_sync first to populate the cache.' Additionally, it explains the 'live' parameter for fetching from the API instead of cache, offering clear decision-making guidance.

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

• withings_trendsA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It states the computation/return behaviour and the auto-sync side effect, but it does not fully spell out whether the sync mutates local storage or whether network access may occur; the mention of auto-sync implies this but leaves some ambiguity.

  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 well organised but contains some redundancy: 'Computes averages, min/max, and changes over time' is repeated as 'Returns aggregated averages with change indicators'. Still, it is concise overall and easy to scan.

  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?

  The description covers purpose, parameters, return content per data type, and explicitly routes raw-data requests to sibling getter tools. It also clarifies the cache/sync context, making it self-contained for an agent deciding between this tool and its siblings.

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

  Parameters5/5

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

  Although the input schema lacks descriptions, the prose explains every parameter: data_type options, period enum/default, start_date/end_date formats and defaults, and compare format including the rule that compare overrides the other date parameters. This is more than enough for an agent to fill the arguments correctly.

  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: analysing trends in cached health data with aggregates (averages, min/max, changes). It explicitly distinguishes itself from raw-data getters by naming the 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 Guidelines5/5

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

  It gives concrete guidance on when to use the tool (trends/aggregates) and when not to use it ('Not for raw data -- use withings_get_body/sleep/activity instead'). It also explains the auto-sync behaviour when the cache is stale, providing useful context for invocation.

  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.8/5.0
  Behavior4/5

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

  Despite no annotations, the description discloses key behaviors: always fetched live (not cached), requires specific devices, returns ECG list with timestamps and AFib classification, and explicitly excludes raw waveforms. Minor omission: no mention of pagination or rate limits, but given simplicity of tool, transparency is high.

  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?

  Concise yet comprehensive: first sentence states purpose, then caching behavior, device requirements, parameter details in a clear list, return summary, and alternative tool. No wasted words.

  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 only 2 optional parameters and an output schema, the description covers all essential aspects: input semantics, output contents, behavioral constraints, and sibling differentiation. No gaps.

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

  Parameters5/5

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

  Schema coverage is 0%, but description fully compensates: specifies date formats ('YYYY-MM-DD' or '30d' for start, 'YYYY-MM-DD' for end), defaults (last 30 days, today), and purpose (define date range for ECG recordings). Adds meaning beyond schema's basic string type.

  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?

  Clearly states the tool fetches 'ECG recordings and atrial fibrillation detection results', distinguishing it from sibling tools like withings_get_body (resting heart rate trends) and withings_get_sleep. The verb 'Get' and specific resource are explicit.

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

  Usage Guidelines5/5

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

  Provides explicit guidance: requires a Withings device with ECG capability (ScanWatch, BPM Core), and advises to use withings_get_body or withings_get_sleep instead for resting heart rate trends. No ambiguity about when to use this vs. alternatives.

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

• withings_syncA
  4.8/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses incremental sync behavior, first sync history fetching, storage in SQLite, and return summary. Missing minor details like API rate limits or authentication, but still comprehensive.

  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 well-structured with a clear heading, paragraphs, bullet points, and explicit sections for args and returns. It is concise yet complete, with no wasted words.

  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 no annotations and an output schema, the description covers purpose, usage guidelines, parameter semantics, behavioral details, and returns. It fully equips the AI agent to select and invoke the tool correctly, even in the context of sibling tools.

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

  Parameters5/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 add full meaning. It explains data_types options with examples and default, and clarifies that 'days' applies only to the first sync. This adds significant value beyond the raw 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 clearly states the tool's purpose: 'Sync Withings health data to the local cache.' It uses a specific verb-resource pair and explicitly distinguishes from sibling query tools like withings_get_body and withings_get_sleep.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance: 'Run this before using other withings_get_* tools' and 'Not for querying data - use withings_get_body, withings_get_sleep, withings_get_activity, or withings_get_workouts instead.' It clearly tells the AI agent when and when not to use the tool.

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

• withings_get_bodyA
  5/5.0
  Behavior5/5

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

  No annotations provided, but the description fully discloses behavior: cache default, live override, sync requirement, sorted results, one entry per group, and metric validation by refusing invalid names.

  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?

  Well-organized with a clear purpose statement, parameter list, and return info. The metric list is necessary for usability, and every sentence adds value without redundancy.

  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?

  Covers return format, exclusions, prerequisites, and alternatives, making it self-sufficient for an agent to decide and call the tool correctly.

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

  Parameters5/5

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

  Despite 0% schema description coverage, the text provides thorough parameter details: date formats, defaults, exact metric options, and the live flag's effect, fully compensating for 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?

  Clearly states it gets body composition measurements and explicitly distinguishes from sleep and activity tools by pointing to withings_get_sleep and 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 Guidelines5/5

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

  Explicitly states when to use this tool (body composition) and when not to (sleep/activity), plus provides guidance on cache vs. live fetching and the need to run withings_sync first.

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

• withings_get_sleepA
  5/5.0
  Behavior5/5

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

  Despite no annotations, the description fully discloses behavioral traits: summary uses local cache unless live=True, detail always fetched live, live is ignored when detail=True, default date ranges differ by mode. 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.

  Conciseness5/5

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

  Description is well-structured with clear sections for summary/detail, bullet points for parameters, and a separate line for return value. Every sentence adds value without redundancy.

  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 has an output schema, the description does not need to detail return values. It covers all necessary context: modes, parameter behaviors, caveats (max 7 days), and sibling differentiation, making it complete.

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

  Parameters5/5

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

  With 0% schema coverage, the description provides extensive parameter details: start_date format options ('YYYY-MM-DD', 'YYYY-MM', '7d'), default behavior for both modes, end_date default, and flags effect. Fully compensates for schema gap.

  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 it gets sleep data in two modes (summary or detail), lists what each mode returns, and explicitly distinguishes from sibling tool withings_get_body for body composition. The verb 'Get' and resource 'sleep' are specific.

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

  Usage Guidelines5/5

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

  The description explains when to use summary vs detail, when to use live flag, and explicitly tells when not to use (for body composition, use withings_get_body). It also notes the maximum 7-day limit for detail mode.

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