Privacy-first MCP server for personal health data, compatible with both local and online AI agents.
Quantified Self MCP
以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →
> **Your health data. Your AI. Your machine.**
>
> A local-first MCP server that gives AI agents access to your personal health data — with **privacy, provenance, and evidence built in**.
· **Documentation**
---
What is it?
Quantified Self MCP gives an AI agent a **local, structured interface to your own health history**.
Instead of another health dashboard, you can ask your AI questions like:
The AI retrieves the relevant data through MCP and analyzes it.
> **The goal isn't another health dashboard.**
>
> **It's a trustworthy interface between your health history and your AI.**
---
Why is it different?
🔒 Local-first
Your health database runs locally in SQLite.
You control where your data goes.
You can use a completely local AI stack:
Cloud models are also supported. In that configuration, the MCP database remains local, but data returned by MCP tools may be sent to the model provider.
🤖 AI-native
Built specifically for **MCP-compatible AI agents**, rather than another standalone health application.
🔎 Evidence & provenance
Analytics can be traced back to the underlying health data and its provenance.
The goal is not simply:
but understanding:
Concretely, every trend, baseline, anomaly, comparison, correlation, recent change, and explained metric carries a claim alongside its numbers — not just descriptive coverage, but an explicit, machine-checkable statement of how strongly the result may be reported:
evidence is descriptive: it reports the coverage a result rests on (how many days were logged, how large any gaps are, how fresh the data is). profile evaluates that coverage along several independent dimensions rather than collapsing it into one number. decision is the authoritative output: the only field that says how strongly the result may actually be claimed, and it is derived exclusively from the assessed dimensions in profile — never from a raw coverage number by itself. Composite results (like explaining a metric change, which combines a headline claim, a trend claim, and any correlations) roll their component decisions up into a single overall_decision, which is never stronger than the weakest component.
**Without evidence:**
> Your HRV decreased 24% over the last 30 days.
**With evidence:**
> Your HRV decreased 24% over the last 30 days — but HRV was only logged on 71% of those days, so treat this trend cautiously rather than as a settled pattern.
The second answer is what calculate_metric_trend (and every other analytics tool) is designed to make possible: the tool returns the 24% figure *and* a claim.decision alongside it (e.g. tier: "suggestive", with must_state naming the specific gaps and low-coverage days behind that tier), and each tool's own description tells the calling model to report that tier and those caveats rather than stating the number as if it came from a complete series.
📊 Longitudinal
Analyze health history across days, weeks, months, and years:
- trends
- baselines
- anomalies
- period comparisons
- correlations
- recent changes
- metric explanations
📥 Import existing data
Bring your existing health history into the local database.