Health4AI

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Most tools have distinct purposes like comparing periods, getting daily snapshots, and querying metrics. However, 'get_health_summary' and 'get_daily_snapshot' overlap somewhat in content, and 'get_hrv_trend' is redundant with 'query_metric' for HRV, causing minor ambiguity.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern in snake_case, with most using 'get_' prefix. 'compare_periods', 'query_metric', and 'search_records' deviate from the 'get_' pattern but still maintain clear verb-first naming, resulting in only minor inconsistency.
Tool Count5/5
11 tools is well-scoped for a health analytics server, covering diverse needs like trend analysis, comparisons, summaries, and searches without being excessive.
Completeness4/5
The tool set provides comprehensive read-only access to health metrics including trend, comparison, stats, and search. Missing write operations (create/update/delete) are acceptable for an analytics-focused server, but there is no correlation or export tool, which could be useful.
Average 3.9/5 across 11 of 11 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 67 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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?
With no annotations, the description carries full burden. It does not disclose behaviors like authentication needs, rate limits, or whether it only returns a subset of data (e.g., pagination via limit). It only states what fields are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but too brief for a tool with two optional parameters. It could add a second sentence explaining parameters without costing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. However, with 0% parameter documentation and no usage guidance, it is incomplete for a tool that has configurable defaults and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description contains no explanation of the two parameters (days and limit). The defaults are in the schema but not mentioned, leaving the agent uninformed about controlling the recency or number of results.
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 returns recent workouts with specific fields (type, duration, distance, calories). It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like compare_periods or get_daily_snapshot, though the focus on workouts is distinct.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context such as that it only returns recent data (default 30 days) or any limitations.
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, the description effectively discloses key behaviors: windows <=30 days return raw samples, longer windows return daily aggregates, and raw samples beyond 30 days are summarized. Adds value beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise (4 lines) with clear structure: purpose statement, examples, then behavioral rules. No fluff, but could be more structured with bullet points.
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?
Covers the main behavioral aspect (window vs aggregation) but partially explains parameters (missing limit). Given it has an output schema, return values need not be detailed, but the tool is fairly simple and the description is sufficient but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains 'metric_type' with examples and implies 'days' controls window length, but does not explain 'limit'. Some added meaning, but not fully comprehensive.
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?
Clearly states the tool retrieves time-series for any HealthKit metric type with examples, but does not explicitly differentiate itself from sibling tools like compare_periods or get_daily_snapshot.
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?
No guidance on when to use this tool versus alternatives (e.g., get_daily_snapshot for single-day aggregation, compare_periods for comparisons). The description only provides behavioral details about window sizes.
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, the description carries the full burden. It mentions default behavior and return metrics but lacks disclosure on safety (read-only), error handling (e.g., missing data), or authentication requirements.
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?
Two concise sentences front-load key information (date format, default, returned metrics) 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?
The output schema exists, so return values are covered. However, with no annotations and moderate sibling count, the description should address behavioral context more thoroughly, such as read-only nature or data availability.
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% coverage, but the description adds format (YYYY-MM-DD) and default behavior. This compensates well for the single parameter, though it could clarify optionality explicitly.
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 retrieves all metrics for a specific date, listing examples like steps, sleep, and HRV, which distinguishes it from more specific sibling tools like get_sleep or get_workouts.
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 use for a full daily summary and notes the default to today, but does not explicitly guide when to use alternatives like get_sleep or get_hrv_trend for specific metrics.
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 takes the full burden. It lists what metrics are returned but does not disclose behavior for missing data, edge cases, or whether the operation is read-only (though implied). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and directly states the purpose and returned metrics. It is concise but could be structured slightly better (e.g., listing metrics in a clearer format).
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 existence of an output schema (not shown), the description sufficiently covers the return values. It also differentiates from the many sibling tools. However, it could mention use cases or limitations for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the 'days' parameter. It indicates 'past N days', which adds context beyond the schema, but lacks details like inclusivity or date range formatting. Baseline 3 is appropriate.
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 it returns an overview of key health metrics (avg steps, sleep, HRV, resting HR, workout count) for the past N days. This distinguishes it from sibling tools that focus on individual metrics or comparisons.
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 for getting a broad summary, but does not explicitly state when to use this vs alternatives like get_sleep or get_workouts. No 'when not to use' guidance is provided.
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?
No annotations are provided, so the description carries the burden. It discloses the data returned and the tier-aware behavior for windows beyond 30 days. However, it does not mention auth requirements, rate limits, or potential side effects, leaving some behavioral aspects unclear.
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?
Three sentences, each serving a distinct purpose: stating the tool's function, listing outputs, and noting a technical detail. No extraneous words, and the most important information is front-loaded.
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 simplicity (1 parameter, output schema exists), the description covers the main aspects: what is returned, the parameter's meaning, and a note on data aggregation for longer windows. It does not repeat return format details since an output schema is present.
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 single parameter 'days' has no schema description (0% coverage). The description adds context by mentioning 'past N days' and 'windows beyond 30 days', helping the agent understand the parameter's effect and the scaling behavior.
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 specifies the verb 'get trend', the resource 'HRV (SDNN)', and the scope 'past N days'. It lists the returned components: daily averages, 7-day rolling comparison, trend direction. This clearly distinguishes it from siblings like get_long_term_trend or query_metric.
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 for HRV trend analysis but does not explicitly state when to use this tool versus alternatives such as get_long_term_trend or get_metric_stats. No when-not-to-use or alternative recommendations are provided.
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?
No annotations are provided, so the description must disclose behavioral traits. It states the tool returns sleep data and stage durations, which is clear, but it does not mention permissions, rate limits, or data availability constraints.
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?
Two sentences efficiently convey the tool's purpose and output. The core information is front-loaded with no wasted words.
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 existence of an output schema (not provided), the description adequately covers the tool's function and main output components. Minor details like max days or edge cases are missing, but it is sufficient for a simple tool.
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 explains the 'days' parameter by mentioning 'past N days', which adds meaning beyond the input schema. With only one simple parameter, this is adequate even with 0% schema description 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 provides sleep analysis for the past N days with a per-night breakdown of stage durations (REM, Deep/Core, Light, Awake), which distinguishes it from siblings like get_daily_snapshot or get_health_summary.
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 for retrieving sleep data over a range of days but does not explicitly state when to use this tool versus alternatives like get_daily_snapshot or get_health_summary.
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?
No annotations are provided, so the description bears full responsibility. It notes the date format and states the tool returns per-period stats and a delta, but does not disclose potential side effects, authentication requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with the main purpose first, followed by examples. It is slightly verbose with multiple examples, but each adds value. No unnecessary sentences.
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 has 7 parameters and no schema descriptions, the description adequately covers the inputs. It also mentions the output schema exists, reducing the need to detail return values. Slightly less complete due to missing behavioral details.
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?
Schema coverage is 0% with no parameter descriptions. The description adds significant meaning by explaining each parameter through examples, covering metric_type, date ranges, and labels, thus fully compensating for the lack of schema documentation.
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 compares a health metric between two date ranges, using specific verbs and resources. It distinguishes itself from sibling tools like 'get_metric_stats' and 'query_metric' by focusing on period comparison.
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 relevant examples of when to use the tool (e.g., sleep before/after supplements, month-over-month HRV). However, it does not explicitly exclude alternative tools or give when-not-to-use guidance.
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?
No annotations are provided, so the description must carry the full burden. It explains the tool combines recent trends and returns a structured summary, listing key fields. It does not disclose whether the operation is read-only, nor any side effects, auth requirements, or rate limits. The fact that an output schema exists (unseen here) could supplement, but the description alone is moderately transparent.
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 three sentences long, front-loaded with the purpose, followed by output details and usage guidance. Every sentence adds value without redundancy or fluff, making it highly concise and well-structured.
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 has no parameters and an output schema exists, the description covers its purpose, output content, and usage timing adequately. It lacks details on any prerequisites, data freshness, or personalization scope, but for a pre-session brief, the provided context is largely sufficient.
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 zero parameters, so parameter semantics are not applicable. According to guidelines, baseline score is 4. The description does not need to add parameter info, and it doesn't, which is appropriate.
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 provides a pre-session coaching brief for Brett, combining recent trends across key metrics. It specifies the output includes recovery status, sleep quality, training load, and fitness trajectory, distinguishing it from sibling tools like 'get_daily_snapshot' or 'get_health_summary' by its personalized and coaching-specific focus.
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 explicitly directs calling this tool 'at the start of every coaching session,' providing clear context for when to use it. However, it does not mention when not to use it or compare directly with alternatives, though the sibling tools list implies other options exist.
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?
No annotations provided, so description carries full burden. It explains behavior for cumulative vs. rate metrics and sorting, but lacks details on auth, rate limits, or potential no-match scenarios. Adequate but not comprehensive.
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?
Concise, well-structured: summary, differentiation of metric types, examples, and sorting behavior. Every sentence adds value with no redundancy.
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 5 parameters and threshold-based filtering, description covers key aspects. Output schema exists, so return values are handled. Could include handling of no matches, but overall complete.
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?
Schema description coverage is 0%, so description compensates well. It explains min_value/max_value as thresholds and provides examples for metric_type. Does not fully detail days and limit, but clarifies defaults 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 tool finds days where a health metric crossed a threshold, and distinguishes between cumulative and rate metrics. This is specific and distinct from siblings like get_metric_stats or query_metric.
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?
Provides clear examples of when to use it (e.g., days with HRV below 40ms). Lacks explicit guidance on when not to use it or alternatives, but the context of threshold crossing is well-defined.
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, the description carries full behavioral burden. It discloses the tier-aware merging behavior and the recency gap closure, which is important for understanding the tool's output. It does not mention authorization or side effects, but those are likely minimal for a read operation. The description adds value beyond the bare schema.
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 concise (4 sentences), with the core purpose in the first sentence. Every sentence adds value: purpose, tier-aware behavior, use case, and parameter examples. No wasted words.
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?
The description covers the tool's complexity (merging logic, parameters, usage context). An output schema exists but is not shown; the description does not explain return values, which is acceptable given the schema. Overall, it provides sufficient context for correct tool invocation.
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?
Schema description coverage is 0%, so the description must compensate. It provides examples for metric_type (e.g., HKQuantityTypeIdentifierHeartRateVariabilitySDNN) and explains the months parameter with its default value (24). While it does not give constraints or a full list, the examples help the agent understand acceptable values.
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 provides 'Long-term trend for any metric' and explains the tier-aware merging of recent raw data with historical summaries, which distinguishes it from sibling tools like get_hrv_trend (specific to HRV). The verb 'get' and resource 'long-term trend' are specific and unambiguous.
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 says 'Best for multi-year / seasonal analysis,' which clearly conveys when to use it. It implies a long-term context but does not explicitly mention when not to use or name alternative tools. However, the context is sufficient for an AI agent to infer appropriate usage.
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, the description fully carries the burden. It details the returned statistics, defines the thresholds field in plain English, and explains percentile meanings. However, it does not mention authorization or side effects, which are minimal for a read-only query. The description is transparent about what the tool does and returns.
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 concise and well-structured: first sentence states purpose, then lists output, then usage guidance, then threshold explanation. Every sentence adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not detail return values, but it does so effectively. It explains the thresholds field, suggests a sibling tool, and provides enough context for an agent to use the tool correctly. The description is complete for the tool's 2 parameters and intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must explain parameters. It implicitly covers 'metric_type' via 'any health metric' but does not describe the 'days' parameter despite its default of 90. The description adds value by explaining the thresholds field and percentiles, but fails to fully compensate for the lack of parameter documentation.
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 provides 'personal baseline statistics for any health metric' and lists specific outputs (min, max, mean, etc.). It distinguishes from sibling tools like get_daily_snapshot by explicitly suggesting pairing, making the purpose unambiguous.
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 includes explicit usage guidance: 'Use to answer: Is today's reading good or bad for me personally?' and 'Pair with get_daily_snapshot to compare today's value against your baseline.' This tells the agent exactly when and how to use the tool, with no ambiguity.
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:

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

Score Badge

Copy to your README.md:

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

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/jefflitt1/health4ai'

If you have feedback or need assistance with the MCP directory API, please join our Discord server