Quantified Self MCP Server
Related Servers
Alternatives to Quantified Self MCP Server
- AlicenseAqualityAmaintenanceAn MCP server that allows users to query and analyze their Apple Health data using SQL and natural language, utilizing DuckDB for fast and efficient health data analysis.354 npm576MIT
- AlicenseAqualityAmaintenanceMCP server for the Google Health API: heart rate, activity, sleep, SpO2, HRV, ECG and irregular-rhythm notifications, read into a local SQLite cache for fast offline queries and trend analysis. OAuth 2.0 with automatic token refresh, incremental sync, a cache-only offline mode, and a doctor command that diagnoses a setup without spending quota.24202 PyPI1GPL 3.0
Related Servers
- FlicenseAqualityBmaintenanceEnables LLMs to answer small business finance questions about spending, sales trends, cash flow projections, and profitability using a local SQLite database.6-
- AlicenseNot gradedqualityCmaintenanceLoads Apple Health export data into a local SQLite database and exposes tools to query health metrics and workout records via natural language.26 PyPI3MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to execute arbitrary SQL queries on a local SQLite database via a single execute_sql tool.1MIT
- AlicenseNot gradedqualityDmaintenanceEnables querying personal data synced from services like Lunch Money and Strava using SQL via Claude.1 npm1MIT
- AlicenseBqualityDmaintenanceEnables AI agents to interact with local SQLite databases with full CRUD, schema introspection, foreign key relations, generated columns, and multi-format import/export (CSV, JSON, XLSX) through natural language.262 npmMIT
- FlicenseNot gradedqualityDmaintenanceEnables querying and summarizing chat messages from a local database.-
TDQS
Scored across 20 tools
Each tool has an explicit 'use this when / do not use this when' section that routes the agent to the correct alternative, and the overlapping candidates (read_health_data vs get_metric_history vs read_measurements, get_baseline vs calculate_metric_trend vs detect_metric_anomalies) are cleanly distinguished by scope. The read/write/log/aggregate/analytics split is unambiguous even for an agent scanning names alone.
All names are snake_case verb_noun, but read-only tools mix 'read_*' (read_health_data, read_measurements) and 'get_*' (get_metric_history, get_baseline) with no clear rule distinguishing them, and some names append _csv or use long sub-verbs. Still predictable and readable, just not perfectly uniform.
20 tools is on the heavy side, but the domain genuinely spans raw/aggregate reads, two logging paths, workout sessions, provenance, status/imports, and seven distinct analytics operations. Each tool covers a distinct capability rather than padding, so the count is justified, if slightly large.
The surface covers read/aggregate/log/clear for metrics plus workouts, provenance, data/import status, CSV export, and a full analytics suite (baseline, anomaly, trend, period compare, correlation, recent changes, explain). Minor gaps remain: no update/delete for individual measurements or workout sessions beyond clear_metric for daily metrics.