whoop-mcp

by d00ennis

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 targets a distinct data category (recovery, sleep, cycles, workouts, body, history) or operation (sync, Life-OS update), with clear descriptions that eliminate ambiguity. The summary tool provides an overarching view but does not overlap with specific metric tools.
Naming Consistency5/5
All tools follow the consistent pattern 'whoop_<descriptive_noun>', with only 'whoop_lifeos_update' using a compound noun, which is still uniform and predictable.
Tool Count5/5
With 9 tools, the set is well-scoped for a health/fitness MCP server, covering essential data retrieval, history, and synchronization without unnecessary bloat.
Completeness4/5
The domain of WHOOP data is well-covered: recovery, sleep, strain, workouts, body metrics, and historical trends are all present. Minor gaps like account info or raw intraday data might be missing, but core user needs are met.
Average 3.2/5 across 9 of 9 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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. It merely lists metrics without disclosing behavioral traits such as data granularity, time range, or response format. With an output schema present, the description fails to clarify what the tool returns or any side effects.
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 concise (a single line), but it lacks structure. It reads as a list rather than a coherent sentence. While not verbose, it could be improved by adding a verb and parameter context.
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 existence of an output schema and multiple sibling tools, the description is incomplete. It does not explain what the output contains or how to distinguish from related tools. The single parameter and list of metrics are insufficient for context.
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?
The input schema has one parameter 'days' with 0% description coverage. The description does not mention this parameter, its purpose, or how it affects results. The description adds no value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists sleep-related metrics (duration, phases, performance, consistency, respiratory rate) but lacks an explicit verb stating what the tool does (e.g., retrieves, gets). This makes it somewhat vague, though the list implies the tool provides sleep data. The purpose is clearer than a tautology but not specific enough to distinguish from siblings like whoop_summary.
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 such as whoop_recovery, whoop_summary, or whoop_cycles. There is no mention of context, prerequisites, or exclusions.
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 provided, so description must convey behavioral traits. It does not explicitly state read-only or any side effects, permissions, or limitations. It only lists output fields.
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?
One sentence listing three data fields. It is efficient but could be more structured. No wasted words, but also no additional context.
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?
Though an output schema exists, the description omits what constitutes a 'cycle' and provides no usage context. The parameter 'days' is crucial but undefined.
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?
Parameter 'days' has no description in schema (0% coverage) and the tool description does not mention it at all. The agent cannot determine its purpose or valid values.
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 lists the data returned (daily strain, calories, heart rate) which implies it retrieves cycle metrics. The name 'whoop_cycles' reinforces this. However, it lacks a direct verb+resource statement like 'get cycles data'.
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 siblings like whoop_recovery or whoop_summary. No when-not or alternative suggestions.
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 must disclose behavioral traits. It only lists return data and does not mention that the tool is read-only, any authentication requirements, rate limits, or data freshness. The lack of behavioral context is a significant gap.
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 a single, short sentence that front-loads the key metrics. It is concise but omits important details like parameter usage and behavioral notes. Every word earns its place, but the brevity comes at the cost of completeness.
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 has an output schema (not shown), the description does not need to explain return structure. However, it does not specify the time range precisely (e.g., 'last few days' is vague) or any prerequisites. For a simple data retrieval tool, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (days, default 7) has no schema description (0% coverage). The description mentions 'der letzten Tage' (recent days) but does not explain that the 'days' parameter controls how many days back to fetch. It adds minimal value beyond the schema.
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 lists the specific metrics (Recovery Score, HRV, resting pulse, SpO2, skin temperature) and implies a retrieval operation for recent days. It distinguishes itself from siblings like whoop_sleep (sleep data) and whoop_workouts (workout data). However, it lacks an explicit verb like 'get' or 'retrieve', which slightly reduces clarity.
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 its siblings (e.g., whoop_summary, whoop_sleep). The description does not mention use cases, prerequisites, or exclusions, leaving the agent to infer context.
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 must convey behavioral traits. It mentions fetching and writing, but omits details on side effects like overwriting data, rate limits, or required permissions. Insufficient for safe invocation.
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?
Two concise sentences, front-loaded with the main purpose. Efficient use of words, though some behavioral details could be added without significant bloat.
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?
Adequately covers basic functionality and default sync behavior, but lacks information on what data types are synced, prerequisites, and conflict handling. Given the output schema exists but is not visible, completeness is moderate.
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?
Describes the default behavior when 'days' is null, adding meaning beyond the schema. However, it does not explain the effect of providing an integer value (e.g., number of days to sync).
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 it fetches WHOOP data and writes to local database and exports, identifying action and resource. However, it does not explicitly distinguish from sibling tools that focus on specific data types.
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?
Provides guidance on using without 'days' to catch up from last sync, but lacks comparison to sibling tools like whoop_recovery, leaving the agent guessing when to prefer this tool over alternatives.
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 must disclose behavioral traits. It covers source (local DB), speed, rate limit, and prerequisite sync, but misses details on permission requirements, whether data is read-only, and what happens without metric. Leave room for improvement.
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 brief (three short sentences) and front-loads the primary purpose. Each sentence adds value, though the structure could be more streamlined.
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 simple two-parameter interface and presence of an output schema, the description reasonably covers the tool's purpose and key functionality. However, it lacks explicit differentiation from sibling tools and full detail on return values, leaving some gaps.
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 0%, so the description must compensate. It gives examples for the metric parameter and implies days via default, but does not explicitly describe the days parameter or its effect. Partial but not 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?
The description states it performs long-term evaluation from a local database rather than the API, and mentions returning a trend comparison when a metric is provided. While it clearly indicates the data source and distinguishes from API-based tools, the exact scope of 'history' is somewhat vague.
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 mentions a prerequisite (prior sync) and performance benefits (fast, no rate limit), but does not explicitly state when to use this tool versus siblings like whoop_recovery or whoop_sleep. Usage context is implied but not fully articulated.
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 provided, so the description bears full burden. It only lists the returned fields (height, weight, max HR) but discloses no behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects.
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?
Single, short German sentence conveying the purpose without any wasted words. Information is front-loaded and efficient.
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 zero parameters and the existence of an output schema (which likely defines return structure), the description adequately covers the tool's purpose and data fields. Slight improvement possible by adding units or time context, but not necessary.
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?
Input schema has no parameters and 100% coverage. With 0 parameters, baseline is 3. The description adds no parameter-level meaning but does list the returned fields, which is acceptable.
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 that the tool retrieves body measurements (height, weight, max heart rate) from WHOOP, using a specific verb (implied get) and resource. It distinguishes from sibling tools which cover different domains like recovery, sleep, workouts, etc.
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?
No explicit guidance on when to use this tool versus alternatives. The distinct resource (body measurements) implies usage when that data is needed, but there is no mention of prerequisites, when not to use, or comparisons with siblings.
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; description discloses backup creation before writing and dry_run behavior, but does not detail permissions, destructiveness, or whether updates are incremental or overwriting.
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?
Three concise sentences in German, front-loaded with the main purpose, followed by constraints and dry_run behavior. No unnecessary 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?
For a simple tool with one parameter and an output schema (signal present), the description covers the key actions, constraints, and safety feature (backup), making it adequately 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?
With only one parameter (dry_run) and 0% schema coverage, the description effectively explains its purpose: 'Mit dry_run werden die Aenderungen nur angezeigt.' This adds value beyond the schema.
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 writes recovery, sleep, and strain into the Life-OS dashboard, distinguishing itself from sibling tools by specifying it only updates Whoop fields and leaves others untouched.
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 mentions what the tool does not affect (Strava activities, weight, nutrition) and dry_run mode, but lacks explicit guidance on when to use this tool versus siblings or when not to use it.
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 full burden. It discloses that the tool returns strain, heart rate zones, distance, and calories, but does not mention data freshness, pagination, or any constraints such as rate limits or data availability. The transparency is adequate but not thorough.
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 purpose, and every sentence adds value. 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 tool has only two optional parameters and an output schema (not shown but exists), the description covers the main output fields and the filter option. Sibling tools are distinct, so the context is sufficient for an agent to understand when to use this tool.
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 add meaning. It explains the 'sport' parameter (filtering by sport type like 'running') but does not explain the 'days' parameter beyond its default value of 14. One of two parameters is partially explained, which is helpful but incomplete.
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 that the tool retrieves workouts with specific metrics (Strain, heart rate zones, distance, calories) and mentions the ability to filter by sport. This distinguishes it from sibling tools that deal with recovery, sleep, cycles, etc.
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 fetching workout data and filtering by sport, but does not provide explicit guidance on when to use this tool versus siblings like whoop_summary or whoop_recovery. No when-not-to-use or alternative suggestions 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?
The description indicates the tool is read-only (provides data) and aggregates averages and trends. With no annotations, it carries the full burden but does not detail any side effects, authorization needs, or limitations. It is adequate but not extensive.
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-loading the core functionality and a use case. 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 one parameter and an existing output schema, the description adequately covers the tool's purpose and use. It mentions the combined metrics (recovery, sleep, strain) and usage context, though it could add more about behavioral aspects.
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 that the output includes per-day data plus averages and trends, implying the 'days' parameter controls the range. It adds meaningful context beyond the schema, which only has a title and default.
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 combined daily overview of recovery, sleep, and strain. It explicitly labels it as the standard tool for weekly summaries, distinguishing it from sibling tools that focus on individual 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 gives a clear usage context: 'The standard tool for questions like 'How was my week?''. This guides the agent to use it for broad overviews, implying sibling tools are for more specific queries. However, it does not explicitly list when not to use it.
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:

[![whoop-mcp MCP server](https://glama.ai/mcp/servers/d00ennis/whoop-mcp/badges/card.svg)](https://glama.ai/mcp/servers/d00ennis/whoop-mcp)

Score Badge

Copy to your README.md:

[![whoop-mcp MCP server](https://glama.ai/mcp/servers/d00ennis/whoop-mcp/badges/score.svg)](https://glama.ai/mcp/servers/d00ennis/whoop-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/d00ennis/whoop-mcp'

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