health-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HEALTH_MCP_DB_PATH | No | Path to the SQLite database file. Defaults to ~/health/health.db. | ~/health/health.db |
| HEALTH_MCP_HEVY_API_KEY | No | Hevy API key. Required for sync_workouts / sync. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| add_productA | Add a Product to the Catalog. Macros are per 100g. |
| find_productA | Search the Catalog by name or brand (substring match). Omit |
| log_foodA | Log that |
| delete_food_entryB | Delete a Food Log Entry by id. |
| sync_workoutsA | Pull new training data from Hevy into the database. Call this before answering a
question about recent training — a workout finished after the last sync isn't in the
database until you do. Delta by default and cheap to call. |
| queryA | Read-only SQL against the health database. Must be a single SELECT or WITH statement. Schema: products(id, name, brand, source, kcal_100g, protein_100g, carbs_100g, fat_100g, fibre_100g, sugar_100g, sat_fat_100g, salt_100g, note, created_at) food_log(id, logged_at, date, product_id, name, source, grams, entered_as, kcal, protein, carbs, fat, note) workouts(id, title, start_time, end_time, date, updated_at, raw) exercise_templates(id, title, primary_muscle_group, secondary_muscle_groups, equipment) workout_exercises(id, workout_id, idx, exercise_template_id, title) workout_sets(id, workout_exercise_id, idx, type, weight_kg, reps, rpe, duration_s, distance_m) body_measurements(date, weight_kg, fat_percent) sync_state(source, cursor, last_run_at, last_status, last_error)
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct resource and action: catalog management (add/find product), food logging (log/delete entries), workout synchronization, and generic SQL query. There is no overlap or ambiguity between tool purposes.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (delete_food_entry, add_product, find_product, log_food, sync_workouts, query). The naming is predictable and uniform.
The server has 6 tools, which is well-scoped for a health data management domain. Each tool serves a clear purpose without unnecessary redundancy or overwhelming count.
Core workflows are covered: product catalog creation and search, food logging and deletion, workout sync, and read-only query access. Minor gaps exist (e.g., no update or delete for products, no update for food entries), but these can be worked around via delete/re-log or are not essential for the server's purpose.