zepp-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 3.5/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 20 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

zepp-mcp MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![zepp-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/DhavalBhimani44/zepp-mcp/badges/card.svg)](https://glama.ai/mcp/servers/DhavalBhimani44/zepp-mcp)

Score Badge

Copy to your README.md:

[![zepp-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/DhavalBhimani44/zepp-mcp/badges/score.svg)](https://glama.ai/mcp/servers/DhavalBhimani44/zepp-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![zepp-mcp MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2FDhavalBhimani44%2Fzepp-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/DhavalBhimani44/zepp-mcp)

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