Mi Fitness Data Bridge

Overview Schema Source Related Servers Discussions Admin

sync_data

Downloads chosen Mi Fitness datasets from Xiaomi into local SQLite, with incremental watermark sync or forced full sync, and returns per-type results.

Instructions

Download selected Mi Fitness datasets from Xiaomi into local SQLite; writes records and sync watermarks, may authenticate/rotate local credentials, and does not modify cloud health records. Requires local CLI setup and user authorization to access the account. Omitted data_types selects all adapter-supported types; an empty list is invalid. Dates are inclusive YYYY-MM-DD; start_date must not exceed end_date. Omitted end_date uses today; omitted start_date resumes the watermark or uses configured lookback (default 30 days). force_full_sync ignores the watermark, not the requested date range, and does not erase the database. Only one sync runs at a time. background=false waits for status ok/partial/error, sync_id, record counts and per-type results; background=true returns accepted plus sync_id to poll with get_sync_status. Partial results may already be stored; inspect results before retrying. Use cached query tools instead when no refresh is needed.

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

Input Schema

Name	Required	Description
`end_date`	No	Inclusive last calendar date, YYYY-MM-DD; must be on or after start_date. Omitted: server local today.
`background`	No	False waits for results; true starts a process-local task and returns sync_id for get_sync_status polling.
`data_types`	No	Dataset names; omitted selects all adapter-supported datasets; [] is invalid.
`start_date`	No	Inclusive first calendar date, YYYY-MM-DD; must be on or before end_date. Uses stored calendar dates, not caller timezone conversion. Omitted: saved watermark, or configured lookback (default 30 days) if no watermark/force_full_sync=true.
`force_full_sync`	No	Ignore saved sync watermark and re-fetch the requested range; no deletion. If start_date is omitted use configured lookback.

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedv0.3.2Sep 21, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / background / description

Added value: +"False waits for results; true starts a process-local task and returns sync_id for get_sync_status polling."

addedInput schema / properties / data_types / description

Added value: +"Dataset names; omitted selects all adapter-supported datasets; [] is invalid."

addedInput schema / properties / data_types / items / enum

Added value: +[
+  "daily_activity",
+  "heart_rate",
+  "body_measurements",
+  "sleep",
+  "workouts",
+  "spo2",
+  "stress",
+  "abnormal_heart_beat"
+]

addedInput schema / properties / data_types / minItems
```
Added value: +1
```

addedInput schema / properties / end_date / description

Added value: +"Inclusive last calendar date, YYYY-MM-DD; must be on or after start_date. Omitted: server local today."

addedInput schema / properties / end_date / examples
```
Added value: +[
+  "2026-01-15"
+]
```
addedInput schema / properties / end_date / format
```
Added value: +"date"
```
addedInput schema / properties / end_date / pattern
```
Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
```
addedInput schema / properties / force_full_sync / default
```
Added value: +false
```

addedInput schema / properties / force_full_sync / description

Added value: +"Ignore saved sync watermark and re-fetch the requested range; no deletion. If start_date is omitted use configured lookback."

addedInput schema / properties / start_date / description

Added value: +"Inclusive first calendar date, YYYY-MM-DD; must be on or before end_date. Uses stored calendar dates, not caller timezone conversion. Omitted: saved watermark, or configured lookback (default 30 days) if no watermark/force_full_sync=true."

addedInput schema / properties / start_date / examples
```
Added value: +[
+  "2026-01-15"
+]
```
addedInput schema / properties / start_date / format
```
Added value: +"date"
```
addedInput schema / properties / start_date / pattern
```
Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
```

First observedv0.3.0Aug 13, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint false, destructiveHint false), the description discloses detailed behavior: it may authenticate/rotate credentials, requires local CLI setup and user authorization, runs only one sync at a time, handles partial results, and clarifies that force_full_sync does not erase the database. This significantly exceeds the sparse annotation information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence serves a purpose. It front-loads the core purpose and then systematically covers prerequisites, parameter nuances, execution behavior, and alternative tools. No redundant or filler sentences; each adds necessary context.

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?

Given the tool's complexity (5 parameters, no output schema), the description covers all aspects needed for correct invocation: prerequisites, authorization, date handling, sync semantics, background modes, and result interpretation. It also warns about partial results and retry considerations, making it fully complete.

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 coverage is 100% and the description adds substantial meaning: omitted data_types selects all supported types, empty list invalid, date ranges are inclusive, start_date omitted resumes watermark, force_full_sync ignores watermark but not date range, background behavior differences. It enriches the schema definitions with usage semantics.

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?

The description clearly states the tool downloads Mi Fitness datasets into local SQLite, writes records and sync watermarks, and explicitly notes it does not modify cloud health records. It distinguishes itself from sibling query tools by naming them as cached alternatives. The verb 'download' and resource 'datasets' are specific.

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?

The description explicitly states when to use the tool (when a refresh is needed) and when not to (use cached query tools instead). It also mentions polling with get_sync_status for background syncs, providing clear routing to alternatives.

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

Deploy Server