使用 SQL 和 DuckDB 从 MCP 客户端查询 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 客户端的查询结果可能会被发送到该客户端配置的模型提供商。
工具 | 用途 |
| 发现表名、列、单位和示例行 |
| 运行只读 |
| 生成每周、每月或自定义健康摘要 |
从 health_schema 开始；表名取决于导出文件中的文件。有关数据模型和工作示例，请参阅 查询 Apple Health 数据。
第一个需要某个表的请求会加载该表的完整 CSV 历史记录。没有日期窗口限制，因此查询可以追溯到导出所涵盖的最早时间。
由于每个工具都可以访问全部已配置的历史记录，因此只能从您信任其处理这些数据的 MCP 客户端启动此服务器。
已加载的表保存在内存中，DuckDB 会获得上述 MAX_MEMORY_MB 限制。大约 1 GiB 可以覆盖两年的多表导出，因此 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
