Withings MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.11
Disambiguation4/5
Most tools have clearly distinct purposes, but there is potential confusion between withings_list_sleep and withings_list_sleep_summary, as well as between withings_daily_summary and withings_weekly_summary. However, the descriptions provide enough detail to differentiate them.
Naming Consistency5/5
All tools follow a consistent withings_verb_noun pattern, using snake_case. The naming is predictable and clear, making it easy to infer functionality from the name alone.
Tool Count4/5
With 23 tools, the server covers a broad range of functionality including authentication, data retrieval, summaries, profile management, and setup. While slightly on the higher end, each tool serves a distinct purpose and the count is justified by the scope of the Withings API.
Completeness4/5
The server covers major Withings data domains (activity, sleep, body measures, heart) and includes essential auth and setup tools. Missing write operations (e.g., creating workouts) are expected for a read-only health API. Some niche data types like blood pressure or device management are absent, but the core use cases are well supported.
Average 3.8/5 across 23 of 23 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on July 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds the scope requirement, which is useful but not a behavioral trait. No contradiction exists.
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 (two sentences) and front-loaded with the purpose. 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having eight parameters and an output schema, the description omits key context like pagination, filtering, privacy modes, and output format. It is too minimal for a tool of this complexity.
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 description coverage is 88%, so the baseline is 3. The description adds no parameter-specific detail, meaning it provides no extra value over 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 clearly states the action ('List') and resource ('Withings workouts'), which is a specific verb-resource pair. However, it does not differentiate from sibling tools like withings_list_activity or withings_list_body_measures, which could cause confusion.
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?
The only usage guidance is the required scope ('user.activity'), but there is no direction on when to use this vs. alternatives, nor any exclusions. With 21 siblings, this is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds only the auth scope requirement ('Requires user.activity scope'), which is useful but minimal. No discussion of pagination, rate limits, or response details beyond what annotations cover.
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?
Two sentences, front-loaded with purpose. No unnecessary words. Every part serves a clear function.
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?
Description is very short given the complexity of the tool (8 parameters, output schema exists). It does not clarify what 'daily activity' includes (e.g., steps, calories) or explain pagination behavior, though the schema and output schema might partially compensate. Could be more complete.
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 description coverage is 88%, so baseline is 3. Description does not add any additional meaning beyond what the schema already provides for parameters. It does not mention parameters or clarify their usage.
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?
Description uses specific verb 'List' and resource 'Withings daily activity summaries', clearly distinguishing from sibling tools like withings_list_workouts or withings_list_sleep_summary. It directly states the function and scope.
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?
No guidance on when to use this tool versus alternatives (e.g., other list tools). Only requirement 'user.activity scope' is mentioned, but no context on appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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: '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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines4/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 (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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds that the tool requires a scope and is not medical advice, but does not disclose additional behavioral traits such as pagination limits, privacy mode defaults, or how dates are handled. With annotations providing baseline safety, a score of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, covers the essential purpose and requirement, and contains no redundant or irrelevant information. It is front-loaded with the key action.
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?
Despite the schema covering many parameters and an output schema existing, the description fails to mention pagination behavior, privacy mode options, or what 'common sleep fields' actually includes. The tool has eight parameters and complex behavior, but the description is too minimal to fully guide an agent on correct invocation and interpretation of results.
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 description coverage is 88%, meaning almost all parameters have detailed descriptions in the schema. The tool description does not add any further semantic information about parameters beyond the schema. Baseline is 3 when coverage is high, and no extra value is provided.
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 verb 'List', the resource 'Withings sleep summaries', and specifies 'with common sleep fields', which distinguishes it from sibling tools like withings_list_sleep that may offer different data. 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the required scope ('user.activity') and provides a disclaimer ('Not medical advice'), giving some context for appropriate use. However, it does not explicitly state when to use this tool versus alternatives (e.g., withings_list_sleep for a different sleep summary), nor does it mention limitations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
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 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. Description adds the scope requirement and a medical disclaimer, providing useful context without contradicting 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?
Two concise sentences with no wasted words. Essential information 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?
With 8 parameters and an output schema, the description is minimal. It doesn't explain what 'punctual measurements' entail or how the data is structured, leaving some ambiguity. Additional context about the return type or common use cases would improve completeness.
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 88%, so the schema already explains most parameters. The description does not add additional semantic detail for parameters beyond what's in 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?
Clear verb 'List' and specific resource 'body measures' with examples 'weight and body composition'. Distinguishes from sibling tools like withings_list_activity and withings_list_workouts by specifying 'punctual measurements'.
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?
Provides the required scope 'user.metrics' and a disclaimer 'Not medical advice', but does not explain when to choose this tool over others or when not to use it. No explicit alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only, idempotent, and non-destructive hints. The description adds value by disclosing the scope requirement and that output is not medical advice, which are useful behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no redundancy: purpose, scope requirement, disclaimer. Each sentence earns its place.
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?
Given the presence of an output schema and rich annotations, the description is adequate for basic understanding. However, it could mention the sibling summary tool for comparison, and the parameter count (8) suggests the description might underspecify when detailed data is available.
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 88%, so parameters are already well-described. The overall description adds no extra parameter-specific meaning beyond stating 'detailed sleep data', which is implied by the schema and tool name.
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 verb 'List' and specific resource 'detailed Withings sleep data'. It distinguishes from the sibling 'withings_list_sleep_summary' by implying detail, and adds scope requirement and disclaimer.
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 includes a required scope ('user.activity scope') but does not explicitly guide when to use this tool versus alternatives such as the summary sibling. Usage context is partly clear but lacks explicit exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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: 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.
Usage Guidelines4/5
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.
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. The description adds negligible behavioral context beyond 'where available' and the scope requirement. 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?
The description is three concise sentences, each serving a clear purpose: purpose, requirement, disclaimer. No filler or redundancy. Front-loaded with the main action.
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 high schema coverage, existing annotations, and presence of an output schema, the description adequately covers the essentials. It is slightly brief but sufficient for an informed agent. Could mention idempotency but annotations handle that.
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 description coverage is 88%, meaning most parameters are already explained in the schema. The tool description adds no additional parameter-level value beyond what the schema provides, so baseline of 3 is appropriate.
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 specifies the action ('List') and the resource ('Withings heart records'). It distinguishes itself from sibling tools like 'list_body_measures' and 'list_activity' by focusing on heart records. The phrase 'where available' adds nuance about data availability.
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 explicit usage guidance by stating the required scope ('Requires user.metrics scope') and a disclaimer ('Not medical advice'). However, it does not explicitly contrast with sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters2/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, 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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![withings-mcp MCP server](https://glama.ai/mcp/servers/davidmosiah/withings-mcp/badges/card.svg)](https://glama.ai/mcp/servers/davidmosiah/withings-mcp)

Score Badge

Copy to your README.md:

[![withings-mcp MCP server](https://glama.ai/mcp/servers/davidmosiah/withings-mcp/badges/score.svg)](https://glama.ai/mcp/servers/davidmosiah/withings-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidmosiah/withings-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server