ultrahuman_mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Each tool targets a specific health metric (recovery, temperature, heart, sleep, activity), but get_health_summary and get_daily_metrics overlap with the specific tools, though descriptions clarify their distinct purposes as summary and raw access.
Naming Consistency5/5
All tools follow a consistent get_<metric> naming pattern, making it easy to predict tool names and purposes.
Tool Count5/5
Seven tools is well-scoped for a health data server, covering the major health domains without unnecessary redundancy.
Completeness4/5
The tool set covers key health metrics (recovery, temperature, heart, sleep, activity) and provides both summary and raw data access. Minor gaps include lack of historical trend queries beyond recent minutes, but core read-only health tracking is well covered.
Average 3.9/5 across 7 of 7 tools scored. Lowest: 3.3/5.
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 does not mention whether the operation is read-only, how defaults are handled, what timezone applies, or any other behavioral traits beyond listing data fields. The 'Use last_minutes' hint is the only behavioral note, leaving significant gaps.
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, using only two sentences. It is front-loaded with the primary purpose, and every sentence adds value. It avoids redundancy with the schema while providing necessary context.
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 lack of an output schema, the description does list key return metrics, which is helpful. However, it does not explain how time filters interact, whether the returned data is aggregated, or what the default behavior is for missing parameters. The description is adequate but not fully complete for a tool with four optional parameters and no output schema.
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 coverage is 100%, so the baseline is 3. The description adds a small tip about last_minutes but does not contribute additional meaning to date, start_time, or end_time beyond their schema descriptions. This meets the minimum viable level without exceeding it.
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 function: retrieving activity and movement data, listing specific metrics like step count, active minutes, VO2 max, and activity level classification. This distinguishes it from sibling tools such as get_recovery_score or get_temperature_data, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not indicate when to use this tool versus alternatives, nor does it specify exclusions or prerequisites. The only guidance is a note to use last_minutes for recent data, which is a parameter tip rather than tool-selection 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?
With no annotations, the description carries the full burden. It discloses that the tool returns a summary and quality indicator, implying a read-only operation. However, it does not mention potential absence of data, date range limitations, or any safety/privacy considerations. The return format is partially specified.
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 compact: two sentences covering the data fields and the quality indicator. Each listed item adds meaning, though the first sentence is a bit dense with list-like structure. Efficient overall.
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?
For a simple read tool with one optional param and no output schema, the description lists the key return fields and quality categories. It does not specify exact output format or edge cases, but for a sleep analysis tool, it provides sufficient context. Minor gaps exist in describing error behavior or data availability.
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 100%, with the single 'date' parameter fully described (format and default). The tool description adds high-level context about the data returned but does not elaborate on parameter behavior beyond what the schema already states. 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 uses a specific verb 'Get' and clearly identifies the resource as 'sleep data', listing concrete data elements (sleep score, duration, efficiency, stages, cycles, quality). This distinguishes it from sibling tools focused on recovery, temperature, metrics, summary, heart vitals, and activity.
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 when sleep analysis is needed, but provides no explicit guidance on when to prefer this over sibling tools like get_daily_metrics or get_health_summary. No exclusions or alternative recommendations are given.
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. It discloses that the tool returns 'complete unprocessed response' and 'ALL raw health metrics,' which is key behavioral context. However, it doesn't mention potential large response size, rate limits, or error behavior, leaving some gaps.
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 two concise sentences. The first states the purpose and scope, the second gives usage guidance. No redundant words, front-loaded with the core action, and every sentence earns its place.
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?
For a simple retrieval tool with three optional parameters and no output schema, the description is reasonably complete but leaves ambiguity about what 'raw health metrics' actually includes. It also doesn't explain how the date parameters interact (single date vs range), though the schema covers their formats.
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 input schema already provides full coverage (100%) with clear descriptions for date, end_date, and start_date. The description adds no extra parameter semantics beyond hinting at raw data retrieval, so baseline 3 is appropriate since the schema does the heavy lifting.
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 verb 'Get' and resource 'ALL raw health metrics from the Ultrahuman API,' making the purpose specific. It also distinguishes from sibling tools by emphasizing the 'complete unprocessed response' and directing use to cases where other tools don't expose the needed data.
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 says 'Use this only when you need access to data not exposed by other tools,' which gives clear when-to-use guidance and implies alternatives (other specific tools). It lacks explicit when-not-to-use examples but the 'only when' phrasing covers the main exclusion.
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 burden of disclosing behavior. It lists the return values and mentions AI-generated insights, which adds some transparency. However, it does not explain how the parameters (date, time filters) affect the summary, nor does it mention any access requirements, data freshness, or limitations. A score of 3 is appropriate because it gives a general sense but lacks finer behavioral details.
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 two sentences, front-loaded with the core function 'Get a comprehensive health overview.' Every phrase adds value—listing key outputs and positioning it as the best quick-overview tool. There is no unnecessary fluff or repetition.
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 moderate complexity and the absence of an output schema, the description does well by enumerating the return elements and indicating breadth. It also hints at use cases relative to siblings. It does not describe parameter interactions, but the schema handles those details. The description is complete enough for most users, so a 4 is warranted.
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 input schema has 100% description coverage for all four parameters, so the description does not need to add much. The description adds no additional meaning beyond what the schema already provides, such as how filters combine or affect the summary. Per the rubric, baseline is 3 when schema coverage is high, and the description does not exceed that baseline.
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 'comprehensive health overview' with a specific list of outputs (sleep score, recovery score, activity score, vital signs, AI insights). This distinguishes it from sibling tools like get_recovery_score or get_activity_data, which are specialized. The phrase 'best tool for getting a quick understanding of overall health status' reinforces its primary purpose.
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 implies usage context: use this tool for a broad health summary rather than a specific metric. It states it is 'the best tool' for an overall status, which serves as a recommendation. However, it does not explicitly mention alternatives or when to use sibling tools, so it falls just short of a 5.
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 the full responsibility. It describes the metrics returned and implies a read-only 'get' operation, but it doesn't disclose response format, timezone handling, or potential errors. This is adequate for a simple read tool but lacks depth.
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 two concise sentences with no fluff. It front-loads the core purpose and ends with a practical hint. Every word contributes value.
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 absence of an output schema and annotations, the description covers the main metrics and typical use case well. It doesn't explain return field names or edge cases, but for a straightforward temperature data tool, it's substantially complete.
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?
All four parameters are already documented in the schema with clear descriptions (100% coverage). The description adds only a redundant tip about last_minutes, which does not meaningfully exceed what the schema already states. 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 the tool retrieves body temperature metrics, specifically naming skin temperature, deviation from baseline, and average body temperature. This is a specific verb+resource that distinguishes it from sibling health tools like heart vitals or sleep analysis.
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 context for when to use the tool ('useful for detecting illness or stress') and gives specific parameter guidance ('Use last_minutes to get recent temperature data'). It does not mention alternatives or exclusions, but the use case is sufficiently clear.
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 the full burden. It discloses the output format and intended use, but does not mention authentication, rate limits, or explicitly state that it is a safe read operation. The verb 'get' implies read-only, but more detail could be added.
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 two sentences long, front-loaded with the action, and contains no filler. Every sentence contributes value: what it does, what it returns, and when to use it.
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?
The tool is simple with one optional parameter and no output schema. The description fully covers the purpose, return values, and usage context, making it self-sufficient for an agent to select and invoke the tool correctly.
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 fully describes the 'date' parameter with defaults and format, achieving 100% coverage. The description does not add extra parameter-level meaning beyond what the schema already provides, so the baseline score of 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 the tool retrieves recovery metrics, specifically a score (0-100) and a status classification. This distinguishes it from sibling tools focused on temperature, heart, sleep, activity, and general health metrics.
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 says 'Use this to determine if the body is ready for intense activity,' providing a clear use case. It does not mention alternatives or exclusions, so it falls short of a 5, but the context is unambiguous.
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 transparency burden. It discloses behavior such as the default summary format (avg, min, max, trend, resting HR) and the availability of detailed timestamps. It does not mention rate limits or error scenarios, but adds meaningful behavioral context beyond the 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 and well-structured: three sentences that front-load the purpose, then provide usage details. Every sentence contributes useful information without redundancy or unnecessary elaboration.
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 tool has five parameters and no output schema, so the description needs to explain return values and parameter usage. It covers summary vs. detailed and last_minutes, but omits guidance on start_time, end_time, and date parameters, which could leave the agent uncertain about how to choose between time filters. Adequate but with clear gaps.
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 coverage is 100%, so the baseline is 3. The description adds value by explaining the default format, listing summary metrics, and giving a concrete example for last_minutes. This enhances understanding beyond the raw schema definitions.
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 function with a specific verb and resource: 'Get heart-related metrics including heart rate, HRV, and SpO2.' This distinguishes it from sibling tools focused on other health data like temperature or sleep. The scope is 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 gives clear context on how to use the tool, including default summary output, the detailed format option, and last_minutes filtering. It does not explicitly mention alternatives or exclusions, but the heart-specific focus implies when this tool should be used relative to siblings.
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:

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

Score Badge

Copy to your README.md:

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

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/crixalis17/ultrahuman_mcp'

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