What can you do with this server?

zepp-mcp lets MCP clients read your Zepp/Amazfit health and workout data locally over stdio. * Fetch daily steps, distance, calories, and sleep breakdown (light/deep/REM/awake) for date ranges via zepp_daily_summary. * Get per-minute heart rate for a day, with nulls for missing readings, via zepp_hearr_rate. * Get single-night sleep detail: stages, score, and resting HR via zepp_sleep. * List workouts across all sports with sport-specific metrics (SWOLF, strokes, pace, cadence, sets) via zepp_list_workouts. * Retrieve full workout detail: laps, time-series streams, and GPS via zepp_workout_detail. * Inspect what the server knows and where decoding is uncertain via zepp_describe_chema. * Send arbitrary GETs to unmodeled Zepp API endpoints via zepp_raw_request. * Check token expiry and region host via zepp_auth_status. * runs 100% locally via stdio, read-only, with no health data stored on disk.

How do I use zepp-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@zepp-mcp How was my sleep last night and what's my heart rate trend today?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

zepp-mcp

by DhavalBhimani44

Overview Schema Related Servers Score Discussions

Python

Remote

zepp-mcp

Read your Zepp / Amazfit health and workout data from any MCP client.

🖥️ 100% local · stdio transport · no server, no cloud relay, no third party

License: MIT Python 3.11+ MCP PRs Welcome Code of Conduct Runs locally Transport: stdio

Ask your assistant "how has my SWOLF trended this month?" or "did I sleep worse on days I trained hard?" and get answers from your own watch data.

› How have my swims gone this week?

  Date     Distance   SWOLF   Strokes   Avg HR
  Aug 16      567 m      36       323      131
  Aug 15      756 m      38       481      139
  Aug 14      630 m      38       361      138

  SWOLF is trending down across the week — you're covering
  each length with fewer strokes and less time.

Built on the private Zepp mobile API, with every decoder verified against real captured responses.

NOTE

This runs entirely on your own machine

zepp-mcp is a local stdio server. Your MCP client launches it as a child process on your laptop and talks to it over stdin/stdout — the same way it runs any local command.

No hosted service. There is nothing to sign up for and no backend I operate.
No cloud relay. Your health data never passes through any server but Zepp's own.
No open port. stdio only — nothing listens on the network.
Your credentials stay in a local .env, never in a client config file.
The only outbound connection is HTTPS from your machine to Zepp's API, read-only, exactly as the Zepp app does it.

See Architecture for the full picture.

IMPORTANT

Unofficial. This project is not affiliated with, endorsed by, or supported by Zepp Health or Huami. It talks to a private API that can change or break without notice. See Legal and safety.

Features · Setup for Users · Developer Setup
Architecture · Tools · Privacy · How it works
Known gaps · Contributing · Legal and safety

Related MCP server: Mi Fitness MCP

Features

All sports in one call. Swimming, running, cycling, football, walking, hiking and strength work, each with its own metrics — SWOLF and stroke counts for swims, pace and cadence for runs, set counts for the gym.
Sleep with all four stages. Light, deep, REM and awake, not just the two most implementations report.
Per-minute heart rate, with no-reading markers preserved as null rather than dropped.
Lactate threshold HR and pace, tracked over time from the watch's own estimate log — the anchor for every training zone — plus VO2 max, per-run time-in-zone distribution and, once a Zepp Coach plan is active, per-session plan progress.
Running dynamics: ground contact time, vertical oscillation, running power and stride ratio, alongside the elevation and climb fields runs share with hikes and rides.
Lap and stream decoding for individual workouts.
Smart-scale body composition. Weight, height and BMI, plus body fat, water and muscle percentages, bone mass, visceral fat and BMR when synced from a real bio-impedance scale rather than a manual entry.
Honest about uncertainty. Unverified units are flagged, unknown sport codes are named as unknown, and an empty response is never reported as confirmed absence.
Nothing stored. No health data touches disk. Only the API token is cached, so restarts don't trigger a fresh login.
Local by construction. A stdio child process on your machine. No hosted service, no relay, no listening port.

Setup for Users

If you just want to use the server with your MCP client, you don't need to clone the repository. You can run it directly using uvx (the uv tool runner).

Add the server to your claude_desktop_config.json and pass your credentials securely via environment variables:

{
  "mcpServers": {
    "zepp": {
      "command": "uvx",
      "args": ["zepp-mcp"],
      "env": {
        "ZEPP_EMAIL": "your-email@example.com",
        "ZEPP_PASSWORD": "your-password"
      }
    }
  }
}

macOS · ~/Library/Application Support/Claude/claude_desktop_config.json
Windows · %APPDATA%\Claude\claude_desktop_config.json

Restart the app completely afterwards.

Install the server globally for Claude Code. Make sure to pass your credentials securely as environment variables:

export ZEPP_EMAIL="your-email@example.com"
export ZEPP_PASSWORD="your-password"
claude mcp add zepp -s user -- uvx zepp-mcp

-s user makes it available in every project. Verify with claude mcp list.

Create or edit ~/.gemini/config/mcp_config.json (global, applies to all projects):

{
  "mcpServers": {
    "zepp": {
      "command": "uvx",
      "args": ["zepp-mcp"],
      "env": {
        "ZEPP_EMAIL": "your-email@example.com",
        "ZEPP_PASSWORD": "your-password"
      }
    }
  }
}

For a single project only, place the same file at .agents/mcp_config.json in your project root instead.

Restart the Antigravity session afterwards — MCP servers are loaded at startup.

WARNING

Zepp counts failed logins against ashared 10-attempt lockout. This server never retries a failed login, and you shouldn't either. If authentication fails, check your credentials carefully before trying again.

Developer Setup

If you want to contribute, run tests, or modify the code locally. Requires uv and Python 3.11+.

git clone https://github.com/DhavalBhimani44/zepp-mcp.git
cd zepp-mcp
uv sync

cp .env.example .env      # add ZEPP_EMAIL and ZEPP_PASSWORD
chmod 600 .env

Verify it works — the test suite needs no network and no credentials:

uv run pytest              # 28 tests against the fixture corpus
uv run tools/smoke_test.py # starts the server, lists its tools

Then check your account connects:

uv run python -c "from zepp_mcp.server import zepp_auth_status; print(zepp_auth_status())"

Connecting a local clone

If you're testing your local clone, configure your client to use the local directory instead of uvx.

{
  "mcpServers": {
    "zepp": {
      "command": "uv",
      "args": ["--directory", "/path/to/zepp-mcp", "run", "zepp-mcp"]
    }
  }
}

(Credentials are read from your local .env, so they stay out of the config file)

claude mcp add zepp-local -s user -- uv --directory /path/to/zepp-mcp run zepp-mcp

Add to ~/.gemini/config/mcp_config.json (global) or .agents/mcp_config.json (workspace):

{
  "mcpServers": {
    "zepp": {
      "command": "uv",
      "args": ["--directory", "/path/to/zepp-mcp", "run", "zepp-mcp"]
    }
  }
}

Credentials are read from your local .env.

Architecture

Everything inside the dashed box runs on your laptop. There is no server in the middle, and the single outbound connection is the same HTTPS call the Zepp app itself makes.

flowchart TB
    subgraph machine["YOUR MACHINE - the whole system lives here"]
        direction TB

        client["<b>MCP Client</b><br/>Claude Code · Claude Desktop<br/>any MCP host"]

        subgraph proc["zepp-mcp · local child process"]
            direction TB
            tools["<b>server.py</b><br/>8 MCP tools"]
            norm["<b>workouts.py · decode.py · codes.py</b><br/>stream decoding · lap splitting<br/>sentinel stripping · unit attribution"]
            http["<b>client.py</b><br/>empty-200 classifier · re-auth once"]
            auth["<b>auth.py</b><br/>password login · region discovery"]
            tools --> norm
            norm --> http
            http --> auth
        end

        env["<b>.env</b><br/>credentials · mode 0600"]
        cache[("<b>~/.zepp-mcp/token.json</b><br/>API token only · mode 0600<br/>no health data on disk")]
    end

    zepp["<b>Zepp Cloud API</b><br/>api-mifit-region.zepp.com"]

    client <-->|"<b>stdio</b> · JSON-RPC over stdin/stdout<br/>no network · no open port"| tools
    env -.->|"read at startup"| auth
    auth -.->|"token only"| cache
    http <-->|"<b>HTTPS · read-only</b><br/>the only outbound connection"| zepp

Reading the diagram

Boundary	What crosses it
Client ↔ server	JSON-RPC over stdio. A pipe between two processes on your machine — not a socket, not a port.
Server ↔ Zepp	HTTPS, read-only. Your credentials and your data go nowhere else. The server never writes to your Zepp account.
Server ↔ disk	The API token, and nothing else. No workout, sleep or heart-rate data is ever persisted.

Lifecycle. You never start the server. Your MCP client spawns it when it launches, speaks JSON-RPC over the pipe, and kills it on exit. Every session gets a fresh process — which is exactly why the token is cached, so a restart does not mean a fresh login against Zepp's shared 10-attempt lockout.

Tools

Tool	Returns
`zepp_daily_summary`	Steps, distance, calories and sleep per day
`zepp_sleep`	One night: light / deep / REM / awake minutes, score, resting HR
`zepp_heart_rate`	Per-minute heart rate for a day, plus statistics
`zepp_list_workouts`	All workouts, all sports, with sport-specific metrics
`zepp_workout_detail`	Laps, time-series streams and GPS for one workout
`zepp_training_thresholds`	Lactate threshold HR/pace and VO2 max, with how they've moved over time
`zepp_body_composition`	Smart-scale weight, BMI, and (real scale sync only) body fat/water/muscle %, bone mass, visceral fat, BMR
`zepp_describe_schema`	What the server knows, and where decoding is uncertain
`zepp_raw_request`	Arbitrary GET, for endpoints not modelled yet
`zepp_auth_status`	Token expiry and region host

Privacy

This is health data. The design reflects that.

Nothing is hosted. zepp-mcp is a local stdio process. There is no backend I run, no account to create, and no relay your data passes through.
No health data is written to disk. Every call fetches live.
Only the API token is cached, at ~/.zepp-mcp/token.json (mode 0600). Set ZEPP_TOKEN_CACHE=off to disable and log in every time.
Credentials live in .env, never in client config files, never in source, never in logs.
The fixture corpus is anonymised and CI-gated. Captures come from a real account, so tools/check_fixtures.py runs on every push and fails the build on any name, MAC address, serial number, email, coordinate stream or credential-shaped token. GPS-bearing workouts are excluded entirely — a running route starts where you live.

If you contribute a fixture, run uv run tools/anonymize_fixtures.py first, and install the pre-push hook — force pushes are blocked on main, so a bad push cannot be rewritten away:

ln -sf ../../tools/hooks/pre-push .git/hooks/pre-push

See CONTRIBUTING.md.

How it works

A few decisions are load-bearing, and each came from evidence rather than assumption.

Zepp returns HTTP 200 with an empty body both for "no data in this range" and for requests it silently rejects. The two are indistinguishable from a single response, so the client reports status: "no_data" with that ambiguity attached, and the server instructs the model not to state it as confirmed absence. Rendering it as "you didn't exercise that week" turns a fault into a fact.

heart_rate and temperature are delta-encoded; currentDistance and speed are absolute. Decoding one as the other yields entirely plausible numbers, so each was settled by decoding both ways and checking against the workout's own summary totals — currentDistance resolves to 75600 cm against a reported 756 m, and speed integrates to 1061 m against a reported 1064 m.

Stage modes 4/5/8/7 are light/deep/REM/awake, verified by recomputing each night's stage minutes and matching the summary's own lt/dp/dt/wk fields across three nights. Reporting deep + light as total sleep silently drops REM — 73, 53 and 96 minutes on those nights.

-1 is the general not-applicable marker, but altitude uses -20000, angle -361, elevation -100, temperature -274 (below absolute zero), and SpO₂ uses both -1 and 0. They are stripped per field family. Values also arrive as strings about half the time (dis is "756.0"), so stripping coerces before comparing — otherwise swolf: "-1" survives onto a bike ride.

elevationGain is centimetres: a hike reporting 27961 sits beside its own altitude_ascend: 279 in the same row. It is converted and renamed to elevation_gain_metres, because 27961 emitted raw reads as a plausible metre figure and turns a 280 m hill into an alpine ascent.

Workouts carry syncedTimezone; daily data carries a tz offset in seconds. Rendering in UTC turns an 08:05 swim into 02:35 and moves a 00:20 bedtime to the previous evening.

Sport codes are numeric with no name anywhere in the payload, so the map was built by confirming each code against the Zepp app. An unrecognised code reports as unknown_sport_<code> rather than a guess. Streams with unconfirmed units carry unit_verified: false, and unrecognised streams are returned raw rather than decoded with an assumed encoding.

Known gaps

Documented rather than hidden — zepp_describe_schema reports these at call time too.

Gap	Detail
Lap column names	Columns 1, 13 and 14 are confirmed (duration, strokes, SWOLF — see examples). The remaining named columns are inferred, and anything outside the named set is returned raw.
`pool_swim_pace`	Unit unconfirmed; flagged `unit_verified: false`.
RTPC	Present on every sport (`avg_rtpc_unverified` and friends), reads a constant 21 outside running, but its meaning is unconfirmed — exposed anyway rather than dropped, flagged as unverified.
Cumulative training load	Per-session `exercise_load` is available; the rolling figure is not. `WatchSportStatistics/SPORT_LOAD` returns HTTP 500 server-side. VO2 max itself IS available — see `zepp_training_thresholds`.
Some endpoints	`manualData`, `bloodPressure` and `heartRate` return HTTP 400 — they need parameters not yet worked out.
Multisport	`parent_trackid` / `child_list` handling is built but untested; no triathlon has been recorded yet.
GPS decoding	Untested. The corpus deliberately excludes GPS-bearing workouts.
Zepp Coach	No dedicated endpoint across 22 probed routes with controls (details). Plan progress is confirmed to arrive through the workout row instead — `dailyScore`, `dailyPlanFinished` and `runningProgram` populate once a plan is active, exposed as `training_plan` in `zepp_list_workouts`. `course_title` and `coachInsight` remain unconfirmed, still empty on every run observed.
Metrics without dedicated tools	PAI, SpO₂, stress, HRV, respiratory rate, readiness and Body Charge return real data via `zepp_raw_request`. (A classifier bug used to report all of these as empty regardless of content — fixed; see api-findings.md.)
`zepp_body_composition` fields	`weight_kg`/`height_cm`/`bmi` are verified (bmi reproduces weight / (height/100)²). Everything under `body_composition` (fat/water/muscle %, bone mass, BMR, visceral fat, body score) uses a schema sourced from a different open-source Zepp API client's documented real-scale capture, not from an account this project holds — see api-findings.md. `bmi_consistent: false` marks records (typically manual/HealthKit entries) whose own weight/height/bmi don't reconcile.

Help with any of these is welcome — see CONTRIBUTING.md.

Examples

Three runnable analyses, with real output, live in examples/: swim technique against volume, training load against recovery, and within-session pacing decay.

Project layout

zepp_mcp/           the server
  auth.py           password login, region discovery, token cache
  client.py         HTTP, empty-200 classification, re-auth
  decode.py         band data, workout streams, laps
  workouts.py       index row -> normalised, sport-aware summary
  codes.py          sport codes, sleep stages, sentinels
  server.py         MCP tool definitions
examples/           runnable analyses with real output
tools/              anonymiser, privacy gate, smoke test
tests/fixtures/     anonymised real API captures
docs/               design spec and API reverse-engineering findings
spike/              the throwaway probe that produced the fixtures

Contributing

Contributions are welcome — see CONTRIBUTING.md for the development setup, testing approach, and the rules around fixtures and personal data. By participating you agree to the Code of Conduct.

Especially useful: sport codes from watches other than the maintainer's, and confirmation of the units flagged above.

Legal and safety

Not medical advice. This is a data-access tool. Nothing it returns is a diagnosis, and it should not be used to make medical decisions.
Unofficial and unsupported. Not affiliated with Zepp Health or Huami. The API is private and may change or break at any time.
Your account, your responsibility. Review Zepp's terms before use. The server is read-only and never modifies your account, but automated access may not be something they permit.
No warranty. See LICENSE.

Security

The threat surface is deliberately small: a local process with no listening port, one outbound HTTPS destination, and a single credential file.

To report a vulnerability, see SECURITY.md. Please don't open a public issue for anything credential-related.

License

Available Tools

8 tools

zepp_auth_statusA

Check the stored Zepp credential and connection.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden. It only says 'check', which is vague—does it make a live network call to verify the connection or just check local storage? No side effects, return behavior, or potential failure modes are disclosed.

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 a single short sentence that states exactly what the tool does. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (zero parameters) and has an output schema, but the description leaves ambiguity about what 'connection' means and what the check entails. It is minimally adequate but not fully clear.

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?

No parameters exist, so the baseline is 4. The description does not need to add parameter details, and none are given.

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 uses a specific verb ('Check') and names the resource ('stored Zepp credential and connection'). It clearly distinguishes this tool from sibling data retrieval tools like zepp_heart_rate or zepp_sleep.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied by the name and context (verify auth before using other Zepp tools), but the description does not explicitly state when to use it or mention any alternatives/exclusions.

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

zepp_daily_summaryB

Daily steps, distance, calories and sleep for a date range. Sleep is broken into light/deep/REM/awake minutes.

ParametersJSON Schema

Name	Required	Description	Default
`to_date`	No
`from_date`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions sleep breakdown into stages, which is useful, but does not state whether this is read-only, require auth, or clarify behavior like date range defaults or timezone handling. The absence of any side-effect or permission context limits transparency.

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 two short sentences, front-loaded with the main output metrics, and adds a useful detail about sleep breakdown. Every word provides relevant information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema and sibling tools, so the description doesn't need to detail return values. It covers the basic purpose and sleep granularity, but lacks parameter semantics and fails to explicitly differentiate usage from zepp_sleep. It is adequate for a simple summary but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 2 parameters (from_date, to_date) with 0% description coverage. The description only says 'for a date range' and does not explain date formats, inclusivity, or that both parameters are optional with null defaults. The parameter names are self-explanatory, but the description adds little beyond what the schema property names already imply.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's output: daily steps, distance, calories, and sleep for a date range. It distinguishes from sibling zepp_sleep by explicitly including sleep as one component among broader metrics, though it lacks a direct verb like 'get' or 'retrieve'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used for a daily summary of multiple metrics, but provides no explicit guidance on when to choose this over zepp_sleep or other siblings. It does not state exclusions or alternatives, leaving the agent to infer usage from the listed data fields.

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

zepp_describe_schemaA

Explain what this server knows: which sport codes are identified, which stream units are verified, and where the decoding is still uncertain.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the transparency burden. It honestly discloses that the tool reports both verified aspects and uncertain decoding areas, which is valuable context. It also implicitly confirms a read-only describe operation, though it doesn't mention auth or side effects.

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?

A single, front-loaded sentence that efficiently conveys purpose and scope. Every word earns its place, with no redundancy or filler.

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 simple nature, zero parameters, and presence of an output schema, the description fully covers what the agent needs to know. It explains the tool's role in the context of zepp_* siblings and provides specific examples of the schema information it will reveal.

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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter info, but none is needed as the schema already fully covers the empty parameter set.

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 uses a specific verb 'Explain' and a clear resource ('this server knows'), and enumerates concrete topics: sport codes, stream units, and decoding uncertainty. This clearly distinguishes it from sibling data-retrieval tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for understanding server capabilities before querying data, which is a useful context given the sibling tools are all data fetchers. However, it does not explicitly state when not to use it or name an alternative.

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

zepp_heart_rateC

Per-minute heart rate for a single day, with a summary. Minutes with no reading are returned as null.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No
`include_series`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior3/5

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

The description discloses that minutes without readings are returned as null, which is useful behavioral information. However, it does not mention authentication needs, the exact structure of the summary, or any limitations, leaving some transparency gaps given that no annotations are provided.

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 two short sentences and front-loads the core purpose. There is no unnecessary wording, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with only two parameters and has an output schema, so the description adequately conveys the basic output concept. However, it does not clarify the default behavior for a null date or the effect of include_series, leaving some ambiguity for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain the 'date' or 'include_series' parameters. With 0% schema description coverage, this is a significant omission that forces the agent to infer meaning solely from parameter names and defaults, adding no semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns per-minute heart rate for a single day with a summary, which distinguishes it from siblings like zepp_sleep or zepp_daily_summary. The verb is implied rather than explicit, but the resource and scope are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as zepp_daily_summary or zepp_sleep. The description simply states what the tool does without any contextual usage advice or exclusions.

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

zepp_list_workoutsA

List workouts across all sports, with sport-specific metrics (SWOLF and stroke counts for swims, pace and cadence for runs, set counts for strength work).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`sport`	No
`to_date`	No
`from_date`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It discloses that results include sport-specific metrics, adding value beyond the schema. However, it does not mention ordering, pagination, or that it returns summaries, leaving some gaps for a read-only list operation.

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 a single, front-loaded sentence with no wasted words. It effectively communicates the core purpose and key detail about metrics, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with 4 optional parameters, the description covers purpose and metric variety, and an output schema exists so return structure is not needed. However, it lacks explicit usage guidance and does not clarify parameter behavior beyond the schema names, leaving modest gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It partially addresses the 'sport' parameter by saying 'across all sports' and hinting at sport-specific metrics, but entirely ignores 'limit', 'from_date', and 'to_date'. This is minimal compensation for four undocumented parameters.

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's action ('List workouts') and scope ('across all sports'), with specific detail about sport-specific metrics. This distinguishes it from sibling tools like zepp_workout_detail, which likely retrieves details for a single workout.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for browsing workouts and their metrics, but does not explicitly state when to use it versus alternatives like zepp_workout_detail. Context suggests listing versus detail, but no explicit exclusions or alternative guidance is provided.

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

zepp_raw_requestA

Send an arbitrary GET to the Zepp API. Use this to reach endpoints this server does not model yet.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description carries full behavioral transparency burden. It discloses the HTTP method (GET) and scope ('arbitrary'), but does not reveal authentication requirements, error handling, rate limits, or how the response is returned. This is a significant gap for a tool that sends requests to a third-party API.

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 extremely concise, consisting of two sentences that are front-loaded and directly informative. No filler or redundant details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple structure and presence of an output schema, the description covers purpose and usage context well. However, the lack of parameter semantics and behavioral caveats (authentication, error handling) makes it incomplete for an agent to invoke correctly without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the meaning of 'path' and 'params' beyond their names. It fails to specify that 'params' are query parameters or how the URL is constructed, requiring the agent to infer behavior from context.

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 action ('Send an arbitrary GET to the Zepp API'), specifies the HTTP method, and gives a distinct purpose ('endpoints this server does not model yet'). This differentiates it from sibling tools that target specific Zepp APIs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use this tool: 'Use this to reach endpoints this server does not model yet.' This implies using dedicated tools for modeled endpoints, though it doesn't list specific exclusions or alternatives.

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

zepp_sleepC

Sleep breakdown for a single night: light, deep, REM and awake minutes, sleep score and resting heart rate.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must carry the behavioral transparency burden. It discloses the output fields but does not mention read-only nature, date format or timezone handling, potential limitations, or any side effects. The description primarily repeats what the output schema likely contains, adding little beyond that.

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 a single, front-loaded sentence that names the resource and immediately lists the output fields. Every word earns its place, with no filler or redundancy. This is a model of conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the output fields are well described, the essential 'date' parameter is left completely unexplained. Given the tool has only one parameter and no annotation coverage, the description should have clarified how to select the night (e.g., date format or timezone). The output schema exists but the input side is under-specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one 'date' parameter with 0% description coverage, and the tool description completely omits any mention of how to specify the date. No format, default behavior, or optionality is explained beyond the schema's bare structure. The description adds zero value for parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the resource is sleep data for a single night and enumerates the specific metrics returned (light, deep, REM, awake minutes, sleep score, resting heart rate). It distinguishes itself from siblings by focusing on 'single night' breakdown, though it lacks an explicit verb like 'get' or 'retrieve'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for a single night' implies the tool is meant for per-night sleep details, giving some usage context. However, there is no explicit mention of when to use this over alternatives like zepp_daily_summary or zepp_heart_rate, nor any exclusion criteria.

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

zepp_workout_detailA

Full detail for one workout: laps, time-series streams and GPS. Get the track_id and source from zepp_list_workouts.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes
`include`	No
`track_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states the nature of the data returned (laps, streams, GPS) but does not mention any side effects, authentication requirements, rate limits, or error behavior. Since it is a read operation implied by 'Full detail', this is acceptable but not richly transparent.

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 two short sentences that are front-loaded with the core purpose. Every word adds value, with no wasted text or repetition of schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity (3 parameters, output schema present), the description is complete enough. It references the companion tool for required IDs and lists the primary data components. The optional 'include' parameter is not mentioned, but its absence does not severely impair understanding due to output schema availability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It clarifies that track_id and source are obtained from zepp_list_workouts, giving them practical meaning. However, the 'include' parameter is left unexplained, and no other parameter details are provided, so it only partially compensates.

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's function: retrieving full detail for a single workout, including laps, time-series streams, and GPS. It distinguishes itself from the sibling zepp_list_workouts by focusing on one workout and referencing that tool for identifiers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit workflow guidance: 'Get the track_id and source from zepp_list_workouts.' This tells the agent how to obtain required parameters and implies a sequential usage pattern. However, it does not explicitly contrast with other sibling tools beyond list_workouts, so it falls short of a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.1.0Aug 17, 2026
- First observedzepp_auth_status
- First observedzepp_daily_summary
- First observedzepp_describe_schema
- First observedzepp_heart_rate
- First observedzepp_list_workouts
- First observedzepp_raw_request
- First observedzepp_sleep
- First observedzepp_workout_detail

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool targets a distinct aspect of the Zepp API: daily aggregates, heart rate, sleep, workout list, workout detail, schema introspection, raw API access, and authentication status. There is no meaningful overlap between them, even though daily_summary and sleep both touch sleep data—they serve different granularity levels.

Naming Consistency3/5

All tool names share the 'zepp_' prefix, but the naming convention is mixed: some are noun phrases (zepp_sleep, zepp_heart_rate, zepp_workout_detail), some are verb phrases (zepp_list_workouts, zepp_describe_schema), and others are compound adjectives/nouns (zepp_daily_summary, zepp_raw_request, zepp_auth_status). The pattern is not consistent, though each name is still readable and communicates its purpose.

Tool Count5/5

With 8 tools, the server is well-scoped for a health data API. It covers the main data domains (daily stats, heart rate, sleep, workouts) plus essential utilities (schema, raw request, auth). This is within the ideal 3–15 range and no tool feels redundant or excessive.

Completeness4/5

The tool set covers the core read-side of the Zepp API: daily summary, heart rate, sleep, and workout details. The inclusion of zepp_raw_request and zepp_describe_schema mitigates gaps by allowing access to unimplemented endpoints and documenting uncertainties. Minor gaps exist (e.g., no explicit body composition or user profile tools), but the surface is adequate for most health data use cases.

Maintenance

ActivityMaintained

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Withings Health DataOAuth
io.github.akutishevsky
MCP server for Withings health data — sleep, activity, heart, and body metrics.
Health & Wellness Research & Data
241
MCP for OuraOAuth
link.smirnov
Multi-tenant hosted MCP server for Oura Ring — 21 read-only tools, OAuth per user.
Health & Wellness Fitness Tracking
2
SomviaOAuth
app.somvia
Private Apple Health metrics and workout detail for ChatGPT, Claude, and any MCP client.
Health & Wellness Fitness Tracking
2
Coach WattsOAuth
com.coachwatts
Remote MCP server for training, nutrition, wellness, and performance data with OAuth 2.0.
Health & Wellness Fitness Tracking
271

Related MCP Servers

Zepp Life MCP
Health & Wellness Fitness Tracking
kubulashvili
A
license
B
quality
B
maintenance
MCP server that provides local caching, sync, and tools for Zepp Life health data including steps, sleep, heart rate, workouts, and body measurements, supporting both file exports and cloud session access.
Updated a month ago (2026-08-05 12:04 UTC)
10
9
MIT
Mi Fitness MCP
Health & Wellness Fitness Tracking
kubulashvili
A
license
C
quality
C
maintenance
MCP server for Mi Fitness cloud data. Provides a local SQLite-backed server to sync and query daily activity, heart rate, and body measurements.
Updated a month ago (2026-08-05 12:05 UTC)
12
4
MIT
Garmin MCP
Health & Wellness Fitness Tracking
lokranjanp
A
license
A
quality
D
maintenance
MCP server that exposes Garmin Connect health and activity data (steps, sleep, stress, activities, etc.) via tools for querying, analysis, and visualization.
Updated 7 months ago (2026-02-20 05:31 UTC)
17
Apache 2.0
Akari Health MCP
Health & Wellness Fitness Tracking
yoruuuchan
A
license
Not graded
quality
B
maintenance
MCP server exposing self-hosted health data from a vivo WATCH GT via 14 tools for querying metrics like heart rate, SpO2, stress, and sleep over stdio and Streamable HTTP.
Updated 6 days ago (2026-09-01 06:21 UTC)
1
AGPL 3.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DhavalBhimani44/zepp-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

zepp-mcp

This runs entirely on your own machine

Contents

Features

Setup for Users

Developer Setup

Connecting a local clone

Architecture

Tools

Privacy

How it works

Known gaps

Examples

Project layout

Contributing

Legal and safety

Security

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API