Personal Health Data (community)

Authorize (one time)

start_authorization

Generates the Withings authorization URL to begin one-time setup, letting users grant read-only access to their body, activity, and sleep data.

Instructions

One-time setup step. Returns the Withings authorization URL for the user to open in a browser (read-only scopes: user.info, user.metrics, user.activity). If the callback URL is on localhost, this server listens there for 10 minutes and finishes the setup by itself; otherwise the user runs exchange_code (or the CLI) with the redirect URL within 30 seconds. Writes only the local token file.

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": "start_authorization"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds real context beyond the annotations: the granted scopes are read-only, the local listener has a 10-minute lifetime, the manual path has a 30-second window, and the only write is the local token file. This productively reconciles readOnlyHint=false with an otherwise non-destructive flow. It does not say what the URL or returns look like on failure/timeout, leaving a small gap.

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-loads 'One-time setup step' and the return value, then branches cleanly into the localhost and non-localhost paths. Dense but nearly every clause carries information; the parenthetical CLI mention is the only mild noise.

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?

With no output schema, the description correctly states what is returned (the authorization URL), what side effect occurs (local token file), and how the flow completes in each deployment scenario. An agent has everything needed to call it and hand off correctly.

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?

There are zero parameters, so the baseline is 4. The description adds relevant meaning by naming the exact scopes (user.info, user.metrics, user.activity) the resulting token will carry, which the empty schema cannot convey.

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 (one-time setup) and resource (Withings authorization URL), and explicitly names the scopes granted. It is clearly distinguishable from siblings exchange_code (the follow-up step) and auth_status (the check), which it references by name.

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 routing: if the callback is on localhost the server self-completes in 10 minutes; otherwise the user must run exchange_code (or the CLI) with the redirect URL within 30 seconds. Both the alternative tool and the condition that selects it are spelled out.

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

Deploy Server