fitbit-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fitbit_statusB | Local connection metadata and implemented types. Declared support is not proof of data availability on this device. Does not return credentials. |
| fitbit_devicesB | Read paired device metadata. |
| fitbit_request_idA | Generate a UUID for one new meal/water draft. Reuse the same ID on retries; use a new ID for a new occurrence. |
| fitbit_readA | Read 1–14 civil calendar days, endDate exclusive. Sleep is grouped by wake date. Raw samples may overlap: do not sum them as daily totals. At most 500 points per call; if incomplete, pass nextPageToken as pageToken with the same type/dates to continue. |
| fitbit_activityA | Daily server-reconciled wearable activity for 1–14 civil days (end exclusive). Returns raw rollup fields; missing values are not zero. A failed domain is explicit. |
| fitbit_summaryA | Normalized daily health metrics and period statistics for 1–14 civil days, end exclusive. Reconciles wearable sources; sleep is grouped by wake date. Missing, conflicting, partial and failed metrics remain explicit. Totals are null unless all requested days are observed. |
| fitbit_compareA | Compare equal calendar windows using code-calculated paired-day means and coverage. Defaults to the preceding window of the same length. No medical or recovery score is invented. |
| fitbit_preview_mealA | Create a local meal draft ONLY. Values apply to the whole dish portion, not per 100g. Review assumptions, portions, date/offset and all K/P/F/C values before saving. Photo estimates are approximate. |
| fitbit_preview_waterA | Create a local water draft ONLY. Review volume and date/time with offset before saving. |
| fitbit_operationB | Inspect the persisted state of a meal/water operation. Never silently resubmit uncertain writes. |
| fitbit_commitA | Save an existing reviewed preview after explicit user intent. Reusing its operation ID never blindly replays an uncertain item. Return per-item states; only verified means read-back succeeded. |
| fitbit_cancel_draftA | Cancel an untouched local preview; does not delete Google records. |
| fitbit_removeA | Remove only the known Google records created by this operation, after explicit user intent. Blocks uncertain records; verifies deletion. To correct manual-food macros, remove old records then review and save a new preview; this is not atomic. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools have distinct roles: preview_meal vs preview_water differ by resource, and commit/cancel/remove/operation form a clear write lifecycle. However, the read trio (fitbit_read, fitbit_activity, fitbit_summary) all return day-based health data and require careful reading of descriptions to distinguish raw vs rollup vs normalized.
All tools share a consistent fitbit_ snake_case prefix, which is highly predictable. Minor deviation: most names are verb-led (read, compare, preview_meal) while a few are noun-led (status, devices, operation), but the pattern remains readable and coherent.
13 tools sits squarely in the well-scoped 3-15 range. Each tool earns its place, covering read, compare, and a full meal/water draft lifecycle without obvious redundancy.
The surface covers reads (raw/activity/summary), comparison, device/status metadata, and a full draft-commit-cancel-remove write lifecycle with operation inspection. The main gap is no in-place update for corrections, handled non-atomically via remove+new preview, which is a minor workaround.