Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@eufylife-scale-mcp What was my latest weigh-in on the Eufy scale?"
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.
An MCP server that gives Claude (or any MCP client) read-only access to the weight and
body composition measured by Eufy smart scales and synced to the EufyLife app. It talks to
the EufyLife cloud API with its own small async client (eufylife_mcp.core); the API
behaviour it relies on follows eufylife-api-hacs
and eufylife-mcp.
EufyLife has no public API. This server logs in the way the app does, so it can break when Eufy changes the app's API.
Tool | Returns |
| Member profiles (people) on the EufyLife account |
| Most recent weigh-in with body composition |
| Weigh-ins from the last |
The measurement tools take an optional member: a name ("Ann") or a member_id from
list_members. When omitted, the account owner (the default member) is used.
Measurements include timestamp_utc, weight_kg, weight_lb, and whatever body
composition the scale measured: bmi, body_fat_pct, body_fat_mass_kg,
subcutaneous_fat_pct, visceral_fat_level, muscle_pct, muscle_mass_kg,
skeletal_muscle_mass_kg, fat_free_mass_kg, bone_mass_kg, water_pct,
protein_pct, bmr_kcal, body_age_years and heart_rate_bpm. Metrics the scale did not
measure (for example when weighing in with socks on) are left out. The latest measurement
also has age_hours.
Related MCP server: FeelFit MCP Server
For a step-by-step guide, including troubleshooting, see the installation guide. Full documentation is at https://eufylife-scale-mcp.readthedocs.io.
You need the EufyLife account (email and password) that your scale syncs to. Accounts that sign in with Google or Apple have no password; set one in the EufyLife app first.
git clone https://github.com/osjayaprakash/eufylife-scale-mcp.git && cd eufylife-scale-mcp
uv syncVariable | Required | Default | Meaning |
| yes | EufyLife account email | |
| yes | EufyLife account password | |
| no |
| Two-letter country code of the account, e.g. |
No clone needed; uv fetches and runs the published package:
uvx eufylife-scale-mcpIn a client config, use "command": "uvx", "args": ["eufylife-scale-mcp"].
The server speaks MCP over stdio, so keep -i:
docker run -i --rm \
-e EUFYLIFE_EMAIL -e EUFYLIFE_PASSWORD -e EUFYLIFE_COUNTRY \
ghcr.io/osjayaprakash/eufylife-scale-mcp:latestIn a client config, use "command": "docker" with those arguments, and pass the
variables through the client's env block.
Add to claude_desktop_config.json:
{
"mcpServers": {
"eufylife": {
"command": "uv",
"args": ["--directory", "/absolute/path/to/eufylife-scale-mcp", "run", "eufylife-scale-mcp"],
"env": {
"EUFYLIFE_EMAIL": "you@example.com",
"EUFYLIFE_PASSWORD": "your-password",
"EUFYLIFE_COUNTRY": "US"
}
}
}
}claude mcp add eufylife \
-e EUFYLIFE_EMAIL=you@example.com \
-e EUFYLIFE_PASSWORD=your-password \
-e EUFYLIFE_COUNTRY=US \
-- uv --directory /absolute/path/to/eufylife-scale-mcp run eufylife-scale-mcpEach tool call becomes a Langfuse trace, with a child span for the EufyLife API call. Install the extra and set the keys:
uv sync --extra langfuseIn the server command, use run --extra langfuse eufylife-scale-mcp instead of
run eufylife-scale-mcp.
Variable | Meaning |
| Tracing is on only when both are set |
| Langfuse URL for self-hosted or regional instances (default: Langfuse Cloud) |
|
|
Privacy: weight and body composition are health data. By default, traces hold only
tool names, timings, member IDs, and error class names. Setting LANGFUSE_CAPTURE_DATA=true
sends measurements and names to your Langfuse instance; only do that with an instance you
trust, such as a self-hosted one.
uv sync
uv run pytest # offline suite
uv run pytest -m live # hits the real API; needs EUFYLIFE_EMAIL/PASSWORD
uv run ruff check src tests && uv run ruff format --check src testsBump version in pyproject.toml and server.json (both places in each package entry),
then push a matching tag:
git tag v0.1.0 && git push origin v0.1.0That tag publishes to PyPI (pypi.yml, needs the PYPI_API_TOKEN secret), to
ghcr.io/osjayaprakash/eufylife-scale-mcp (docker.yml), and then to the MCP Registry
(mcp-registry.yml). Read the Docs builds the documentation from master.
Most recent weigh-in with its body composition.
Check age_hours: this is the last time the person stepped on the scale.
| Name | Required | Description | Default |
|---|---|---|---|
| member | No | Name (e.g. 'Ann') or member_id from list_members. Omit for the account owner, or when the account has one member. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context about the `age_hours` field meaning 'last time the person stepped on the scale,' which is behavioral insight beyond the annotations, but nothing about empty results or freshness limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short front-loaded sentences with no wasted words. The `age_hours` note is somewhat tangential to invoking the tool but is compact and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and annotations cover the safety profile, so return values and read-only behavior need not be restated. For a zero-required-parameter lookup, the definition is nearly complete, missing only usage routing against get_measurement_history.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema coverage is 100%, so the schema fully documents the optional `member` argument including omission behavior. The description adds no parameter-level meaning, which is the expected baseline when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: 'Most recent weigh-in with its body composition.' It is clearly distinct from get_measurement_history, though it never names the sibling to make the contrast explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given. The description does not say to use this instead of get_measurement_history when only the newest record is needed, nor does it mention prerequisites or when results may be empty.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Weigh-ins from the last days days (default 30), oldest first.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days back to include, counting from now. | |
| member | No | Name (e.g. 'Ann') or member_id from list_members. Omit for the account owner, or when the account has one member. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds ordering semantics ('oldest first') and the default window, which are genuinely useful beyond the annotations, but it says nothing about volume limits, pagination, or empty-history behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler, and the ordering clause is useful. The '(default 30)' restates the schema default, a small redundancy that keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and annotations cover the read-only nature. For a simple two-parameter read tool the description is adequate, though it could have noted the multi-member case to match the schema's `member` guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both `days` and `member` are fully documented in the schema and the baseline of 3 applies. The description only restates the `days` default and adds no meaning the schema lacks; `member` is not mentioned at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (weigh-ins) and scope (last `days` days, oldest first), which is enough to distinguish it from get_latest_measurement in practice. However, it never names or contrasts with that sibling explicitly, so the differentiation is inferential rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given. The agent must infer from the name and the sibling set that this is for historical ranges while get_latest_measurement returns the most recent reading; nothing in the text confirms this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the member profiles (people) on this EufyLife account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the scoping constraint (members belong to 'this EufyLife account'), which is useful context, but says nothing about pagination, ordering, or result volume.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler; the verb and scope land first and nothing is repeated from structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and with no parameters there is little surface area to cover. The only residual gap is any hint about result size or ordering for a list operation, which is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (member profiles / people) scoped to the EufyLife account. The resource is unambiguous and clearly distinct from the measurement-focused siblings get_latest_measurement and get_measurement_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no when-to-use guidance, no prerequisites, and no mention of alternatives. For a list tool this is implied by the name, but nothing in the text helps an agent decide when this is preferable to the measurement siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_latest_measurementget_measurement_historylist_membersScored across 3 tools
The three tools target distinct resources: member listing vs. measurement retrieval. However, get_latest_measurement is essentially a special case of get_measurement_history (the newest entry), so an agent could reasonably confuse the two when only the latest reading is needed.
All tools follow a consistent verb_noun snake_case pattern: list_members, get_latest_measurement, get_measurement_history. The verbs are appropriate and predictable for their actions.
Three tools is a small but reasonable surface for a read-only smart-scale integration. Each tool has a clear role, though the set sits at the lower bound and leaves little margin for additional read operations.
The core read paths are covered: enumerate members, fetch the latest body-composition measurement, and retrieve historical weigh-ins. Minor gaps exist (e.g., no tool to fetch a single measurement by ID, no member-specific filter explicitly documented), but nothing that would block typical agent queries.
MCP server for Withings health data — sleep, activity, heart, and body metrics.
Read wearables and lab health data — sleep, activity, workouts, timeseries, lab tests and orders.
Read your workouts, history, and stats; create and schedule new workouts. Writes are additive only.
Hyperscale Product reads and contract operations over MCP.
