Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@WHOOP MCP Server how was my recovery today?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for WHOOP biometric data. Query recovery, strain, sleep, workouts, and heart rate from any MCP-compatible AI client.
Remote — Calls /api/whoop/stats on a deployed WHOOP-connected site (e.g., patrickwingert.com)
Direct — Talks to the WHOOP API directly with local OAuth + token storage
Both modes expose the same 11 tools through a shared interface.
Related MCP server: Whoop MCP Server
npm install
npm run buildRemote mode (uses an existing WHOOP-connected site):
{
"mcpServers": {
"whoop": {
"command": "node",
"args": ["/path/to/whoop-mcp-server/dist/index.js"],
"env": {
"WHOOP_MODE": "remote",
"WHOOP_BASE_URL": "https://patrickwingert.com"
}
}
}
}Direct mode (standalone, talks to WHOOP API):
{
"mcpServers": {
"whoop": {
"command": "node",
"args": ["/path/to/whoop-mcp-server/dist/index.js"],
"env": {
"WHOOP_MODE": "direct",
"WHOOP_CLIENT_ID": "your-client-id",
"WHOOP_CLIENT_SECRET": "your-client-secret"
}
}
}
}Go to WHOOP Developer Portal
Create a new application
Set redirect URI to http://localhost:8787/callback
Enable scopes: read:profile, read:recovery, read:cycles, read:workout, read:sleep, read:body_measurement
Copy Client ID and Client Secret to your config
On first use, the server will need OAuth tokens. The OAuth flow:
Server starts a temporary listener on localhost:8787
Open the generated authorization URL in your browser
Authorize on WHOOP's site
Tokens are stored in ~/.whoop-mcp/tokens.json (chmod 600)
Tokens auto-refresh going forward
Tool | Description |
| Full biometric snapshot (recovery, strain, HR, sleep, workout) |
| Recovery score (0-100), resting HR, HRV, SpO2, skin temp |
| Daily strain (0-21), kilojoules, average/max HR |
| Latest workout: sport, duration, strain, HR zones, distance |
| Current HR with source context (resting/workout/decay) |
| Sleep performance, stages, efficiency, respiratory rate |
| Sleep need breakdown: baseline, debt, strain impact, nap offset |
Tool | Description |
| Endpoint status, token expiry, connection state |
| What's cached, staleness, TTL remaining |
| Force fresh data on next request |
| Current mode, target, scopes, cache TTL |
All tools support response_format: markdown (default, human-readable) or json (structured data).
Variable | Mode | Required | Description |
| Both | Yes |
|
| Remote | Yes | Base URL of WHOOP-connected app |
| Direct | Yes | From WHOOP developer dashboard |
| Direct | Yes | From WHOOP developer dashboard |
~/.whoop-mcp/
├── tokens.json # OAuth tokens (chmod 600)
└── cache.json # Cached API responses# Test with MCP Inspector
npx @modelcontextprotocol/inspector node dist/index.jsStart OAuth flow to connect a WHOOP account. Returns an authorization URL to open in your browser. Direct mode only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 starts an OAuth flow and returns an authorization URL, but does not mention side effects like stored credentials or post-authorization steps. This is a gap for a mutation-like tool, but the essential behavior is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loads the action, and contains no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool without an output schema, the description explains both purpose and return value ('Returns an authorization URL'). It could mention a follow-up step (e.g., checking health after auth), but the description is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers 100% of the parameter space. The baseline of 4 applies because no extra semantic description is needed when there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Start OAuth flow') and resource ('WHOOP account'), clearly distinguishing it from sibling tools that fetch data. It unambiguously states the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage constraint with 'Direct mode only', indicating when the tool should not be used (indirect mode). It does not explicitly mention alternatives, but the sibling set makes the context clear, so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connection and endpoint health: status per endpoint, token expiry, connection state
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context by mentioning status per endpoint, token expiry, and connection state. However, with no annotations, it does not explicitly state that this is a safe read-only operation or describe any potential side effects 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded, conveying the core purpose in one line. It is not a full sentence but avoids redundancy. Slightly more structure or a verb would make it clearer, but it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists key aspects of the health report but does not fully describe the return format beyond the response_format parameter. It lacks details on how endpoint statuses are presented or any limitations, though the tool is simple and has no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter (response_format), including its default and meaning. The description does not add any further parameter details, which is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool's purpose as reporting connection and endpoint health, including token expiry and connection state. While it lacks a specific verb like 'check' or 'retrieve', it clearly distinguishes this tool from sibling data-retrieval tools by focusing on health status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or related tools like whoop_get_cache_status or whoop_authorize that might be relevant for health checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cache freshness: cached data status, age, TTL remaining
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return content (status, age, TTL remaining) but does not explicitly state whether the operation is read-only, whether authentication is required, or if there are any side effects. Since no annotations are provided, the description bears the full burden and could be more transparent about the tool's safe, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using a noun phrase to convey the essential information in only a few words. There is no filler or redundancy, though it could be slightly expanded into a full sentence for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple cache status tool with one optional parameter and no output schema, the description adequately explains what data is returned (status, age, TTL remaining). It covers the key return values, which is essential in the absence of an output schema. The main missing element is usage guidance, which is already scored separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter response_format is fully documented in the schema with an enum, default, and description. The tool description adds no parameter-specific meaning, but 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool reports cache freshness metadata (status, age, TTL remaining). It distinguishes itself from sibling data getters by focusing on cache status rather than health or workout data. However, it is phrased as a noun phrase rather than an explicit action, so it's slightly less clear than a full verb-led description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like whoop_invalidate_cache or whoop_check_health. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Server configuration: mode, base URL or API target, enabled scopes, cache TTL
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only lists content fields. It does not state that this is a read-only operation, whether data may be cached, or that response_format allows markdown/json output. The lack of any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact fragment that lists key config fields without redundancy. It is efficient and easy to scan, though not a complete sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple config-getter with one optional parameter and no output schema, the description covers the main content (mode, base URL, scopes, cache TTL). It could be improved by mentioning the configurable response formats, but overall it is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter (response_format) with enum and default. The description adds no parameter-specific information, but the high schema coverage (100%) warrants the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves server configuration and enumerates specific elements (mode, base URL, scopes, cache TTL). This distinguishes it from sibling data-retrieval tools (stats, recovery, sleep) and health/cache management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the descriptive fragment, but there is no explicit guidance on when to choose this tool over siblings (e.g., for configuration inspection vs. data queries or health checks). No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current heart rate with context: HR value, source (live/decay/resting), resting HR baseline
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the source can be 'live/decay/resting', which adds behavioral context about the data's nature. However, it does not mention response format behavior, data freshness limits, or any permissions, though these are less critical for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core purpose ('Current heart rate') and then specifies the returned context. No wasted words; every phrase adds informational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 parameter and no annotations, the description adequately covers what the tool returns and the context (source and baseline). While it doesn't explain how to interpret the source values or provide examples, the output is simple enough that the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (response_format) is fully described in the schema with enum values, default, and explanation, so schema coverage is 100%. The tool description does not add any parameter-specific meaning, but since the schema already covers it fully, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (heart rate) and specifies the returned context (HR value, source, resting HR baseline), which distinguishes it from sibling tools like whoop_get_stats or whoop_get_recovery. However, it lacks an explicit verb like 'retrieves' or 'gets', relying on the tool name to imply the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, such as 'for historical heart rate use whoop_get_heart_rate_history' (which is not a sibling but implied). There is no explicit context for when this tool is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recovery score and details: score (0-100), resting HR, HRV, SpO2, skin temp
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavior. It only lists the data returned and gives no information about authentication needs, cache behavior, whether it fetches from the API, or whether it returns the most recent recovery. This is minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core purpose and key return fields. There is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, so the description partially covers the return values by listing metrics. However, it leaves ambiguity about whether this is the current/latest recovery vs. historical, and omits relevant context like requiring authorization (given sibling tools whoop_authorize, whoop_check_health, and cache tools).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter (response_format) with full enum documentation, achieving 100% schema coverage. The description does not mention this parameter, but the schema fully defines it, so the description adds no needed semantic value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Recovery score and details' and enumerates the returned metrics (score, resting HR, HRV, SpO2, skin temp). It distinguishes from the sibling 'whoop_get_recovery_history' by implying current recovery, though it does not explicitly say 'current' or contrast with the history tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention whether to use this for the latest recovery vs. historical data, nor does it reference sibling tools such as whoop_get_recovery_history. No prerequisites or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent recovery scores: daily recovery, resting HR, HRV, SpO2 trends over multiple days
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of records to return (1-25, default 7) | |
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only lists data types returned, not behavior such as ordering, time window, response format, or authentication requirements. It does not contradict any annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the primary output ('Recent recovery scores'), with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 optional params, no output schema), but the description is vague about the precise time range ('recent', 'over multiple days') and lacks details on sorting or default behavior. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions for 'limit' and 'response_format', so the description adds no parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns recent recovery scores with specific metrics (recovery, resting HR, HRV, SpO2) and indicates historical scope ('trends over multiple days'). This distinguishes it from sibling 'whoop_get_recovery' (singular) via the 'history' suffix and multi-day scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for viewing recovery trends over time, which is distinct from sibling 'whoop_get_recovery' (single record). However, it does not explicitly state when not to use it or reference alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest sleep data: performance %, stages, efficiency, respiratory rate, disturbances, nap flag
| Name | Required | Description | Default |
|---|---|---|---|
| include_stages | No | Include sleep stage breakdown | |
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states what data is returned and gives no information about side effects, authentication requirements, error behavior, or data freshness. For a read-only retrieval tool, the absence of any caveats or limitations leaves the agent with limited understanding of what happens under the hood.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists key output fields. Every word contributes value, and there is no redundant or tangential information. It is highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (two optional parameters, no output schema) and the presence of an explicit field list, the description covers the essential return content. It does not explain what 'latest' means (e.g., last night's sleep) or mention auth requirements, but these are minor gaps for a simple retrieval tool. The overall context is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters (include_stages and response_format) with 100% coverage. The tool description adds no extra parameter semantics. As per the baseline, a score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: retrieving the latest sleep data. It lists specific data points (performance %, stages, efficiency, respiratory rate, disturbances, nap flag), giving a concrete scope. It distinguishes from the history variant by using 'Latest' but does not explicitly name siblings or contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like whoop_get_sleep_history or whoop_get_sleep_need. The description implies it returns the most recent sleep data, but it does not explain how to choose between this and the history tool, nor does it mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent sleep data: performance, duration, efficiency, stages over multiple nights
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of records to return (1-25, default 7) | |
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context about the data content (performance, duration, efficiency, stages) and multi-night scope, but it does not clarify 'recent' (which is governed by the limit parameter), authentication requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact 9-word fragment that front-loads 'Recent sleep data' and uses a colon-separated list. It is concise and avoids waste, though it lacks a formal sentence structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description provides a reasonable overview of the returned data and multi-night scope. However, it does not explain how 'recent' relates to the limit parameter or explicitly differentiate from whoop_get_sleep beyond 'multiple nights', leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions for limit and response_format. The description does not add parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a tool for retrieving recent sleep data over multiple nights, listing specific data fields (performance, duration, efficiency, stages). The verb 'get' is implied by the tool name, and the 'multiple nights' phrase distinguishes it from whoop_get_sleep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for multi-night sleep history but does not explicitly contrast with whoop_get_sleep or name alternatives. It gives context but no clear when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sleep need analysis: baseline need, sleep debt, strain-based need, nap offsets
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
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 consists solely of a noun phrase listing analysis components and does not indicate that this is a read-only operation, describe return values, or mention any side effects or limitations. This is a significant gap for a tool that likely retrieves computed data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact phrase with no filler words. Every word contributes to naming the tool's focus, making it appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter), but the description lacks context on when to invoke it, what the output looks like, or how it relates to sibling sleep tools. It reads as a tagline rather than a complete guide, and with no output schema or annotations, more explanation is needed to fully prepare an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single response_format parameter with an enum and default value, achieving 100% schema description coverage. The description adds no additional parameter meaning, but per the rubric, a baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Sleep need analysis' and enumerates specific components (baseline need, sleep debt, strain-based need, nap offsets), which differentiates it from sibling whoop_get_sleep by focusing on need rather than raw sleep data. It is specific and actionable, though it does not explicitly name the sibling tool as an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like whoop_get_sleep or whoop_get_recovery. The description neither states conditions for use nor mentions any exclusions or alternative tools, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full biometric snapshot: recovery, strain, HR, HRV, SpO2, skin temp, sleep, latest workout
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists what data is included but does not disclose whether this is a read-only operation, how data is aggregated, data freshness, potential null values, response structure, or any rate limits or dependencies. Minimal behavioral insight beyond the scope of included metrics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently enumerates the biometric data covered. Every word contributes value, with no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and minimal annotations, so the description must compensate by explaining return values and usage context. While it lists the included metrics, it does not describe the output structure, units, or how to interpret the snapshot. It also lacks guidance on when to use this aggregate tool versus specific metric tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'response_format' parameter, but the input schema provides full coverage of that parameter with an enum, default, and description. Per the rubric, high schema coverage yields a baseline of 3, and the description adds no additional parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this is a comprehensive snapshot of biometric data, listing the specific metrics included (recovery, strain, HR, etc.). This distinguishes it from the individual whoop_get_* sibling tools, though the verb is implied rather than explicit ('snapshot' as a noun).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The label 'Full biometric snapshot' implies this tool is used to get a broad overview rather than calling individual metric endpoints, providing an implied usage context. However, it does not explicitly state when to prefer this over siblings or any exclusions, leaving this to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily strain: strain score (0-21), kilojoules, average and max heart rate
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It lists output fields but does not explain how 'Daily' is determined (e.g., today's data, most recent), whether authentication is required, or if any side effects exist. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise fragment that front-loads the core purpose and key fields. No unnecessary words, though it is slightly telegraphic and could benefit from a full sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and lack of output schema, the description adequately lists the returned metrics, but it leaves open questions about the time period (daily vs. current), return shape (single object vs. array), and prerequisite authorization. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, response_format, is fully documented in the schema (100% coverage). The description adds no additional semantic value beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning daily strain metrics, listing strain score (0-21), kilojoules, and average/max heart rate. This distinguishes it from sibling tools like recovery or workout, though it does not explicitly differentiate from whoop_get_strain_history, relying on the 'Daily' scope to imply a single day's data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as whoop_get_strain_history or other metric tools. It only states the resource and output fields, with no mention of exclusions or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent daily strain: strain scores, calories, heart rate trends over multiple days
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of records to return (1-25, default 7) | |
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds context by listing the returned data fields (strain scores, calories, heart rate trends) and temporal scope ('recent', 'multiple days'), but does not mention ordering, default range, or any limitations. It is a read-only get operation, but the description does not elaborate on edge cases or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core concept ('Recent daily strain'), and every word contributes meaningful information. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema), the description sufficiently covers the main data content and temporal scope. It could mention default behavior or return structure, but the schema already documents the parameters, and the description's compact overview is adequate for a read-only list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both 'limit' and 'response_format' have detailed descriptions), so the schema carries the parameter documentation burden. The description adds minimal value beyond implying the 'limit' parameter via 'multiple days'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns recent daily strain data, including strain scores, calories, and heart rate trends over multiple days. This distinguishes it from the singular whoop_get_strain tool and other history tools by focusing on daily history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical daily strain data through words like 'recent' and 'over multiple days', but it does not explicitly state when to prefer this tool over whoop_get_strain or other alternatives. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest workout: sport, duration, strain, distance, heart rate zones, altitude
| Name | Required | Description | Default |
|---|---|---|---|
| include_zones | No | Include heart rate zone breakdown | |
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden but only lists output fields. It fails to disclose that heart rate zones are only included when the include_zones parameter is set to true (as per the schema default false), and gives no information about error behavior, authentication, or caching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase, using only 11 words to convey the tool's purpose and output. It is well-structured as a front-loaded summary, though it is a fragment rather than a full sentence, which slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema, the description lists the main fields returned, which is helpful. However, it omits the conditional behavior of heart rate zones, the effect of response_format, and any error/edge-case behavior, leaving gaps for an agent deciding how to invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (include_zones and response_format), achieving 100% schema coverage. The description adds no parameter-specific semantics, but the baseline of 3 applies because the schema itself is self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly identifies the tool as returning the 'Latest workout' and enumerates the included attributes (sport, duration, strain, distance, heart rate zones, altitude). It distinguishes itself from the sibling tool whoop_get_workout_history by focusing on the single most recent workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the most recent workout but provides no explicit when-to-use guidance or comparison against alternatives. There is no mention of when to prefer this over whoop_get_workout_history or other get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent workouts: sport, duration, strain, calories for multiple past workouts
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of records to return (1-25, default 7) | |
| response_format | No | Response format: markdown (human-readable) or json (structured data) | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description carries the full burden of disclosing behavior. It mentions the data fields (sport, duration, strain, calories) but omits details like ordering, pagination, date filtering, or how 'recent' is defined. It also does not disclose authentication requirements or limits in the description, though limits appear in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, a single noun phrase, with no wasted words. It is front-loaded with the key concept 'recent workouts'. However, it is more of a fragment than a complete sentence, and may be terse to the point of omitting critical context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and annotations are absent, so the description must carry the burden of explaining what the agent can expect. It fails to mention ordering, pagination, default limit, available response formats, or the difference from a single workout query. For a history tool, this is insufficient guidance for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (limit and response_format), each with their own descriptions. The tool description adds no extra parameter meaning, but since the schema already documents them, the baseline of 3 is appropriate. The description's mention of 'recent' vaguely relates to limit but does not enhance schema understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states what the tool does: it returns recent workouts with sport, duration, strain, and calories. The phrase 'multiple past workouts' distinguishes it from the sibling whoop_get_workout which likely targets a single workout. It lacks an explicit verb, but the intent is clear from the tool name and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that whoop_get_workout is for a single workout or when a history view is appropriate. The only implied usage is that it returns multiple workouts, but no explicit conditions or alternative comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force fresh data on next request by invalidating the cache
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral implications. It states the tool invalidates cache, but omits side effects (e.g., whether it clears all cache, affects other requests, or requires authentication). No details on reversibility or performance impact are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence that communicates the primary action and its effect without unnecessary words. It earns its place and is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description covers the core action but lacks contextual completeness. It does not explain when this action is needed, what happens after invalidation, or how it interacts with caching behavior. While adequate for a simple operation, a short note on usage context would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly focuses on the operation rather than parameters, and there is no schema coverage issue since no parameters exist. Nothing is omitted that could disambiguate input expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Force fresh data on next request by invalidating the cache' clearly states the tool's function with a specific verb ('invalidating') and resource ('the cache'). It distinguishes itself from sibling getter tools by being the only cache-management operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description implies a scenario (stale data) but does not state exclusions, prerequisites, or contrast with getters or cache status checks. The sibling tool 'whoop_get_cache_status' might be relevant but is never mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0whoop_authorizewhoop_check_healthwhoop_get_cache_statuswhoop_get_configwhoop_get_heart_ratewhoop_get_recoverywhoop_get_recovery_historywhoop_get_sleepwhoop_get_sleep_historywhoop_get_sleep_needwhoop_get_statswhoop_get_strainwhoop_get_strain_historywhoop_get_workoutwhoop_get_workout_historywhoop_invalidate_cacheScored across 16 tools
Most tools are clearly distinct by metric and time range, but whoop_get_stats overlaps with specific getters like whoop_get_recovery and whoop_get_sleep, which could cause an agent to misselect. The descriptions help, but the boundary between the aggregate and specific tools is slightly unclear.
All tools follow a consistent whoop_get_<metric> pattern with snake_case and descriptive names. The pattern is uniform and predictable across the entire set.
With 16 tools, the server is slightly above the typical 3-15 range but still remains well-scoped. Each tool has a distinct role in retrieving or managing WHOOP data, so the count feels reasonable rather than excessive.
The tool set comprehensively covers core WHOOP biometrics—recovery, strain, workout, sleep, and heart rate—with both current and historical data views. The inclusion of health, cache, and config management tools fills the operational gaps, leaving no significant missing operations for the domain.
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Your WHOOP data in the assistant, read-only: recovery, sleep, strain, workouts, cycles and body meas
MCP server for Withings health data — sleep, activity, heart, and body metrics.
Pace is a remote MCP server that exposes wearable and fitness data to Claude via the Model Context Protocol. It connects to Garmin, Oura, Whoop, Polar, Fitbit and 20+ devices and provides 15 tools for querying sleep, activity, recovery, and training data. Hosted on Google Cloud Run, OAuth 2.1 authentication, Streamable HTTP transport. Instructions: First you need to create an account at: https://pacetraining.co and connect your wearables. After that you can connect the remote Server via Custom Connector in Claude and OAuth 2.1 Flow startet.