Mi Fitness Data Bridge

Overview Schema Source Related Servers Discussions Admin

query_workouts

Read-onlyIdempotent

Retrieve cached Mi Fitness workout session summaries within an inclusive date range, filtered by activity type, duration, or distance, with pagination for heart-rate and pace data.

Instructions

List recorded workouts starting within an inclusive YYYY-MM-DD range. Returns data.workouts, count and data_quality; rows include workout_id, activity_type, start_at/end_at, duration_minutes, distance_m, calories_kcal and available heart-rate/pace fields (missing fields may be null). activity_types matches case-insensitively; min_duration is minutes and min_distance_km is kilometers (unlike output distance_m). Filters combine with AND before pagination. Use a returned workout_id with query_workout_series for a heart-rate curve; this tool returns session summaries, not samples. Read-only local SQLite query; no cloud request or automatic sync. Requires a configured local account/cache. Returns JSON text with status, source=cache, generated_at and data; empty lists mean no cached matches, not zero measurements. Use get_data_coverage to inspect availability or sync_data to refresh with user consent. Returns data.pagination {limit, offset, has_more, next_offset}; next_offset is null at the end. Keep filters unchanged and avoid syncing between pages.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum records per page (1-5000); count describes this page only.
`offset`	No	Zero-based position; pass pagination.next_offset unchanged with the same filters.
`end_date`	Yes	Inclusive last calendar date, YYYY-MM-DD; must be on or after start_date.
`start_date`	Yes	Inclusive first calendar date, YYYY-MM-DD; must be on or before end_date. Uses stored calendar dates, not caller timezone conversion.
`min_duration`	No	Minimum workout duration in minutes, inclusive; 0 or omitted disables this filter.
`activity_types`	No	Optional activity labels from stored workouts (e.g. running); case-insensitive. Omit or [] for all; labels depend on device/upstream data.
`min_distance_km`	No	Minimum workout distance in kilometers, inclusive; 0 or omitted disables this filter. Returned distance uses meters.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.4Sep 30, 2026

addedInput schema / properties / limit

Added value: +{
+  "default": 5000,
+  "description": "Maximum records per page (1-5000); count describes this page only.",
+  "maximum": 5000,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Zero-based position; pass pagination.next_offset unchanged with the same filters.",
+  "minimum": 0,
+  "type": "integer"
+}

Changed14 schema fields changedv0.3.2Sep 21, 2026

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

addedInput schema / properties / activity_types / description

Added value: +"Optional activity labels from stored workouts (e.g. running); case-insensitive. Omit or [] for all; labels depend on device/upstream data."

addedInput schema / properties / end_date / description

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

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 / min_distance_km / description

Added value: +"Minimum workout distance in kilometers, inclusive; 0 or omitted disables this filter. Returned distance uses meters."

addedInput schema / properties / min_distance_km / minimum
```
Added value: +0
```

addedInput schema / properties / min_duration / description

Added value: +"Minimum workout duration in minutes, inclusive; 0 or omitted disables this filter."

addedInput schema / properties / min_duration / minimum
```
Added value: +0
```

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."

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

A4.8/5.0

Behavior5/5

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

Goes well beyond the read-only/idempotent annotations: returns JSON with status, source=cache, generated_at, and pagination metadata; explains that empty lists mean no cached matches (not zero measurements); notes it requires a configured local account/cache and performs no cloud request or sync. This is exactly the extra behavioral context the annotations cannot convey.

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 the core purpose and generally dense with useful facts, but it is a long run-on block and repeats pagination/return guidance, so a little trimming would help. Nearly every sentence earns its place.

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 present, the description fully carries the return-shape burden (data.workouts, count, data_quality, pagination fields) and the caching/account prerequisites. Nothing essential for calling it correctly is missing.

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 100%, so the baseline is 3, but the description adds cross-parameter semantics: 'min_duration is minutes and min_distance_km is kilometers (unlike output distance_m)' and 'filters combine with AND before pagination'. These clarify unit mismatches and filter combination logic beyond the per-field schema text.

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 and resource ('List recorded workouts') plus its range scoping, and explicitly distinguishes itself from the sibling query_workout_series ('this tool returns session summaries, not samples'). An agent can tell exactly what this returns without opening the 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?

Names alternatives and the conditions selecting them: query_workout_series for heart-rate curves via a returned workout_id, get_data_coverage to inspect availability, sync_data to refresh with consent. It also gives operational guidance ('keep filters unchanged and avoid syncing between pages'), which is explicit when/how-to-use advice.

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

Deploy Server

query_workouts

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools