Skip to main content
Glama
Sign In
withings-mcp

withings-mcp

by partymola
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

withings_sync

Syncs Withings health data to a local SQLite cache for offline queries, updating only records newer than the last sync so other health-data tools can retrieve current metrics.

Instructions

Sync Withings health data to the local cache.

Fetches data from the Withings API and stores it in SQLite for fast offline queries. Run this before using other withings_get_* tools.

Syncs incrementally: only fetches data newer than the last sync. First sync fetches the specified number of days of history.

Args: data_types: What to sync. Options: "all", "body", "sleep", "activity", "workouts". Comma-separated for multiple, e.g. "body,sleep". Default: "all". days: Days of history for first sync (default: 30). Ignored on subsequent syncs (uses last sync timestamp).

Returns summary of records synced per data type. Not for querying data - use withings_get_body, withings_get_sleep, withings_get_activity, or withings_get_workouts instead.

Input Schema

NameRequiredDescriptionDefault
daysNo
data_typesNoall

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.11.0
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "withings_syncOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses incremental sync semantics (only data newer than last sync), that 'days' is ignored after the first sync, that data lands in a SQLite cache, and that it returns a per-type summary. It does not mention authentication requirements or what happens to existing cached rows on re-sync, which keeps it from a 5.

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?

Front-loaded with purpose, then sync behavior, then args, then exclusions — a logical order. Minor waste in restating the schema defaults ('default: 30', 'default: "all"'), but the surrounding explanation of those params earns the space.

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 two-param sync tool with no output schema and no annotations, it covers purpose, sequencing, incremental behavior, param semantics, and return shape. The one meaningful omission is any mention of credential/auth prerequisites for the Withings API before a sync can succeed.

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 compensate entirely, and it does: data_types enumerates the five valid values plus comma-separated multi-value syntax with a default, and days is explained as first-sync-only history depth with the subsequent-sync override called out.

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?

States a specific verb and resource ('Sync Withings health data to the local cache') plus the mechanism (Withings API into SQLite). It is unmistakably distinct from every withings_get_* sibling, which only read cached data.

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 ordering guidance ('Run this before using other withings_get_* tools') and an explicit exclusion naming four alternative tools ('Not for querying data - use withings_get_body, withings_get_sleep...'). Both when-to-use and when-not-to-use are stated with alternatives.

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

Deploy Server

Other Tools