whoopmcp

by kurok

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or analytical operation: auth lifecycle (status, login, complete_login, logout), raw data (profile, body measurement, recoveries, sleeps, cycles, workouts, single gets), and analysis (summarize, trend, correlate, compare). Even similar-sounding tools like list_sleeps vs get_sleep are clearly differentiated by singular vs plural and description.
Naming Consistency3/5
The naming is mostly verb_noun (get_profile, list_sleeps, summarize_period) but inconsistent: auth tools carry a whoop_ prefix (whoop_login, whoop_complete_login) while data tools do not, and metric_trend breaks the verb_noun pattern by being noun_noun. The style is readable but not uniform.
Tool Count4/5
16 tools is slightly above the typical 3-15 range, but each tool earns its place by addressing a distinct need (auth, each data type, individual records, and analysis). The count is a bit heavy but not bloated, and the domain of WHOOP data access justifies the breadth.
Completeness4/5
The surface covers the core WHOOP data types (profile, body measurement, recoveries, sleeps, cycles, workouts) plus individual getters for sleep and workout, and adds useful analytical tools. Minor gaps persist: there is no get_recovery or get_cycle by ID, and no way to retrieve a single cycle or recovery directly, but these can be worked around via the list functions.
Average 4.4/5 across 16 of 16 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 114 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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 and destructiveHint=false, covering safety. The description adds meaning by specifying measurement units (metres, kilograms, bpm), which is useful but does not disclose additional behavioral traits like whether it returns current or latest values. No contradiction with 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 a single, efficient sentence that conveys exactly what is returned with no wasted words. It is appropriately front-loaded and concise.
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 an output schema and safety annotations, the description is complete. It clearly defines the three returned values and their units, leaving no ambiguity for 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 zero parameters, so the description cannot add parameter meaning. Baseline for zero-parameter tools is 4, and no further explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns height in metres, weight in kilograms, and max heart rate in bpm, using a specific verb and resource. It does not explicitly differentiate from get_profile, which may also provide body-related metrics, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_profile or summarize_period. The description only states what it returns, with no context for selection.
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 and destructiveHint=false, so the read-only nature is covered. The description adds the detail that the identifier is a v2 UUID, which is a useful format constraint, but provides no additional behavioral context such as auth requirements or response behavior.
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 a single, succinct sentence that directly states the tool's purpose. Every word earns its place, with no repetition of schema or annotation information.
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 is simple with one parameter, and the output schema exists, so return values need no explanation. The description covers the core functionality and identifier format, though it lacks explicit usage guidance regarding when to use this tool versus listing workouts.
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 schema has a single workout_id parameter with 0% description coverage. The description compensates by specifying that the ID must be a v2 UUID, providing meaningful format guidance beyond the schema's plain string type.
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 returns a single workout by its v2 UUID, using a specific verb and resource. It distinguishes itself from sibling tools like list_workouts by emphasizing the singular nature and identifier-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that list_workouts should be used to find UUIDs or that this is for retrieving a specific item, leaving the agent to infer usage context.
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 and destructiveHint=false, so the agent knows this is a safe read. The description adds the specific fields returned, which is useful context, but it does not disclose other behavioral traits like auth requirements or data freshness beyond the 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 a single sentence that is front-loaded with the action and resource, and lists specific fields. Every word earns its place, and there is no redundancy or filler.
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 the tool's simplicity (zero params), strong annotations (readOnly, openWorld, non-destructive), and the presence of an output schema, the description fully conveys what the tool does and what it returns. No additional context is needed for an agent to select and invoke it correctly.
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 empty with 100% coverage (vacuously). The description adds no parameter-related information, but none is needed. Baseline for 0 params is 4, and the description does not detract from it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'WHOOP profile', listing specific fields (user id, email, first and last name). This distinguishes it from sibling tools like get_sleep or get_workout, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, such as whoop_auth_status or other data retrieval tools. The usage context is implied by the name but not explicitly stated, and there are no exclusions or alternative recommendations.
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 and destructiveHint=false, so safety is covered. The description adds value by specifying the v2 UUID format and that it returns a single record, but doesn't discuss not-found behavior.
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?
A one-sentence description that is front-loaded with the action and resource, with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-get tool with an output schema, the description covers the resource, identifier format, and scope. It doesn't mention error cases but those are typically understood; given the simplicity, it's adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by clarifying that the sleep_id parameter must be a v2 UUID, which adds meaning beyond the schema's generic string type.
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 the specific verb 'Return' and identifies the resource as 'a single sleep' by its 'v2 UUID', clearly distinguishing it from list_sleeps and other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific v2 UUID for a sleep, providing clear context. However, it does not explicitly mention alternatives like list_sleeps for retrieving multiple sleeps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive, so the description adds valuable behavioral context: it discloses that limit is capped at 25 by WHOOP, that next_token continues a previous truncated response, that start/end default to last 7 days, and that 'detail' controls whether zone_durations are included, with units in a top-level 'units' key. This goes well beyond the annotations and explains pagination and response shaping.
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 one-line purpose followed by an Args section. Each parameter has a concise explanation without redundant filler. Despite the length, every sentence adds necessary information, especially given the 0% schema coverage. It is efficiently packaged and easy to scan.
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 the complexity of 5 optional parameters, pagination, and an enum, the description covers all necessary details: default date range, server-side cap, cursor semantics, and the difference between summary and full detail, including the top-level units key. With an output schema present, the description does not need to repeat return values, so this is complete.
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 description coverage is 0%, but the description fully compensates by explaining every parameter: ISO 8601 formats for start/end, default ranges, limit cap and page size, next_token as a cursor, and the summary/full distinction for detail. This is exemplary parameter documentation that adds meaning the schema alone cannot convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' with the resource 'workouts' and enumerates the key fields returned (sport, strain, heart rate, zone durations). It is clear and specific, but it does not explicitly distinguish from sibling tools like get_workout or list_sleeps, relying on the plural 'list' vs. singular 'get' naming convention.
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 provides implied usage context, such as the default 7-day range when start/end are omitted, and explains pagination use via next_token. However, it does not explicitly state when to prefer this tool over alternatives like get_workout for a single workout, or compare against list_sleeps/list_recoveries. This leaves usage boundaries to be inferred.
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?
The description adds a valuable behavioral detail beyond the annotations: the state parameter is 'verified against the pending login before the code is used.' This discloses a safety check and order of operations. The annotations already indicate readOnlyHint=false and openWorldHint=true, so the description does not need to repeat the mutation/network effects, but it enriches the behavioral understanding.
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 succinct and front-loaded. The core purpose is stated in a single sentence, followed by a brief Args list. Every sentence adds value: the first defines the tool's function, the Args detail the parameter sources and verification. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter login completion tool, the description covers the essential context: both parameters are explained, the verification behavior is disclosed, and an output schema is present (so return values are already defined). The only minor gap is that it does not describe what happens on invalid state, but this is not necessary for successful 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?
The input schema has no descriptions (0% coverage), so the description must compensate. It explains both parameters: code is 'the code query parameter from the redirect' and state is 'the state query parameter from the redirect,' with an additional note that state is verified. This provides meaningful semantics that are absent from the 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 clearly states the tool's function: 'Finish a login using the code and state from the redirect URL.' This is a specific verb ('Finish') and resource ('login'), and it distinguishes the tool from siblings like whoop_login (which initiates login) and whoop_logout (which ends a session). The context of the redirect URL makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool: after obtaining a code and state from a redirect URL. It implies the preceding step of starting a login (via whoop_login) and the pending login state, but it does not explicitly mention alternatives or exclusions. This meets the 'clear context, no exclusions' threshold.
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 this as a safe, read-only, non-destructive operation. The description adds useful behavioral context by revealing the output shape: 'both periods' summaries and the delta, with sample sizes.' This goes beyond annotations without contradicting them.
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 compact and front-loaded: a clear action statement, a usage hint, a return-value summary, and then parameter definitions. Every sentence earns its place and the Args section is cleanly formatted.
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 the tool's simplicity, the presence of an output schema, and strong annotations, the description covers what the tool does, when to use it, what it returns, and all parameters. No critical information is missing.
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 descriptions are absent (0% coverage), so the description's Args list is essential. It explains each parameter's role (start/end of baseline/comparison) and requires ISO 8601 format, providing meaningful guidance beyond property titles alone.
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 purpose: comparing every summary metric between a baseline and a later period. This specific verb+resource combination distinguishes it from siblings like summarize_period (single period) and metric_trend (trend analysis).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context with the example 'did the training block change anything' questions. However, it does not explicitly mention when not to use it or name alternative tools, so it lacks explicit exclusions.
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?
Discloses default date range (last 7 days) and pagination behavior (limit capped at 25, next_token cursor), which go beyond the readOnlyHint annotation. It also clarifies the semantics of a cycle, adding useful context about the data model.
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?
Starts with a clear one-line summary, then a brief context sentence defining cycles, followed by a succinct Args list. No wasted words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential operational aspects: default behavior, pagination, and the central concept of cycles. With an output schema present, return values are already specified, so the description need not enumerate them.
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 descriptions are absent (0% coverage), but the Args section explains each parameter's meaning, format (ISO 8601), default behavior, and pagination use. This fully compensates for the schema 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 it lists physiological cycles with specific metrics (strain, heart rate, kilojoules) and defines cycles as WHOOP's day bounded by sleep. This distinguishes it from sibling list tools for sleeps, workouts, and recoveries.
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?
Explains what a cycle is and its role as the key join key, implying when cycle-level data is needed. It does not explicitly name alternative tools or contrast with them, but the context is clear enough for an agent to select it appropriately.
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 annotations declaring readOnlyHint=true, the safety profile is already known. The description adds valuable context that the slope is 'a description of the window requested, not a forecast' and discloses the return of r² and rolling means, which helps set expectations beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and the purpose is front-loaded. It is slightly longer than minimal but every sentence carries substantive information—no filler.
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 the presence of an output schema, the description need not detail every return field, but it does describe the key outputs (slope, r², rolling means) and provides an important interpretation caveat. All parameters are fully explained, and the tool's purpose is unambiguous, making it complete for an agent.
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?
The Args section in the description fully documents all three parameters—metric (with explicit enum-like options), start, and end (with ISO 8601 format). This completely compensates for the schema's generic string types, providing rich meaning beyond the input 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 clearly states 'Compute the direction and rate of change of one metric over a range,' using a specific verb and resource. It distinguishes itself from siblings by focusing on single-metric trend analysis rather than correlation or period comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool—when you need a trend (slope) of one metric over a time range. It does not explicitly mention alternatives or exclusion criteria, but the 'not a forecast' caveat adds a boundary for interpretation.
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 mark the tool as readOnlyHint=true and destructiveHint=false, and the description adds behavioral context: it doesn't complete login itself, requires external user browser action, and relies on a redirect URI with code/state parameters. This exceeds the annotation-only information.
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 short paragraphs – the first states the primary output, the second explains the process. No redundant words, all sentences contribute.
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 tool with an output schema and clear annotations, the description covers the entire flow: what the user receives, what they must do, and how the flow continues into whoop_complete_login. No major 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?
There are no parameters (schema properties empty), so the baseline is 4. The description adds no parameter details, as none exist; nothing more 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 explicitly states 'Return a URL the user must open in a browser to authorise this server' – a specific verb, resource, and outcome. It references the subsequent whoop_complete_login step, distinguishing it from sibling tools.
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 clearly implies the flow: open returned URL, complete consent, then pass code/state to whoop_complete_login. It doesn't explicitly state when not to use it (e.g., when already authenticated), but the sequential context makes usage clear.
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 and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context by detailing the return values (mean, std, median, min, max) and explaining days_missing as a coverage gap, not a record count. This goes beyond the annotations without contradicting them.
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, front-loaded with the main purpose, and structured clearly. The Args section is formatted neatly, and every sentence adds value—no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params), and the description explains the return values and the meaning of days_missing. Given the annotations indicate a read-only, open-world operation and an output schema exists, the description is sufficiently complete for an agent to use the tool effectively.
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?
The input schema only provides parameter names and types (string). The description adds essential meaning: both are ISO 8601 dates and define the start/end of the range. With schema description coverage at 0%, this compensation is crucial for correct invocation and is done clearly.
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 'Summarise recovery, sleep and strain over a date range,' clearly stating a specific verb, resource, and scope. It distinguishes from sibling tools like list_recoveries and compare_periods by focusing on aggregation over a range rather than individual records or comparisons.
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 clearly implies its use case: when you need summary statistics over a date range. It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough that an agent can infer it's for aggregation rather than raw data retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds substantial behavioral context: joining by UTC calendar date rather than by cycle, the meaning of positive lag (metric_a leads), the refusal threshold of 8 pairs, and autocorrelation warning. This goes well beyond annotations and provides essential statistical caveats.
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 longer than average, but every sentence adds value—statistical caveats, lag semantics, and edge cases are all substantive. It is well-structured with a summary paragraph followed by an Args section. While slightly verbose, the length is justified by the tool's complexity.
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 the tool's statistical complexity and 0% schema coverage, the description covers all essential aspects: lag range, join method, correlation coefficients, sample size threshold, error condition (ValueError for negative lag_days), and causal limitations. An output schema exists, so return values don't need explanation, but the description is complete for usage.
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 description coverage is 0%, so the description must carry the full burden, and it does. It explains metric_a as 'as in metric_trend', clarifies start/end as ISO 8601, and adds critical details for lag_days: default 3, capped at 14, and the inclusive sweep from -lag_days to +lag_days. All 5 parameters are meaningfully described, far exceeding the bare 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 states a specific action: 'Correlate two metrics over a range, sweeping a range of day-offsets.' It clearly distinguishes from siblings like metric_trend (single metric trend) and compare_periods (period comparison) by focusing on lagged correlation between two metrics. The inclusion of Pearson's r and Spearman's rho at every lag further specifies the 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 strong contextual guidance, explaining when results are meaningful and cautioning against causal interpretation: 'Correlation here is descriptive, not causal' and 'do not read a strong r at some lag as proof that one metric drives the other.' While it does not explicitly name alternative tools for different use cases, it gives clear context on the appropriate interpretation and limitations, which is nearly as useful.
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 this is a safe, read-only, non-destructive operation. The description adds useful behavioral context by specifying what the report contains (scopes, expiry) and how to interpret failure states, which goes beyond the annotation hints. It doesn't contradict 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?
Two terse sentences deliver the purpose, the key output details, and the primary use case. Information is front-loaded and every clause adds value, with no redundancy or filler.
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 status tool, the description fully conveys its role and diagnostic value. An output schema exists to document return shape, so the description doesn't need to list fields. The failure-mode guidance completes the picture within the broader tool landscape.
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, so the baseline of 4 is appropriate. The description correctly focuses on behavior rather than parameter details, and the empty schema leaves nothing unexplained.
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 the specific verb 'Report' and clearly states the resource: WHOOP authentication status including token validity, scopes, and expiry. This distinguishes it from siblings like whoop_login, whoop_logout, and data-fetching tools.
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?
It explicitly advises to call this tool first when a data tool fails, and explains that it distinguishes between three failure modes (never logged in, token expired, scope not granted). This is direct, actionable guidance with clear context and no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite destructiveHint=true already signaling destruction, the description adds critical behavioral context: the operation is local-only and does not affect WHOOP-side authorization. It also informs the user that revocation must be done externally, preventing misinterpretation.
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 succinct at two sentences, with the primary action in the first sentence and a clarifying caveat in the second. No unnecessary words or repetition.
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 logout tool, the description covers the action, its scope, and the distinction from full authorization revocation. The presence of an output schema further reduces the need for return-value explanation, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty schema provides complete coverage. Per the baseline for 0 params, no additional description is needed to explain parameters. Score 4 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 'Delete the locally stored WHOOP token' uses a specific verb+resource, clearly stating the action. It distinguishes from sibling auth tools (whoop_auth_status, whoop_login) by focusing on local token deletion, not authentication or revocation.
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 what the tool does NOT do: 'This does not revoke the grant at WHOOP' and directs the user to the WHOOP app for revocation. This provides clear context for when to use the tool (local logout) and an alternative for full authorization withdrawal, though it doesn't explicitly reference sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and non-destructive behavior. The description adds valuable behavioral details: pagination via next_token, limit capped at 25 by WHOOP, and default date range behavior. This goes beyond the annotations and helps the agent understand paging and defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary followed by a clearly formatted argument list. Every line adds value, with no filler or 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?
The description covers purpose, fields, parameters, defaults, and pagination. An output schema exists, so return value details are not needed. It is complete for a list tool with optional parameters.
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 description coverage is 0%, so the description must compensate. It fully explains all four parameters: start/end as ISO 8601 with an example, limit capped at 25, and next_token as a cursor for continued pagination. This exceeds what the schema provides.
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 'List recovery records' and specifies the exact fields returned (recovery score %, HRV ms, resting heart rate bpm). This distinguishes it from sibling tools like list_sleeps or list_workouts, which focus on different 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful usage context: start and end default to the last 7 days when both omitted, and next_token enables pagination. However, it doesn't explicitly state when to use this tool instead of alternatives, though the resource is unique among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond annotations: default date range behavior, WHOOP's 25-per-page cap, cursor-based pagination via next_token, and the summary vs. full detail distinction including units placement. This goes well beyond the provided 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 with the core purpose, followed by a concise parameter list. Every line provides useful information without fluff or 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?
The description covers all essential aspects for a complex listing tool: pagination, defaults, response shaping, and unit handling. Given the output schema exists, the description is fully complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description thoroughly documents all five parameters: start/end ISO 8601 defaults, limit cap, next_token pagination cursor, and detail enum semantics. It adds significant meaning beyond the bare 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 clearly states the tool lists sleep records and specifies key data included (performance, efficiency, stage durations). It is specific and distinguishes from singular get_sleep and other resource-specific list tools.
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 the tool, including the default date range and detail options. However, it does not explicitly name alternatives or exclusion criteria, such as when to use get_sleep instead.
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:

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

Score Badge

Copy to your README.md:

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

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/kurok/whoopmcp'

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