Provides tools to query personal health data stored in a SQLite database, allowing AI agents to perform aggregated health summaries and execute raw SQL queries for detailed data analysis.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Wellness Planner Generate an energy-aware schedule for my tasks today."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local MCP agent that queries personal health data and provides energy-aware task scheduling.
This project uses simulated data. Health data is seeded from data/seed_db.py into a SQLite database. There is no Apple Health integration — real health data is not imported or synced.
Related MCP server: Productivity Tracker MCP Server
Python 3.14+
uv for dependency management
Run the Plan-and-Execute agent loop locally:
uv run python mcp_server/agent.py [YYYY-MM-DD]Uses yesterday's date if no date is given.
Reads from data/health.db and data/todo.json.
Prints a daily brief: sleep, activity, heart rate, readiness score, and proposed schedule.
The MCP server is spawned by Cursor when needed — you do not start it manually in a separate terminal.
Configure Cursor to use the local MCP server (e.g. .cursor/mcp.json):
{
"mcpServers": {
"wellness-planner": {
"command": "uv",
"args": ["run", "--directory", "/path/to/wellness_planner", "python", "mcp_server/server.py"]
}
}
}Replace /path/to/wellness_planner with your actual project path.
Cursor will spawn the server and communicate over stdio.
Command | Purpose |
| Placeholder entry point |
| Seed |
When the server is connected, these tools are available:
get_health_summary — Aggregated sleep, activity, and heart rate for a date
calculate_readiness_score — 1–10 readiness score for task timing
query_raw_logs — Run read-only SQL against the health DB
get_tasks — Load tasks from todo.json
propose_schedule — Energy-aware schedule based on readiness and tasks
get_data_dictionary — Schema introspection: column names, types, and sample values
run_analysis — Execute a pandas/sqlite analysis script locally; returns stdout
generate_chart — Produce a self-contained Observable Plot HTML chart
get_insights — Retrieve previously saved findings from the Fact Store
save_insight — Persist a discovered insight so it isn't re-computed next session
There are two layers to test: the skills directly, and the MCP tools through Cursor chat.
Phase 1 — Sandbox execution:
uv run python -c "
from skills.sandbox import run_python_analysis
r = run_python_analysis('''
df = pd.read_sql('SELECT date, total_hours FROM sleep_logs ORDER BY date DESC LIMIT 7', __import__('sqlite3').connect(DB_PATH))
print(df.to_string(index=False))
''')
print(r['output'])
"Phase 2 — Schema discovery:
uv run python -c "
from skills.schema import get_data_dictionary
import json
print(json.dumps(get_data_dictionary(), indent=2))
"Phase 3 — Chart generation:
uv run python -c "
import sqlite3
from skills.visualization import generate_chart
rows = sqlite3.connect('data/health.db').execute('SELECT date, total_hours FROM sleep_logs ORDER BY date').fetchall()
r = generate_chart([{'date': r[0], 'total_hours': r[1]} for r in rows], 'Sleep Trend', 'date', 'total_hours')
print(r)
"Then open the url value in a browser to see the chart.
Phase 4 — Fact Store:
uv run python -c "
from skills.memory import save_insight, get_insights, clear_insights
save_insight('test_key', 'test value', 'manual test')
print(get_insights())
clear_insights()
"Ask the agent questions in chat and watch the MCP tool calls fire in sequence:
Schema discovery: "What tables and columns are in the health database?"
Analysis: "What's the correlation between my step count and sleep quality over the last 30 days?"
Should trigger: get_insights → get_data_dictionary → run_analysis → save_insight
Chart: "Show me my resting heart rate trend as a chart."
Should trigger: run_analysis → generate_chart → returns a file path
Memory: "What do you already know about my health patterns?"
Should trigger: get_insights and return stored findings without re-running anything
uv run python mcp_server/agent.py 2026-02-18Tests the non-MCP path (summarizer + readiness + scheduling) and confirms nothing broke during the Phase 1–4 additions.
Calculate a 1-10 readiness score based on sleep quality, resting heart rate, and prior-day exertion. Use this to decide when to schedule demanding tasks.
Args: target_date: ISO date string (YYYY-MM-DD). Defaults to today.
| Name | Required | Description | Default |
|---|---|---|---|
| target_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adequately describes what the tool does (calculates a readiness score) and its practical application, but doesn't disclose important behavioral aspects like how the calculation algorithm works, what happens with missing data, whether the score is cached or real-time, or what format the output takes. The description doesn't contradict any annotations since none exist.
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 perfectly structured and concise - the first sentence clearly states the tool's purpose and practical application, while the Args section efficiently documents the single parameter with format and default information. Every sentence earns its place with no wasted words.
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 the tool's moderate complexity (calculating a readiness score from multiple factors) and the absence of both annotations and output schema, the description is adequate but has gaps. It explains what the tool does and its practical application, but doesn't describe the output format (just mentions it returns a 1-10 score) or address edge cases like missing data. For a calculation tool with no structured output documentation, more detail would be helpful.
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 description adds significant value beyond the input schema, which has 0% description coverage. It explains that target_date is an 'ISO date string (YYYY-MM-DD)' and 'Defaults to today,' providing format details and default behavior that aren't in the schema. Since there's only one parameter and the description covers it well, this earns a high score despite the schema's poor coverage.
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 with specific verb ('calculate') and resource ('readiness score'), and explicitly lists the three input factors (sleep quality, resting heart rate, prior-day exertion). It distinguishes this from sibling tools like get_health_summary or propose_schedule by focusing specifically on readiness scoring rather than general health data or scheduling.
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 provides explicit guidance on when to use this tool ('to decide when to schedule demanding tasks') and distinguishes it from alternatives by focusing on readiness scoring rather than raw data retrieval (query_raw_logs), task management (get_tasks), or scheduling generation (propose_schedule). The practical application context is clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an aggregated health summary (sleep, activity, heart rate) for a date.
Args: target_date: ISO date string (YYYY-MM-DD). Defaults to today.
| Name | Required | Description | Default |
|---|---|---|---|
| target_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves aggregated data but doesn't cover critical aspects like authentication requirements, rate limits, error handling, or what happens if no data exists for the date. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 appropriately sized and front-loaded. The first sentence clearly states the purpose, and the 'Args' section efficiently explains the parameter without redundancy. Every sentence earns its place, and there's no wasted text, making it easy for an agent to parse quickly.
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 the tool's moderate complexity (single parameter, read operation) and lack of annotations or output schema, the description is minimally adequate. It covers the purpose and parameter semantics but misses behavioral details like response format, error cases, or integration with siblings. For a health data tool, more context on data aggregation or limitations would improve completeness.
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 description adds meaningful context beyond the input schema. The schema has 0% description coverage and only lists 'target_date' as a string/null with a default. The description clarifies that it's an 'ISO date string (YYYY-MM-DD)' and 'Defaults to today,' providing essential format and default behavior that the schema lacks. With one parameter and low schema coverage, this compensates well.
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 an aggregated health summary (sleep, activity, heart rate) for a date.' It specifies the verb ('Get'), resource ('health summary'), and scope ('for a date'), though it doesn't explicitly differentiate from sibling tools like 'calculate_readiness_score' or 'query_raw_logs'. The purpose is specific and actionable.
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 provides no guidance on when to use this tool versus alternatives. It mentions the tool fetches aggregated health data but doesn't compare it to siblings like 'calculate_readiness_score' (which might compute a score) or 'query_raw_logs' (which might provide raw data). There's no mention of prerequisites, exclusions, or contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current task list from todo.json. Each task has an energy_required level (high/medium/low) and preferred_time slot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that tasks include 'energy_required level (high/medium/low) and preferred_time slot,' which adds some context about the data structure. However, it doesn't describe critical behaviors like whether this is a read-only operation, potential errors, or how the data is sourced (e.g., real-time vs. cached). For a tool with zero annotation coverage, this is insufficient.
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 highly concise and front-loaded: the first sentence states the core purpose, and the second adds useful details about task attributes. Every sentence earns its place by providing essential information without redundancy or fluff.
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 the tool's low complexity (0 parameters, output schema exists), the description is somewhat complete but has gaps. It explains what the tool returns and the structure of tasks, which is helpful. However, with no annotations and an output schema present, it could benefit from more behavioral context (e.g., read-only nature, error handling). It's adequate but not fully comprehensive.
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 has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately avoids mentioning any. This meets the baseline for tools with no parameters, as it doesn't mislead or omit necessary information.
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: 'Return the current task list from todo.json' specifies the verb (return) and resource (task list from a specific file). It distinguishes from siblings by focusing on tasks rather than readiness scores, health summaries, schedules, or logs. However, it doesn't explicitly contrast with sibling tools, keeping it from a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer get_tasks over other sibling tools like get_health_summary or propose_schedule, nor does it specify prerequisites or contextual triggers. Usage is implied only by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose an energy-aware daily schedule based on today's readiness score and the task list. High-energy tasks are placed when readiness supports them.
Args: target_date: ISO date string (YYYY-MM-DD). Defaults to today.
| Name | Required | Description | Default |
|---|---|---|---|
| target_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the scheduling logic (energy-aware, placing high-energy tasks when readiness supports them), which adds useful context beyond basic functionality. However, it lacks details on critical behaviors: it doesn't specify what 'readiness score' means, how tasks are prioritized, whether the schedule is saved or tentative, or what the output format is. For a tool with no annotations and no output schema, this leaves significant gaps in understanding its operation.
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 appropriately sized and front-loaded: the first sentence clearly states the purpose, and the second adds key behavioral context. The Args section is concise and adds necessary parameter details without redundancy. Every sentence earns its place, with no wasted words or under-specification.
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 the complexity (scheduling based on energy and readiness), no annotations, 0% schema coverage, and no output schema, the description is partially complete. It explains the core logic and parameter default, but it doesn't cover the output format, how 'readiness score' and 'task list' are obtained or structured, or error conditions. This leaves the agent with gaps in understanding how to invoke and interpret results, though it's adequate for basic usage.
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 description adds meaningful semantics beyond the input schema. The schema has 1 parameter with 0% description coverage, only listing 'target_date' as an ISO date string with a default. The description compensates by explaining that 'target_date' defaults to today and that the schedule is based on 'today's readiness score and the task list,' clarifying the temporal context and implied dependencies. However, it doesn't detail the format or constraints of 'readiness score' or 'task list,' which are not in the schema but are critical inputs.
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: 'Propose an energy-aware daily schedule based on today's readiness score and the task list. High-energy tasks are placed when readiness supports them.' This specifies the verb (propose), resource (daily schedule), and key inputs (readiness score, task list). It distinguishes from siblings like 'calculate_readiness_score' or 'get_tasks' by focusing on scheduling rather than calculation or retrieval. However, it doesn't explicitly contrast with all siblings (e.g., 'get_health_summary' might overlap in energy context).
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 context: it should be used when you have a readiness score and task list to create an optimized schedule. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., whether to use 'calculate_readiness_score' first or how it differs from manual scheduling). No exclusions or prerequisites are mentioned, leaving some ambiguity about the required inputs beyond the parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a read-only SQL query against the health database.
Available tables:
sleep_logs (date, bedtime, wake_time, total_hours, deep_sleep_hours, rem_sleep_hours, awakenings)
activity_logs (date, steps, active_minutes, calories_burned, workouts)
heart_rate_logs (date, timestamp, bpm)
Args: query: A SELECT SQL query. Only read operations are allowed.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool is 'read-only' and specifies 'Only read operations are allowed,' which covers safety and permissions. It also lists available tables, providing context about what data can be accessed. However, it lacks details on rate limits, error handling, or response format, preventing a perfect score.
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 appropriately sized and front-loaded, starting with the core purpose, followed by available tables and parameter details. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
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 the tool's complexity (SQL querying with multiple tables), no annotations, and an output schema present (which handles return values), the description is largely complete. It covers purpose, usage, behavioral constraints, and parameter semantics. However, it could benefit from mentioning query limitations (e.g., timeouts, result size) or authentication needs, slightly reducing completeness.
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 schema description coverage is 0%, so the description must fully compensate. It explicitly defines the single parameter 'query' as 'A SELECT SQL query' and adds critical constraints ('Only read operations are allowed'), providing essential semantic meaning beyond the bare schema. This fully addresses the parameter's purpose and usage.
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 specific action ('Run a read-only SQL query') and target resource ('against the health database'), distinguishing it from sibling tools that perform calculations, summaries, task management, or scheduling. It precisely defines the tool's function without being vague or tautological.
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 provides clear context for when to use this tool (for SQL queries on health data) and implicitly suggests alternatives by listing available tables, but it does not explicitly state when not to use it or name specific sibling tools as alternatives. This gives good guidance but falls short of the highest score.
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. Dates show when Glama detected each change.
v0.1.0calculate_readiness_scoreget_health_summaryget_taskspropose_schedulequery_raw_logsEach tool has a clearly distinct purpose with no overlap: calculate_readiness_score computes a score, get_health_summary aggregates data, get_tasks retrieves tasks, propose_schedule creates a schedule, and query_raw_logs runs SQL queries. The descriptions make it easy to differentiate them, preventing misselection.
The naming is mostly consistent with a verb_noun pattern (e.g., calculate_readiness_score, get_health_summary, get_tasks, propose_schedule), but query_raw_logs deviates slightly by using 'query' as a verb instead of a more standard action like 'get' or 'fetch'. However, the pattern is still readable and coherent overall.
With 5 tools, the server is well-scoped for a wellness planner domain. Each tool serves a specific function in the workflow—from data retrieval and calculation to scheduling and querying—without being too sparse or bloated, making it efficient for agents to use.
The tool set covers core wellness planning operations: calculating readiness, summarizing health data, managing tasks, proposing schedules, and querying raw logs. A minor gap is the lack of tools for updating or modifying tasks or health data (e.g., add_task, update_health_log), but agents can work around this using the existing tools for read and propose operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
ADHD system of record for agents: tasks, goals, loops, calendar, focus stats.
AI life manager: tasks, home, health, wealth, childcare, pets & more — on your own data.
Deterministic fitness coaching engine: adaptive programs, progression math, readiness autoregulation
Track, curate, and analyze data about your health, habits, and goals.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rwking/wellness_planner'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
