Skip to main content
Glama
Sign In
withings-mcp

withings-mcp

by partymola
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

withings_trends

Analyze cached health data trends by computing averages, min/max, and changes over time for body, sleep, or activity, with automatic sync when the cache is stale.

Instructions

Analyse trends in cached health data.

Computes averages, min/max, and changes over time from the local cache. Auto-syncs if the cache is stale (no sync today).

Args: data_type: What to analyse. Options: "body", "sleep", "activity". period: Aggregation period. Options: "weekly", "monthly", "quarterly". Default: "monthly". start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "365d" for relative days. Default: 365 days back from the end date or today, whichever is earlier. end_date: End date as "YYYY-MM-DD", "YYYY-MM" (its last day), or "Nd". Default: today. compare: Compare two periods. Format: "last_30d vs previous_30d", "2026-03 vs 2026-02", "2026-Q1 vs 2025-Q4". When set, period/start_date/end_date are ignored.

Returns aggregated averages with change indicators. For body data: weight, fat%, muscle trends. For sleep: duration, score, HR trends. For activity: steps, distance, calorie trends. Not for raw data -- use withings_get_body/sleep/activity instead.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "withings_trends"
  }
}

Input Schema

NameRequiredDescriptionDefault
periodNomonthly
compareNo
end_dateNo
data_typeNobody
start_dateNo

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_trendsOutput",
-  "type": "object"
-}New value: +null
  2. Changed2 schema fields changedv0.8.0
    • addedInput schema / properties / data_type / enum
      Added value: +[
+  "body",
+  "sleep",
+  "activity"
+]
    • addedInput schema / properties / period / enum
      Added value: +[
+  "weekly",
+  "monthly",
+  "quarterly"
+]
  3. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does disclose meaningful behavior: results come from a local cache, and the tool auto-syncs when the cache is stale (no sync today). It also describes the return shape (aggregated averages with change indicators, broken out per data_type). It stops short of stating that the operation is read-only/non-mutating or describing failure behavior when a sync fails or no cached data exists.

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 behavior, then a per-parameter breakdown, then return contents and the sibling exclusion. The Args: docstring formatting is slightly verbose but every line carries information; nothing is redundant.

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?

No output schema exists, and the description fills that gap by enumerating the metrics returned for each data_type (weight/fat%/muscle, duration/score/HR, steps/distance/calories). Combined with cache/auto-sync behavior and full parameter documentation, an agent has everything needed to call this correctly against the seven siblings.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it does so for all five parameters: `data_type` and `period` enumerations, `start_date` accepted formats (YYYY-MM-DD, YYYY-MM, 365d) plus default semantics, `end_date` last-day-of-month and Nd handling, and the `compare` string grammar with three concrete examples plus its precedence over the other date parameters.

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

Purpose5/5

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

Opens with a specific verb and resource ("Analyse trends in cached health data") and immediately narrows to what is computed: averages, min/max, and change over time. It also explicitly separates itself from the raw-data siblings with "Not for raw data -- use withings_get_body/sleep/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?

Gives explicit when-to-use guidance (trend/aggregate analysis) and explicit when-not-to-use guidance pointing at three named sibling tools. It also documents interaction rules between parameters, stating that when `compare` is set, `period`/`start_date`/`end_date` are ignored.

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