withings-mcp

by partymola

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation5/5
Each tool targets a distinct domain (activity, body, devices, heart, sleep, workouts, sync, trends) with clear descriptions and explicit 'Not for' disclaimers, eliminating ambiguity.
Naming Consistency5/5
All tools follow the 'withings_' prefix with a consistent pattern: 'get_' for data retrieval, plus 'sync' and 'trends' as distinct actions, making navigation predictable.
Tool Count5/5
With 8 tools covering synchronization, data retrieval across key health categories, and trend analysis, the set is well-scoped and not excessive.
Completeness5/5
The tool surface covers all major Withings data types (activity, body, sleep, heart, workouts, devices) plus sync and analysis, with no obvious gaps for a read-only health data API.
Average 4.8/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 42 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under GPL 3.0.
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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

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.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It explains cache-by-default behavior, the live fetch option, sorting by date, and prerequisites (sync). However, it does not explicitly state that the tool is read-only or mention rate limits or authentication, leaving minor 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?
The description is well-structured with a brief summary line followed by detailed 'Args:' section. Every sentence adds value, and it is front-loaded with key information. No redundancy or unnecessary text.
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 absence of annotations and low schema coverage, the description covers input parameters, return fields, behavior, and prerequisites. It also distinguishes from siblings. However, it lacks details on error handling, pagination, or exact data freshness, and does not reference the output schema that exists. Still, it is largely 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?
The schema has 0% description coverage, so the description must fully explain parameters. It does so for all four: provides format and default for start_date (e.g., '90d', 'YYYY-MM-DD'), end_date (default today), category (case-insensitive partial match with examples), and live (boolean flag). This adds significant meaning beyond the schema's bare titles.
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 retrieves workout sessions with specific data (type, duration, HR, calories). It distinguishes from the sibling tool withings_get_activity by specifying it is not for daily step/activity totals, providing a clear and unique purpose.
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 instructs users to run withings_sync first to populate the cache, explains default cache behavior versus live API usage via the 'live' parameter, and provides default date ranges. It also gives an explicit alternative (withings_get_activity) for daily totals, offering complete 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses auto-sync behavior on stale cache and explains that the 'compare' parameter overrides others. While it doesn't explicitly state read-only or non-destructive nature, it implies no side effects beyond cache refresh. A minor gap but still informative.
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 clear sections (summary, args, returns, exclusion). While a bit lengthy, it is front-loaded and every sentence adds value. Could be slightly more concise but remains efficient.
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 5 parameters, no annotations, no schema descriptions, and an output schema (which explains returns), the description provides complete context: explains return values per data type, cache sync behavior, and parameter interactions. 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%, so the description must explain all parameters. It covers all 5 parameters with options, formats, defaults, and interactions (e.g., compare overrides others). Examples are provided, making it very clear.
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 analyzes trends in cached health data, specifying it computes averages, min/max, and changes over time. It distinguishes itself from sibling tools by stating 'Not for raw data -- use withings_get_body/sleep/activity instead,' fulfilling the specific verb+resource+scope requirement.
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 explicitly says when to use (trend analysis on cached data) and when not to use (raw data), naming alternatives. It also notes auto-syncs if cache is stale, providing clear context and 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?
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.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: returns from cache unless live=True, requires prior withings_sync, return sort order and grouping. 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?
Well-structured with separate sections for args and notes. First sentence gives purpose. Concise yet comprehensive, 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?
Complete for a 4-parameter tool with output schema. Covers all parameter details, return format, and caching behavior. 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?
All 4 parameters are explained with formats, defaults, and allowed values. Metrics parameter lists all options. Schema coverage was 0%, so description compensates fully.
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 (weight, fat, muscle, etc.). Distinguishes from siblings by explicitly saying 'Not for sleep or activity data -- use withings_get_sleep or withings_get_activity instead.'
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?
Explicit when to use (body composition), when not (sleep/activity), and alternatives. Also explains caching behavior and prerequisite: 'Run withings_sync first to populate the cache.'
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?
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.

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/partymola/withings-mcp/badges/card.svg)](https://glama.ai/mcp/servers/partymola/withings-mcp)

Score Badge

Copy to your README.md:

[![withings-mcp MCP server](https://glama.ai/mcp/servers/partymola/withings-mcp/badges/score.svg)](https://glama.ai/mcp/servers/partymola/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/partymola/withings-mcp'

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