Skip to main content
Glama

garmin_sync_weight

Copies recent Xiaomi scale weigh-ins into Garmin Connect with real body composition values, skipping duplicates and implausible weights. Use dry run first to preview entries.

Instructions

Copy recent weigh-ins from the Xiaomi scale into Garmin Connect.

Use this instead of garmin_add_body_composition when the measurement came from the Mi Fitness / Xiaomi body-fat scale — it reads the real values (weight, body fat, water, muscle, bone, BMI) rather than asking the user to type them.

Every weighing becomes its own entry, with the time it was taken: morning fasted and evening before bed are two measurements, ten weighings make ten entries. Only the scale's double upload — a weight-only row followed by the full row seconds later — is folded into one, keeping the richer row.

A weighing Garmin already holds (same moment within three minutes) is skipped, so re-running writes nothing. Matching is by moment rather than by day, which is what lets a second weighing on the same day through while still recognising the first.

Weights that look wrong are refused, because Garmin keeps every entry and there is no undo: with ≥3 Garmin weigh-ins in the window, anything more than ±40% off their median is skipped (a 斤 mis-read is exactly 2× kg); without Garmin history, weights outside 30–250 kg are skipped. Skips are listed with the reason — override one manually with garmin_add_body_composition if it was genuine.

Deleting a weigh-in in the Mi Fitness app does NOT remove it from Garmin: this tool has no delete path. Remove stray entries in the Garmin Connect app itself.

THIS WRITES TO YOUR GARMIN ACCOUNT unless dry_run is true. There is no undo through this tool. Call with dry_run=true first when the user has not seen the numbers yet, then report what would be written.

Requires a one-time interactive login (garmin-mcp-lite-xiaomi-login), because Xiaomi's login needs a captcha and an SMS code. When the token is missing or expired the result carries an error explaining that, and no write happens.

Args: days: How far back to look, in days. Defaults to 7, capped at 90. dry_run: Report what would be written without writing anything.

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

Input Schema

NameRequiredDescriptionDefault
daysNo
dry_runNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.10

TDQS

A4.6/5.0
Behavior4/5

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

No annotations exist, so the description carries the full behavioral burden and does so well: it discloses the one-entry-per-weighing model, how the scale's double upload is folded, the three-minute dedup window that makes re-runs idempotent, and the ±40% / 30–250 kg rejection rules with reasons reported per skip. It also states the hard limits that matter most for a mutation — no undo, no delete path, and that deletions in Mi Fitness do not propagate to Garmin. It stops short of describing the response payload shape beyond mentioning `error` and skip listings, which keeps it at 4 rather than 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 alternatives, then write/dedup behavior, then the critical write warning — a sensible ordering. It is long, but nearly every sentence carries distinct operational meaning (dedup window, validation thresholds, login failure mode); the dry-run advice is stated twice, once mid-text and once in the Args block, which is the only real 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?

For a destructive, unannotated, two-parameter write tool with no output schema, the description covers everything an agent needs: side effects, idempotency, partial-failure behavior (skips with reasons), auth prerequisites and their failure mode, and the exact remediation path for mistakes. Nothing material is left for the agent to infer.

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 coverage is 0% (bare `integer`/`boolean` with defaults only, no descriptions), so the prose must compensate — and it explains `days` with a default of 7 and an undocumented cap of 90 that appears nowhere in the schema, plus `dry_run`'s report-only behavior. Both parameters are covered with meaning beyond the schema, though `dry_run`'s phrasing is close to its own name.

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 ('Copy recent weigh-ins from the Xiaomi scale into Garmin Connect') and immediately names the sibling it replaces, `garmin_add_body_composition`, with the reason (real measured values vs. typed values). An agent can distinguish the two without opening either schema.

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 states when to prefer this over the alternative tool, and adds a recommended call sequence ('Call with dry_run=true first when the user has not seen the numbers yet'). It also names the prerequisite login flow and says no write happens when the token is missing, covering the when-not case.

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