whoop-mcp-server

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation5/5
Each tool targets a distinct Whoop data domain: profile, body measurements, recovery, sleep, workouts, cycles, and a combined health overview. The health overview is clearly complementary rather than overlapping, and the parameterized filters on date/limit further distinguish the data-retrieval tools.
Naming Consistency5/5
All tools follow the exact same 'whoop_get_<resource>' pattern, with clear and consistent resource names. This uniform verb_noun structure makes it easy to predict tool behavior and select the right one.
Tool Count5/5
Seven tools is well-scoped for a Whoop data retrieval server. Each tool covers a meaningful health data category without redundancy, and the count feels appropriately balanced—not too sparse, not overwhelming.
Completeness5/5
The tool set provides comprehensive read coverage of Whoop's main health data types: profile, body metrics, recovery, sleep, workouts, daily cycles, and a combined overview. Since the server's purpose is data retrieval, the absence of write operations is not a gap; all core data categories are represented, and the health overview tool nicely ties everything together.
Average 4.2/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about returned data fields (e.g., sleep stages, respiratory rate), but does not disclose potential behavioral nuances like pagination behavior, rate limits, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose sentence, labeled parameter list, and return-field bullets. It is slightly verbose but every section earns its place, and the formatting aids scannability.
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 tool has no output schema, so the description compensates by detailing expected return fields and parameter behavior. It covers key aspects for invocation, though it omits minor details like sorting order or error handling, which are not critical for this simple read-only 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 100%, with each parameter already described in the schema. The description adds slight clarification (e.g., 'Filter sleeps after this date' vs 'End date filter') but does not significantly add beyond the schema. Baseline of 3 is appropriate given the schema carries the full parameter meaning.
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 detailed sleep data from Whoop, listing specific fields like sleep stages, performance, and respiratory rate. This distinguishes it from sibling tools focused on other data types (workouts, recovery, etc.) with a specific verb and resource.
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 (use when you need sleep data) but does not explicitly mention when not to use it or alternatives among sibling tools. It provides no exclusionary guidance or comparison to other Whoop endpoints, leaving the agent to infer appropriateness.
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?
Annotations already cover the read-only, idempotent, non-destructive nature, so the description adds value by specifying exactly what fields are returned (recovery_score, hrv_rmssd_milli, etc.) and how to interpret recovery scores. This goes beyond the structured annotations by providing semantic meaning of the data, though it omits details like timezone handling or pagination beyond the limit parameter.
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 well-structured with clear sections for the main purpose, recovery score interpretation, parameters, and return fields. It is longer than necessary because the parameter list echoes the schema, but the bullet point format and front-loaded summary make it easy to scan. Every section contributes to understanding the tool's output and usage, so there is no wasted content.
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?
With no output schema, the description appropriately explains return values and even provides interpretation guidance for recovery scores. All three parameters are documented, and the response fields are enumerated with units. The only missing completeness element is explicit alternative tool recommendations, but for a read-only data retrieval tool, the description gives sufficient information for an agent to invoke it 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?
Schema coverage is 100%, so the baseline is 3. The description's parameters section largely repeats the schema's descriptions, but it adds slightly more semantic clarity by stating 'Filter recoveries after this date' for start and 'before this date' for end, which is more explicit than the schema's generic 'Start date filter' and 'End date filter'. This is a minor enhancement, not a significant compensation gap.
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 data from Whoop' and lists specific metrics (recovery score, HRV, resting heart rate, SpO2). This specific verb+resource combination distinguishes it from sibling tools like whoop_get_sleep and whoop_get_workouts, which focus on other 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?
The description implies usage by explaining the recovery score bands (Green/Yellow/Red) and how they relate to strain readiness, but it does not explicitly say when to use this tool over others or provide exclusion criteria. There is no mention of alternatives like whoop_get_health_overview for broader health metrics, so usage context is only implied, not fully articulated.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: the physiological-day definition, the 0-21 strain scale interpretation, and the expected return fields. This goes beyond the annotations to help the agent understand data semantics, though it omits details like pagination 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 well-structured with a concise main statement, a clarifying definition, a strain scale breakdown, and bullet lists for parameters and return fields. It contains substantial useful detail without fluff, though it is longer than minimal; the organized sections earn their place for readability.
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?
With no output schema, the description fully compensates by explicitly listing return fields (strain, kilojoule, average/max_heart_rate). It also covers the conceptual cycle definition, parameter ranges, and the strain scale, making it self-contained for a read-only tool with strong annotations. This is a complete, well-rounded description.
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% for all three parameters (limit, start, end). The description essentially repeats the same parameter semantics (limit 1-25 default 7; ISO 8601 filters) without adding new meaning beyond the schema. It does list return fields, which indirectly clarifies parameter effects, but the baseline of 3 applies.
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 opens with a specific verb ('Retrieves') and names the resource ('physiological cycle (day) data' including daily strain, calories, and heart rate). It clearly distinguishes from sibling tools by focusing on daily cycles and strain, and explicitly clarifies that a cycle is wake-to-wake, not a calendar day.
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 daily strain and cycle data with detailed semantics (cycle definition, strain scale), but it does not explicitly mention when to use this tool versus siblings like whoop_get_recovery or whoop_get_sleep. There are no exclusions or alternative tool references, leaving usage guidance only implicit.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read operation. The description adds valuable behavioral context by explaining the strain scale (0-21) and enumerating return fields, going beyond the schema and annotations.
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 well-structured and front-loaded: it opens with the purpose, then the strain scale, then parameters, then return fields. Every sentence contributes useful information without redundancy or fluff.
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?
With no output schema, the description compensates by listing return fields and explaining strain interpretation. It omits details like pagination or error handling, but these are not critical for this simple read-only tool, making it sufficiently 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?
The input schema fully describes all three parameters with details (limit range/default, start/end ISO format). The description repeats this information without adding new semantic nuances beyond a minor clarification of filter direction. With 100% schema coverage, the baseline 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 workout data including specific fields (strain, heart rate zones, calories, distance), using a specific verb and resource. It distinguishes from sibling tools like whoop_get_recovery or whoop_get_sleep through the workout-specific content.
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 implicitly conveys when to use the tool by listing workout-specific fields and the strain scale, making it appropriate for workout data retrieval. It does not explicitly mention alternatives, but the context and sibling tool names provide enough differentiation.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the returned field names and authentication context, but no additional behavioral traits like rate limits or pagination. This is adequate but not rich, consistent with the reduced burden when annotations are present.
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 short, front-loaded with the core action, and structured with a bulleted list for return fields. The final sentence on use cases earns its place. No redundant or extraneous content.
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?
For a zero-parameter, read-only tool with strong annotations, the description fully covers what is needed: the resource retrieved, the exact return fields, and practical applications. There is no output schema, so the description appropriately explains the return values. No 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?
The tool has zero parameters and an empty input schema, so there are no parameter details to document. The baseline for no parameters is 4, and the description correctly omits any irrelevant parameter information.
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 opens with a specific verb+resource: 'Retrieves body measurements for the authenticated Whoop user.' It clearly differentiates from sibling tools by naming the resource (body measurements) and listing the exact fields returned, which are distinct from profile, recovery, sleep, workouts, cycles, and health overview.
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 phrase 'Useful for calculating calories burned and personalizing workout recommendations' conveys clear intended use cases. However, it does not explicitly mention when not to use this tool or point to alternative sibling tools, so it stops 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context about what data is included (recovery score, HRV, RHR, SpO2, sleep, strain) and the time ranges (latest, last night, today/yesterday), plus personalized recommendations. This is meaningful beyond annotation hints, though no mention of auth or rate limits is needed for a read-only overview.
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 well-structured with a clear opening sentence, a best-use note, and bullet-point lists for returns and use cases. Every sentence adds value, and it is front-loaded with the core purpose. No wasted words.
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 no output schema, the description compensates by enumerating the key return categories and providing use-case guidance. Sibling tools exist for specific data details, and this tool is clearly positioned as an aggregate overview. The description is complete for an agent to decide when and how to invoke it.
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 tool has zero parameters and the schema is fully descriptive (empty object). The description does not need to add parameter details. Since there are no parameters, the baseline is 4, and the description appropriately focuses on return values rather than input semantics.
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 ('Gets'), resource ('comprehensive health overview'), and scope ('combining your latest recovery, sleep, and strain data'). It distinguishes itself from sibling tools that focus on individual data types, making it the go-to for an aggregated summary.
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 identifies when to use this tool ('This is the best tool to use when you want a quick summary of current health status') and lists concrete use cases. It does not explicitly name alternatives or provide exclusions, but the context clearly implies detailed data tools should be used when specific metrics are needed.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral context by specifying that it operates on the authenticated user and lists the returned fields. No contradictions exist, and the extra detail about return values is valuable.
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 efficiently structured, with a clear opening sentence, a bulleted list of return fields, and a brief usage note. Every sentence adds value without redundancy, making it easy for an agent to parse.
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?
Despite having no output schema, the description enumerates all return fields, clarifying what 'basic profile information' means. Combined with a clear purpose, usage hint, and good sibling differentiators, the description is complete for a simple zero-parameter read-only 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?
With zero parameters, the schema fully covers all inputs (100% coverage). The baseline for 0 parameters is 4, and the description does not need to elaborate on parameter mechanics. It appropriately focuses on outputs rather than inputs.
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 states the specific action ('Retrieves basic profile information') and the resource ('authenticated Whoop user'). It clearly differentiates from sibling tools, which all target different data types (recovery, sleep, workouts, etc.), by focusing on profile identity fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: 'Use this to identify the user and personalize responses.' It does not explicitly mention when not to use it or name alternatives, but the implied contrast with sibling tools is evident. This meets the 'clear context, no exclusions' level.
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-server MCP server](https://glama.ai/mcp/servers/benhursenabathi/whoop-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/benhursenabathi/whoop-mcp-server)

Score Badge

Copy to your README.md:

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

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/benhursenabathi/whoop-mcp-server'

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