MCP クライアントから SQL と DuckDB を使って Apple Health データを照会します。このサーバーはローカルで実行され、必要に応じて CSV エクスポートを読み取り、スキーマ探索、読み取り専用クエリ、健康サマリーのツールを提供します。
Node.js 22 以降
Simple Health Export CSV で作成された Apple Health CSV エクスポート
ネイティブの Apple Health export.xml 形式は現在サポートされていません。
Related MCP server: apple-mcp
Claude Desktop の場合、以下を ~/Library/Application Support/Claude/claude_desktop_config.json に追加します。
{
"mcpServers": {
"apple-health": {
"command": "npx",
"args": ["-y", "@neiltron/apple-health-mcp"],
"env": {
"HEALTH_DATA_DIR": "/path/to/your/unzipped/health-export"
}
}
}
}設定を変更したらクライアントを再起動します。他の MCP クライアントでも同じコマンド、引数、環境、stdio トランスポートを使用できます。
変数 | 必須 | デフォルト | 目的 |
| はい | — | エクスポートされた CSV ファイルを含むディレクトリ |
| いいえ |
| DuckDB のメモリ制限（メガバイト単位） |
| いいえ |
| キャッシュされるクエリ結果の最大数 |
iPhone で Simple Health Export CSV をインストールして開きます。
すべて を選択し、エクスポートする期間を選択します。
アーカイブを MCP クライアントを実行しているコンピュータに転送します。
解凍し、HEALTH_DATA_DIR をそのディレクトリに設定します。
サーバーはファイルをその場で読み取ります。エクスポートをアップロードしたり、ネットワークリクエストを行ったりすることはありません。ただし、MCP クライアントに返されたクエリ結果は、そのクライアントの設定されたモデルプロバイダーに送信される可能性があります。
ツール | 目的 |
| テーブル名、列、単位、サンプル行を検出する |
| JSON、CSV、またはサマリー出力で読み取り専用の |
| 週次、月次、またはカスタムの健康サマリーを生成する |
まず health_schema から始めてください。テーブル名はエクスポート内のファイルによって異なります。データモデルと実用的な例については、Apple Health データのクエリ を参照してください。
テーブルを必要とする最初のリクエストは、そのテーブルの完全な CSV 履歴を読み込みます。日付ウィンドウはないため、クエリはエクスポートが遡れる限り遡ることができます。
すべてのツールが設定された履歴全体にアクセスできるため、このサーバーはそのデータを信頼できる MCP クライアントからのみ起動してください。
読み込まれたテーブルはメモリに保持され、DuckDB には上記の MAX_MEMORY_MB 制限が与えられます。約 1 GiB で 2 年間の複数テーブルのエクスポートをカバーできるため、2048MB のデフォルトには余裕があります。より大きなエクスポートの場合は MAX_MEMORY_MB を引き上げてください。サーバーは健康データの行をディスク上の一時ディレクトリに書き出すことはないため、制限に収まらないエクスポートは明示的なエラーで失敗します。
その他の現在の制限:
Simple Health Export CSV レイアウトのみがサポートされています。
DuckDB データベースはメモリ内にあり、サーバープロセスごとに再構築されるため、起動のたびに CSV ファイルから再読み込みされます。永続的な増分インポートは将来の作業として計画されており、現在の動作ではありません。
デバイスの重複により、重複したように見える測定値が発生する可能性があります。クエリでは必要に応じて sourceName を考慮する必要があります。
健康レポートは記録されたデータを要約したものであり、医学的アドバイスではありません。
git clone https://github.com/neiltron/apple-health-mcp.git
cd apple-health-mcp
bun install
npm test
npm run typecheck
npm run buildコードレイアウト、データライフサイクル、実装の制約については、アーキテクチャ を参照してください。
MIT
Run one analytical query on Apple Health data.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | One DuckDB analytical query. Joins, CTEs, subqueries, set operations, and window functions are supported. | |
| format | No | Output format (default: json) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It states the tool runs a query but does not explicitly disclose that it is read-only, whether there are side effects, limits on query complexity or result size, or what the tool returns. 'Analytical query' weakly implies a read operation, but this is under-specified for a tool that accepts arbitrary SQL.
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?
The description is a single front-loaded sentence with no filler: it names the verb, resource, and scope immediately. It is concise, but so terse that it misses opportunities to add routing or behavioral context that would make it more genuinely helpful.
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?
For a tool accepting arbitrary DuckDB SQL over health data, an agent needs to know how to discover available tables and fields IAW health_schema, and what output shape or limits to expect. With no output schema, no annotations, and no mention of health_schema, the description is only minimally viable.
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 the schema already documents the query string and the format enum including the default JSON value. The description adds the 'one analytical query' framing but no additional parameter detail beyond the schema, so the baseline 3 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?
The description uses a specific verb ('Run') and names the resource ('Apple Health data'), with the qualifier 'one analytical query.' It clearly communicates what the tool does, though it does not explicitly distinguish itself from the sibling tools health_report and health_schema.
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?
Usage is implied: use this tool when an analytical query needs to be executed against Apple Health data. However, there is no explicit guidance about when to choose this tool over health_report or health_schema, and no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate structured health reports for a specific period
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | End date for custom reports (YYYY-MM-DD) | |
| start_date | No | Start date for custom reports (YYYY-MM-DD) | |
| report_type | Yes | Type of report to generate | |
| include_metrics | No | Metrics to include (default: all) |
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 only says 'Generate structured health reports' without disclosing whether the operation is read-only, what permissions are needed, what side effects exist, or what the output format is. This is insufficient for a tool with no output schema.
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?
The description is a single sentence with no filler or redundant information. It is front-loaded with the action and object, making it easy to scan.
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?
Given there is no output schema and no annotations, the description is too minimal to provide complete context. It does not specify what a health report contains, how it is structured, or any edge-case behavior. The presence of sibling tools and moderate parameter count (4) calls for more explanatory content.
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 the baseline is 3. The description adds minimal value beyond the schema—it merely echoes the 'specific period' concept already covered by start_date and end_date descriptions. It does not explain report_type enum semantics or include_metrics default behavior.
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?
The description states a specific action ('Generate') and resource ('structured health reports') with a scope ('for a specific period'). It is clear what the tool does, though it does not explicitly distinguish itself from sibling tools like health_query or health_schema beyond the word 'report'.
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?
Usage context is implied by the description: it generates reports for a period. However, there is no explicit guidance on when to use this tool versus siblings, nor any alternative or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about available health data tables, their structure, and sample data to help write SQL queries
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read-only, informational operation ('Get information'), which is consistent with a schema tool. However, it does not disclose any behavioral details such as data source, freshness, or access restrictions beyond the basic read-only implication.
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?
The description is a single, concise sentence that front-loads the action ('Get information') and immediately specifies the resource and purpose. Every phrase adds value with no redundancy.
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?
For a simple, parameterless tool, the description is largely complete. It specifies what the tool returns (table structures and sample data) and why it is useful (writing SQL queries). Without an output schema, this baseline description suffices.
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 input schema is empty with zero parameters, so there are no parameter semantics to explain. Per the baseline for 0-parameter tools, this scores 4.
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?
The description clearly states the tool's purpose: 'Get information about available health data tables, their structure, and sample data.' It uses a specific verb ('get') and a specific resource, and the context of sibling tools (health_query, health_report) makes it distinct as the metadata/schema exploration tool.
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 implies usage before writing SQL queries ('to help write SQL queries'), but it does not explicitly state when to use this tool versus health_query or health_report, nor does it mention any exclusions or alternatives.
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.
v1.4.5health_query1 field changedInput schema / properties / query / descriptionPrevious value: -"SQL SELECT query to execute"New value: +"One DuckDB analytical query. Joins, CTEs, subqueries, set operations, and window functions are supported."v0.1.0health_queryhealth_reporthealth_schemaScored across 3 tools
Each tool serves a clearly distinct purpose: health_query runs analytical queries, health_report generates reports, and health_schema provides metadata about tables. There is no overlap in functionality.
All tools follow a consistent pattern with the prefix 'health_' followed by a clear noun (query, report, schema). Naming is uniform and predictable.
With only 3 tools, the set is compact but well-scoped for the stated analytical purpose. While slightly minimal, each tool earns its place and doesn't feel overly sparse.
The tools cover the essential analytical workflow: querying data, generating reports, and understanding schema. Minor gaps exist (e.g., no direct data export), but for the apparent read-only analytical scope, coverage is sufficient.
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
GibsonAI MCP server: manage your databases with natural language
Text-to-SQL MCP server: read-only queries on PostgreSQL, MySQL and SQL Server with your real schema
