Withings MCP

Withings Daily Activity

withings_list_activity

Read-onlyIdempotent

Retrieve daily activity summaries from Withings for a date range, with pagination and privacy controls.

Instructions

List Withings daily activity summaries. Requires user.activity scope.

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_list_activity"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No	Withings page number.
`after`	No	Inclusive start bound. Converted to Withings startdate (epoch) or startdateymd (YYYY-MM-DD) per action.
`limit`	No	Upstream page-size hint and local output cap used for pagination safety.
`before`	No	Inclusive end bound. Converted to Withings enddate (epoch) or enddateymd (YYYY-MM-DD) per action.
`all_pages`	No	Fetch multiple pages up to max_pages.
`max_pages`	No	Maximum pages to fetch when all_pages is true.
`privacy_mode`	No	Optional per-call privacy override. Defaults to WITHINGS_PRIVACY_MODE or structured. raw returns upstream Withings JSON. summary minimizes sensitive health and profile details.
`response_format`	No		markdown

Output Schema

Name	Required	Description	Default
`count`	Yes
`empty`	No
`records`	Yes
`warning`	No
`endpoint`	Yes
`has_more`	Yes
`next_page`	No
`privacy_mode`	Yes
`pages_fetched`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.5.4Sep 4, 2026
- addedOutput schema / properties / empty
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / warning
```
Added value: +{
+  "type": "string"
+}
```

Changed6 schema fields changedv0.4.11Jul 30, 2026

changedInput schema / properties / after / description

Previous value: -"Only return Withings records after this time. Converted to Withings startdate."New value: +"Inclusive start bound. Converted to Withings startdate (epoch) or startdateymd (YYYY-MM-DD) per action."

removedInput schema / properties / after / format
```
Removed value: -"date-time"
```

changedInput schema / properties / after / pattern

Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"New value: +"^\\d{4}-\\d{2}-\\d{2}([Tt ]\\d{2}:\\d{2}(:\\d{2})?(\\.\\d+)?([Zz]|[+-]\\d{2}:?\\d{2})?)?$"

changedInput schema / properties / before / description

Previous value: -"Only return Withings records before this time. Converted to Withings enddate."New value: +"Inclusive end bound. Converted to Withings enddate (epoch) or enddateymd (YYYY-MM-DD) per action."

removedInput schema / properties / before / format
```
Removed value: -"date-time"
```

changedInput schema / properties / before / pattern

Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"New value: +"^\\d{4}-\\d{2}-\\d{2}([Tt ]\\d{2}:\\d{2}(:\\d{2})?(\\.\\d+)?([Zz]|[+-]\\d{2}:?\\d{2})?)?$"

Changed3 schema fields changedv0.4.7Jul 6, 2026

changedInput schema / properties / after / description

Previous value: -"Only return Withings records after this time. Converted to an Withings start_date."New value: +"Only return Withings records after this time. Converted to Withings startdate."

changedInput schema / properties / before / description

Previous value: -"Only return Withings records before this time. Converted to an Withings end_date."New value: +"Only return Withings records before this time. Converted to Withings enddate."

changedInput schema / properties / limit / description

Previous value: -"Local page-size hint used for pagination safety."New value: +"Upstream page-size hint and local output cap used for pagination safety."

First observedv0.4.6Jun 26, 2026

TDQS

B3.1/5.0

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, covering the safety profile. The description adds the permission requirement (user.activity scope), which is useful but minimal. It does not disclose pagination behavior, data freshness, or any edge cases, so it adds some value beyond annotations but not rich 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 extremely concise—two sentences with no fluff. The purpose is front-loaded and the scope requirement is valuable. However, given the tool's complexity, a bit more context could be warranted, but the brevity is not a flaw in itself.

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?

For a tool with 8 parameters and many sibling list tools, this description is inadequate. It doesn't explain what 'daily activity summaries' entail, how pagination works, or how it differs from other list tools. The output schema covers return values, but the tool's role and selection criteria are missing, leaving a significant gap.

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 documents most parameters in detail. The description adds nothing about parameters, such as how 'after' and 'before' work or what 'privacy_mode' does. With high coverage, the baseline of 3 is appropriate; the description neither helps nor hurts.

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 states the verb 'List' and the resource 'Withings daily activity summaries', which is clear and specific. It distinguishes from siblings like list_workouts and list_sleep by naming 'activity', though it doesn't explicitly contrast with them. 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 Guidelines2/5

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

The description provides a prerequisite (user.activity scope) but gives no guidance on when to choose this tool over alternatives like list_workouts or list_body_measures. There is no explicit context for typical use cases or exclusions, leaving the agent to infer when this tool is appropriate.

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