Life Dashboard
OCI · GHCR.IO/OWEN282000/LIFE-DASHBOARD-MCP
Read-only health and screen time history from the Postgres of a self-hosted Life Dashboard Stack
Available components
Last scanned (23 hours ago)
Scores higher than 97% of OCI servers
Category Health and Science
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security0
- No malware scan is available for this kind of package: the supply-chain vendors we use do not cover it. This is a permanent gap in our coverage, not a finding about the package.Unverified
- Known CVEs could not be checked: this image's dependency list comes from an SBOM its publisher attached, which nothing verifies, so we will not report it as a clean result.Unverified
- Install-script risk not yet assessed.Unverified
- Dependency health could not be checked: this image's dependency list comes from an SBOM its publisher attached. It names packages and versions but not whether each is deprecated, still maintained or linked to its source, so there is nothing we can fairly grade.Unverified
Provenance & Transparency100
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to owen282000/life-dashboard-stack). View diagnostics → Pass
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 2 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability61
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 1654 tokens (~206/item across 8 items; 8 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management60
- Stability observed for 18 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 8 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 9 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
Unverified: 1 category
A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 3 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.
- 1 Nov 26 0
- Tool safety: pass → unverified ▼ security
- Stability: 0.47 → unverified ▼ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- First check of Schema quality: unverified functional
- Package version: 1.2.0 → 1.2.1 functional
- 31 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.
- 29 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.
- 27 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.
- 25 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.
- 23 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.
- 22 Oct 26 0
- Stability: 0.13 → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- First check of Schema quality: unverified functional
- Package version: 1.1.2 → 1.2.0 functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 4 Nov 2026 · Analysed oci/ghcr.io/owen282000/life-dashboard-mcp@1.2.1
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | oci |
| Reason | Verified |
| Discovered via | OCI referrers API |
| Source repo | owen282000/life-dashboard-stack |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/owen282000/life-dashboard-stack/.github/workflows/release.yml@refs/tags/1.2.1 |
| Rekor log index | 3636198776 |
| Predicate type | SLSA build provenance https://slsa.dev/provenance/v1 |
| Subject digest | sha256:34a3f6c2085be583819a747094b564e84169d67c5a5da053984b67dab892856b |
Background: How many MCP packages publish verified provenance →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
daily_summary ~173
Totals per day, one row per phone and day: steps, distance_km, active_kcal, total_kcal, sleep_h and in_bed_h (the night that ended that morning), exercise_min and workouts, screen_min (Android only), resting_hr (bpm) and weight_kg. Steps, distance and calories are the phone's daily totals, counted once across phone and watch. null means nothing was recorded. complete=false marks today, a running total. Dates are inclusive, at most 92 days per call.
| Name | Type | Req | Description |
|---|---|---|---|
| from_date | string | yes | A date as YYYY-MM-DD |
| phone | – | – | A phone label from list_phones, such as pixel. Leave it out for every phone. |
| to_date | string | yes | A date as YYYY-MM-DD |
No output schema declared.
No examples provided.
data_catalog ~189
What each phone has stored and what the other tools can answer from it. Per phone: every type of data (the payload key, such as heart_rate or sleep) with its records, windows (series sent per time window), the apps that wrote it (sources), its first and last local day, and read=false when no tool reads it (the dashboards still show it). tools gives, per tool, what has data: the daily_summary fields, the day range of sleep_nights, workouts and screen_time (null when there is none), and every trend metric with its day range. Steps per day come from daily_totals, so raw steps records show read=false. Call it before asking for a metric, to know whether and since when it exists.
| Name | Type | Req | Description |
|---|---|---|---|
| phone | – | – | A phone label from list_phones, such as pixel. Leave it out for every phone. |
No output schema declared.
No examples provided.
list_phones ~65
List the phones that send data to this stack: label, platforms (Android, iPhone, Screen time), device, app version, when it last sent data, and the first and last day with data. Also gives the time zone and today's date. Call this first.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
screen_time ~102
Screen time on one day per phone: total_min, the number of apps, the last use, and the top 10 apps with their minutes. The day is the app's day, which runs from 04:00 to 04:00 by default. Android phones only.
| Name | Type | Req | Description |
|---|---|---|---|
| date | string | yes | A date as YYYY-MM-DD |
| phone | – | – | A phone label from list_phones, such as pixel. Leave it out for every phone. |
No output schema declared.
No examples provided.
sleep_nights ~156
One night per phone, on the date the person woke up: bedtime and wake_time (local time), asleep_h, in_bed_h, deep_h, light_h, rem_h and awake_h (stages are null when the night has none), hr_low (the lowest 10-minute average heart rate in the night, not the resting heart rate) and hr_avg. Dates are wake dates, inclusive, at most 92 days per call.
| Name | Type | Req | Description |
|---|---|---|---|
| from_date | string | yes | A date as YYYY-MM-DD |
| phone | – | – | A phone label from list_phones, such as pixel. Leave it out for every phone. |
| to_date | string | yes | A date as YYYY-MM-DD |
No output schema declared.
No examples provided.
sync_status ~213
When each phone last sent data and when each type of data last arrived. Per phone: payload_sources (Android, iPhone or Screen time) with the last payload, hours since, payloads in the last 24 hours and app version; types with last_time (the newest record), last_received (when the receiver last stored any of it), days_since, active_days (local days with data in the 28 days up to the newest record), usual_gap_days (28, or fewer for a younger type, divided by active_days) and quiet; sources: per type and writing app, its newest record and whether it went quiet. quiet means the newest record is older than twice the usual gap; null when the type had data on one day only. A source is quiet by the same rule when it wrote the type in those 28 days. quiet lists the quiet types.
| Name | Type | Req | Description |
|---|---|---|---|
| phone | – | – | A phone label from list_phones, such as pixel. Leave it out for every phone. |
No output schema declared.
No examples provided.
trend ~442
One metric over the last `days` complete days (up to yesterday) against the same number of days before: mean, lowest and highest day, days with data, and the change of the mean (absolute and in percent). For exercise_min a day without a workout counts as 0 in the mean; for every other metric the mean is over days with data.
| Name | Type | Req | Description |
|---|---|---|---|
| days | integer | – | Length of the period in days, 7 to 365 |
| metric | string | yes | What to measure: steps (steps): Steps per day, counted once across phone and watch; distance_km (km): Distance per day; active_kcal (kcal): Active energy per day; total_kcal (kcal): Total energy per… |
| phone | – | – | A phone label from list_phones, such as pixel. Leave it out for every phone. |
No output schema declared.
No examples provided.
workouts ~124
Every workout: day, start_time and end_time (local time), activity (such as running, walking or biking), minutes and the app that recorded it. A workout that a watch and a phone app both recorded is listed once. Dates are inclusive, at most 92 days and 100 workouts per call.
| Name | Type | Req | Description |
|---|---|---|---|
| from_date | string | yes | A date as YYYY-MM-DD |
| phone | – | – | A phone label from list_phones, such as pixel. Leave it out for every phone. |
| to_date | string | yes | A date as YYYY-MM-DD |
No output schema declared.
No examples provided.
How do I install the Life Dashboard MCP server?
Life Dashboard runs locally as a container image, launched with docker run --rm -i -e MCP_TRANSPORT -e PGHOST -e PGDATABASE -e PGUSER -e PGPASSWORD ghcr.io/owen282000/life-dashboard-mcp:1.2.1. Ready-made configuration for Claude, Cursor, VS Code, Codex and 3 more is on this page, copied from each client's own documentation.
oci · ghcr.io/owen282000/life-dashboard-mcp
claude mcp add owen282000-life-dashboard -- docker run --rm -i -e MCP_TRANSPORT -e PGHOST -e PGDATABASE -e PGUSER -e PGPASSWORD ghcr.io/owen282000/life-dashboard-mcp:1.2.1
This image reads MCP_TRANSPORT, PGHOST, PGDATABASE, PGUSER and PGPASSWORD. Set them in your client's env block for this server; docker run -e passes each one through to the container.
What is the Life Dashboard MCP server?
Life Dashboard is an MCP server listed in the public MCP registry as io.github.owen282000/life-dashboard. Read-only health and screen time history from the Postgres of a self-hosted Life Dashboard Stack. This page covers its container image (ghcr.io/owen282000/life-dashboard-mcp).
Is the Life Dashboard MCP server safe to use?
Life Dashboard scores 57 out of 100 on VerifyMCP. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Life Dashboard MCP server expose?
Life Dashboard exposes 8 tools: list_phones, data_catalog, sync_status, daily_summary, sleep_nights, and 3 more. Their descriptions and schemas cost roughly 1,464 tokens of context every time the server is loaded.
Is the Life Dashboard MCP server still maintained?
Life Dashboard is still listed as active in the MCP registry. We last reached this channel on 4 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the Life Dashboard MCP server under?
Life Dashboard declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.