Skip to main content
Glama
shkyyy18

Mi Fitness Data Bridge

by shkyyy18
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_dateNoInclusive last calendar date, YYYY-MM-DD; must be on or after start_date. Omitted: server local today.
backgroundNoFalse waits for results; true starts a process-local task and returns sync_id for get_sync_status polling.
data_typesNoDataset names; omitted selects all adapter-supported datasets; [] is invalid.
start_dateNoInclusive 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_syncNoIgnore 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.

  1. Changed15 schema fields changedv0.3.2
    • 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}$"
  2. First observedv0.3.0

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

Other Tools