Wellness Planner

by rwking

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.7/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![wellness_planner MCP server](https://glama.ai/mcp/servers/rwking/wellness_planner/badges/card.svg)](https://glama.ai/mcp/servers/rwking/wellness_planner)

Score Badge

Copy to your README.md:

[![wellness_planner MCP server](https://glama.ai/mcp/servers/rwking/wellness_planner/badges/score.svg)](https://glama.ai/mcp/servers/rwking/wellness_planner)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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