WHOOP MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool addresses a distinct WHOOP domain (recovery, sleep, strain, workouts, profile, training recommendation) with no overlap. The descriptions clearly differentiate the data each returns, making it easy for an agent to select the correct tool for a given question.
Naming Consistency4/5
All tool names follow a consistent 'get_' prefix with a noun representing the data type (recovery, sleep, strain, etc.). This is predictable and clear. The only minor deviation is the slightly longer 'get_training_recommendation' compared to the others, but it still fits the pattern.
Tool Count5/5
With 6 tools, the set is well-scoped for a WHOOP fitness tracker integration. Each tool represents a core data category a user would query, and there are no extraneous or missing tools that would make the surface too large or too small for the domain.
Completeness4/5
The tools cover the most common queries about WHOOP data: recovery, sleep, strain, workouts, profile, and training recommendations. A minor gap is the lack of tools to query cycle/physiological data, meal logging, or team features, but the core personal health metrics are well represented.
Average 4.3/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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?
With no annotations provided, the description carries the full burden. It describes the return format (list + summary) and parameter options. However, it does not explicitly state that this is a read-only operation, mention authentication needs, rate limits, or pagination behavior. The description is adequate but missing these behavioral hints.
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 key fields and purpose. Every sentence adds value: first sentence lists what is returned, second explains the parameter options, third gives a usage directive. 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's simplicity (3 optional parameters, no output schema, no annotations), the description is mostly complete. It covers the purpose, parameter semantics, and usage context. However, it does not mention behavior when no workouts are found, whether results are sorted, or any error conditions. Still, it is fairly thorough for a list 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%, so the schema already documents the three parameters well. The description restates the two ways to specify time range (days or start/end) but does not add significant new meaning beyond what the schema provides. It adds value by mentioning the return structure (summary + records), but that is not parameter-specific.
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 a list of logged WHOOP workouts with specific fields (sport type, duration, strain, heart rates, calories). It distinguishes itself from sibling tools like get_recovery or get_sleep by focusing on exercise sessions, and explicitly mentions both current and historical queries.
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 answer questions about specific exercise sessions, now or in the past.' It also explains the two date range options (days or start/end). While no explicit 'when not to use' or alternatives are given, the sibling tools are distinct enough that this guidance is sufficient for an agent.
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 full burden for behavioral disclosure. It correctly states it is a read operation (no mutation implied) and discloses that data is per night (excludes naps). However, it does not mention pagination, rate limits, data freshness, or any auth requirements beyond what might be implicit, though none are needed given the tool's simplicity.
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 concise (3 sentences) and front-loaded with the most important information (what data is returned). Every sentence adds value: first sentence specifies fields and excludes naps, second explains the two input modes, third states the use case and return format. Loses 1 point for including the e.g. inside the schema description rather than in the main description, but that's a minor issue.
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 3 parameters (all optional, no output schema) and no annotations, so the description needs to compensate for the missing output schema. It does well by stating the return format ('summary with averages plus nightly records'). It covers all input modes and use case. A 5 would require explicit disclaimer about max date range or mention of any data source limitations.
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%, so the parameters are already well-documented in the schema. The description adds value by explaining the two query modes ('last N days' vs 'explicit start/end range') and provides a concrete example of the start/end format, which goes beyond the schema's description. 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 specific verbs ('Get') and clearly identifies the resource ('WHOOP sleep data'). It lists key fields (sleep performance %, efficiency %, time in bed, etc.) and distinguishes itself from other tools by explicitly noting it excludes naps, focusing on nightly data.
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 clearly states when to use this tool ('to answer questions about sleep quality or duration') and provides explicit guidance on using either 'last N days' or an explicit historical range, with a concrete example ('e.g. a specific past month'). It does not mention sibling tools for exclusion, but the specific verb+resource + listing of fields makes the differentiation 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 carries the full burden. It discloses the output format (summary with averages plus daily records) and the two parameter modes. However, it does not mention any potential side effects, authentication requirements, rate limits, or data freshness limitations. For a read-only data retrieval tool, this is adequate but not exceptional.
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, front-loaded with the purpose and metrics, followed by parameter modes and usage guidance. Every sentence earns its place; there is no redundancy or unnecessary detail.
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 3 parameters, no output schema, and no annotations, the description covers purpose, parameters, output format, and usage. It does not detail the exact JSON structure of the return value, but that is acceptable without an output schema. It is mostly complete for a moderately 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the two mutually exclusive parameter modes (days vs. start/end) and provides a clear example of the date range usage. This helps the agent understand correct parameter combinations, going beyond the raw schema descriptions.
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 WHOOP recovery data, enumerates specific metrics (recovery score, HRV, resting heart rate, SpO2, skin temperature), and distinguishes from siblings like get_sleep and get_strain. It is a specific verb+resource with clear scope.
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 explicit usage guidance: 'Use this to answer questions about how recovered/rested the user is, now or in the past.' It also explains the two parameter modes (last N days vs. explicit range). While it does not explicitly mention when not to use it or alternatives, the sibling tool names are distinct enough, and the context is 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 carries the burden of behavioral transparency. The description indicates this is a read operation ('Get') and lists the returned data fields, which implies no destructive side effects. It does not mention authentication needs, rate limits, or data freshness, but given the simplicity (no parameters, no output schema), these gaps are minor and acceptable.
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 with no wasted words. It front-loads the core action ('Get the WHOOP user's basic profile') and then lists the fields and usage context efficiently. Every sentence serves a purpose.
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 that the tool has no parameters, no output schema, and no nested objects, the description is fully complete. It tells the agent exactly what the tool does, what information it retrieves, and when to use it. There are no missing details that would hinder correct 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?
There are 0 parameters, so the baseline is 4. The schema description coverage is 100% (trivially satisfied), and the description adds meaning beyond the empty schema by explicitly naming the returned fields. No further parameter documentation is needed.
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 and resource ('Get the WHOOP user's basic profile') and lists the exact fields returned: name, email, height, weight, and max heart rate. This clearly distinguishes it from sibling tools like get_recovery, get_sleep, or get_workouts, which focus on different data domains.
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 states when to use this tool ('Use this for identity or body-metric questions'), providing clear context for its purpose. However, it does not explicitly state when not to use it or mention alternatives among siblings, but the sibling names are distinct enough that the agent can deduce this.
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 the full burden. It discloses that the tool uses today's recovery score and last 3 days of sleep, returns a recovery band, guidance, and a sleep debt warning. This implies a read-only operation with no side effects. It does not mention authentication or rate limits, but for a simple read tool, the disclosure is adequate.
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: first states what it does and inputs; second provides usage examples and an additional behavioral note (sleep debt warning). Every word earns its place. Front-loaded with essential purpose. No waste.
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 no output schema, no annotations, and zero parameters, the description is nearly self-contained. It explains inputs, output format (recovery band, guidance, warning), and use case. Could be slightly more complete by stating it is read-only or clarifying that data is real-time, but overall 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?
There are no parameters (0 params, schema coverage 100%), so baseline is 4 per the rule. The description adds context about what internal data the tool uses (recovery score, sleep performance) but does not describe parameter semantics since none exist. No contradiction with schema.
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 specific language: 'Get a coaching recommendation for today based on today's WHOOP recovery score and the last 3 days of sleep performance.' It clearly defines the verb (get), resource (coaching recommendation), and scope (today, using recovery and sleep). It also gives example questions that differentiate it from raw data siblings like get_recovery and get_sleep.
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 answer
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?
No annotations are provided, so the description carries a high burden. It thoroughly describes safety implications (an explicit read operation with no destructive action implied), usage modes (last N days vs. date range), and return format ('summary with averages/totals plus the daily records'). It is very transparent about what the tool does and its non-mutating nature.
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 (three sentences) and front-loaded: it states the core purpose first, then details parameters, then use cases. Every sentence contributes unique value without redundancy.
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 appropriately summarizes what is returned ('summary with averages/totals plus the daily records'). The tool is straightforward with 3 simple parameters and no nested objects, and the description covers all critical aspects: data type, range constraints, modes of use, and example queries. Complete for a simple read tool.
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 100%, but the description adds significant value by explaining how to use start and end together for a historical range, giving a concrete example for March 2026. It also clarifies the mutual exclusivity of days vs. start/end, adding meaning beyond the schema descriptions.
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 specific verbs ('Get', 'returns') and clearly identifies the resource: 'WHOOP daily strain data'. It distinguishes itself from siblings like get_recovery or get_sleep by explicitly listing the data points it retrieves (cardiovascular strain score, heart rate, calories burned) and the context (daily/cycle).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (e.g., 'answer questions about daily exertion or workload, now or in the past') and gives an explicit example ('what was my average strain in March'). It does not, however, explicitly state when not to use it or mention sibling alternatives like get_workouts for exercise-specific data.
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/vaibhavgoel63-arch/Whoop-MCP/badges/card.svg)](https://glama.ai/mcp/servers/vaibhavgoel63-arch/Whoop-MCP)

Score Badge

Copy to your README.md:

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

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