Skip to main content
Glama
deenesjakoruzh
vaibhavgoel63-arch

WHOOP MCP Server

by vaibhavgoel63-arch
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

WHOOP MCP Server

An MCP (Model Context Protocol) server that lets Claude query your personal WHOOP health data — recovery, sleep, strain, workouts, and profile — via WHOOP's official OAuth 2.0 REST API (v2).

Each person who uses this runs their own copy against their own WHOOP account: you register your own free developer app with WHOOP, and your tokens/credentials stay in local files on your machine (gitignored, and written with restrictive permissions) — they're never sent anywhere except directly between your machine and WHOOP's API.

That said, the health data these tools return is a different story: once a tool call happens, its result is returned to whatever MCP client/model you're using (e.g. Claude), so it's subject to that service's own privacy and data-handling policies from that point on. Only the credentials and tokens are guaranteed to stay local — the recovery scores, sleep data, etc. you ask about necessarily become visible to the model answering your question.

git clone https://github.com/vaibhavgoel63-arch/Whoop-MCP.git
cd Whoop-MCP

1. Get WHOOP API credentials

  1. Go to the WHOOP Developer Dashboard and sign in.

  2. Create (or open) an app.

  3. Under the app's API settings, set the Redirect URI to exactly:

    http://localhost:8080/callback

  4. Copy the Client ID and Client Secret — you'll paste these into .env in step 3 below.

Related MCP server: Whoop MCP Server

2. Prerequisites

  • Node.js 18+ (needed for the built-in fetch API). Check with node --version.

3. Install and configure

npm install
cp .env.example .env

Open .env and paste in your Client ID and Client Secret from step 1:

WHOOP_CLIENT_ID=your-client-id-here
WHOOP_CLIENT_SECRET=your-client-secret-here
WHOOP_REDIRECT_URI=http://localhost:8080/callback

⚠️ You must manually fill in WHOOP_CLIENT_ID and WHOOP_CLIENT_SECRET — the server will refuse to start any OAuth flow until these are set.

4. Build and log in (one-time)

npm run build
npm run login

This will:

  1. Start a temporary local server on http://localhost:8080.

  2. Open your browser to WHOOP's consent screen (requesting recovery, sleep, cycle, workout, profile, body-measurement, and offline/refresh scopes).

  3. After you approve, WHOOP redirects back to localhost:8080/callback with an authorization code.

  4. The script exchanges that code for an access + refresh token and saves them to token.json (gitignored) in the project root.

You only need to do this once. The MCP server automatically refreshes the access token using the refresh token when it expires (WHOOP access tokens last about 1 hour). If your refresh token is ever revoked or expires, just re-run npm run login.

5. Connect to Claude Desktop

Open your Claude Desktop config file:

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

Note: if you installed Claude Desktop from the Microsoft Store, the file above may just be a stub — the app actually reads %LOCALAPPDATA%\Packages\<Claude package folder>\LocalCache\Roaming\Claude\claude_desktop_config.json. If tools don't show up after following the steps below, check there.

Add a whoop entry under mcpServers. Replace the path below with the absolute path to this project's dist/server.js on your machine (find it with pwd on macOS/Linux or cd on Windows from inside the project folder):

{
  "mcpServers": {
    "whoop": {
      "command": "node",
      "args": ["/absolute/path/to/whoop-mcp/dist/server.js"]
    }
  }
}

⚠️ You must manually fill in this absolute path to wherever you cloned this repo. Use forward slashes even on Windows (e.g. C:/Users/you/whoop-mcp/dist/server.js) — they work fine inside this JSON file.

Then fully restart Claude Desktop (quit from the system tray, not just close the window).

6. Test it

  1. In Claude Desktop, click the tools/hammer icon in the chat box and confirm you see whoop with 6 tools listed: get_recovery, get_sleep, get_strain, get_workouts, get_profile, get_readiness_context.

  2. Try these prompts:

    • "How was my recovery this week?"

    • "Should I train hard today?"

    • "How did I sleep the last 3 nights?"

    • "Show me my workouts from the last 7 days."

    • "What's my current strain and how does it compare to yesterday?"

    • "What was my average strain in March 2026?" (historical range, not just "last N days")

  3. Spot-check one result (e.g. today's recovery score) against the WHOOP app to confirm the numbers match.

Tools reference

Tool

Description

get_recovery(days | start+end)

Recovery score, HRV, resting heart rate, SpO2, skin temp, score_state (SCORED/PENDING_SCORE/UNSCORABLE — non-scored records are included with null metrics, not dropped), user_calibrating — plus an averages summary

get_sleep(days | start+end)

Sleep performance %, efficiency %, stage breakdown (light/deep/REM), sleep_onset (full ISO timestamp of when sleep began, not just the date), score_state — plus an averages summary

get_strain(days | start+end)

Daily strain, average/max heart rate, calories per day, score_state — plus an averages/totals summary

get_workouts(days | start+end)

Logged workouts with sport, duration, strain, heart rate, calories, score_state — plus a summary

get_profile()

Name, email, height, weight, max heart rate

get_readiness_context()

Today's recovery, last 3 nights of sleep, last 3 days of strain — raw signals only, no verdict. Deliberately doesn't try to tell you whether to train; it can't see context like soreness, illness, or injury, so that synthesis is left to whoever's using this data

The four range-based tools accept either days (rolling window, e.g. days=7 for the last week) or an explicit start/end date pair (YYYY-MM-DD, end exclusive) for querying a specific historical period, e.g. start="2026-03-01", end="2026-04-01" for all of March 2026. Each returns a summary object (averages/totals) alongside the individual daily/nightly records.

Troubleshooting

  • "No WHOOP tokens found" — run npm run login.

  • 401 / token errors after working before — the server auto-refreshes access tokens; if you see a refresh failure, your refresh token was likely revoked (e.g. you removed app access in WHOOP settings). Re-run npm run login.

  • 403 Forbidden — your token is missing a scope. Scopes are fixed at login time, so re-run npm run login to get a fresh token with the full scope set.

  • 429 Too Many Requests — you've hit WHOOP's rate limit (100 requests/minute, 10,000/day). Wait and try again.

  • Tools don't show up in Claude Desktop — double-check the absolute path in claude_desktop_config.json, that you ran npm run build (the config points at dist/server.js, not src/server.ts), and that you fully restarted Claude Desktop.

Project structure

src/
  auth.ts        # OAuth constants, token load/save, refresh logic
  login.ts        # One-time login script (npm run login)
  whoopClient.ts  # Authenticated WHOOP API client + response normalizers
  server.ts       # MCP server exposing the 6 tools
.env.example      # Template for WHOOP_CLIENT_ID / WHOOP_CLIENT_SECRET / WHOOP_REDIRECT_URI

.env (credentials) and token.json (access/refresh tokens) are both gitignored — never commit either file.

Available Tools

6 tools
get_profileA

Get the WHOOP user's basic profile: name, email, height (cm), weight (kg), and max heart rate. Use this for identity or body-metric questions.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of behavioral transparency. The description indicates this is a read operation ('Get') and lists the returned data fields, which implies no destructive side effects. It does not mention authentication needs, rate limits, or data freshness, but given the simplicity (no parameters, no output schema), these gaps are minor and acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long with no wasted words. It front-loads the core action ('Get the WHOOP user's basic profile') and then lists the fields and usage context efficiently. Every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has no parameters, no output schema, and no nested objects, the description is fully complete. It tells the agent exactly what the tool does, what information it retrieves, and when to use it. There are no missing details that would hinder correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are 0 parameters, so the baseline is 4. The schema description coverage is 100% (trivially satisfied), and the description adds meaning beyond the empty schema by explicitly naming the returned fields. No further parameter documentation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Get the WHOOP user's basic profile') and lists the exact fields returned: name, email, height, weight, and max heart rate. This clearly distinguishes it from sibling tools like get_recovery, get_sleep, or get_workouts, which focus on different data domains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('Use this for identity or body-metric questions'), providing clear context for its purpose. However, it does not explicitly state when not to use it or mention alternatives among siblings, but the sibling names are distinct enough that the agent can deduce this.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_recoveryA

Get WHOOP recovery data: recovery score (0-100), HRV (ms), resting heart rate, SpO2, and skin temperature, per day. Accepts either the last N days or an explicit historical start/end range (e.g. a specific past month). Returns a summary with averages plus the daily records. Use this to answer questions about how recovered/rested the user is, now or in the past.

ParametersJSON Schema
NameRequiredDescriptionDefault
endNoEnd date, exclusive, as YYYY-MM-DD. Use together with "start".
daysNoNumber of most recent days to look back (1-90). Omit if using "start"/"end" instead.
startNoStart date, inclusive, as YYYY-MM-DD. Use together with "end" to query a specific historical period instead of "days" — e.g. for all of March 2026: start="2026-03-01", end="2026-04-01".

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the output format (summary with averages plus daily records) and the two parameter modes. However, it does not mention any potential side effects, authentication requirements, rate limits, or data freshness limitations. For a read-only data retrieval tool, this is adequate but not exceptional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the purpose and metrics, followed by parameter modes and usage guidance. Every sentence earns its place; there is no redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters, no output schema, and no annotations, the description covers purpose, parameters, output format, and usage. It does not detail the exact JSON structure of the return value, but that is acceptable without an output schema. It is mostly complete for a moderately simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the two mutually exclusive parameter modes (days vs. start/end) and provides a clear example of the date range usage. This helps the agent understand correct parameter combinations, going beyond the raw schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves WHOOP recovery data, enumerates specific metrics (recovery score, HRV, resting heart rate, SpO2, skin temperature), and distinguishes from siblings like get_sleep and get_strain. It is a specific verb+resource with clear scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'Use this to answer questions about how recovered/rested the user is, now or in the past.' It also explains the two parameter modes (last N days vs. explicit range). While it does not explicitly mention when not to use it or alternatives, the sibling tool names are distinct enough, and the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_sleepA

Get WHOOP sleep data: sleep performance %, efficiency %, time in bed, time asleep, and a breakdown of light/deep/REM sleep stages, per night (excludes naps). Accepts either the last N days or an explicit historical start/end range (e.g. a specific past month). Returns a summary with averages plus the nightly records. Use this to answer questions about sleep quality or duration, now or in the past.

ParametersJSON Schema
NameRequiredDescriptionDefault
endNoEnd date, exclusive, as YYYY-MM-DD. Use together with "start".
daysNoNumber of most recent days to look back (1-90). Omit if using "start"/"end" instead.
startNoStart date, inclusive, as YYYY-MM-DD. Use together with "end" to query a specific historical period instead of "days" — e.g. for all of March 2026: start="2026-03-01", end="2026-04-01".

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. It correctly states it is a read operation (no mutation implied) and discloses that data is per night (excludes naps). However, it does not mention pagination, rate limits, data freshness, or any auth requirements beyond what might be implicit, though none are needed given the tool's simplicity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3 sentences) and front-loaded with the most important information (what data is returned). Every sentence adds value: first sentence specifies fields and excludes naps, second explains the two input modes, third states the use case and return format. Loses 1 point for including the e.g. inside the schema description rather than in the main description, but that's a minor issue.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 3 parameters (all optional, no output schema) and no annotations, so the description needs to compensate for the missing output schema. It does well by stating the return format ('summary with averages plus nightly records'). It covers all input modes and use case. A 5 would require explicit disclaimer about max date range or mention of any data source limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are already well-documented in the schema. The description adds value by explaining the two query modes ('last N days' vs 'explicit start/end range') and provides a concrete example of the start/end format, which goes beyond the schema's description. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('Get') and clearly identifies the resource ('WHOOP sleep data'). It lists key fields (sleep performance %, efficiency %, time in bed, etc.) and distinguishes itself from other tools by explicitly noting it excludes naps, focusing on nightly data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states when to use this tool ('to answer questions about sleep quality or duration') and provides explicit guidance on using either 'last N days' or an explicit historical range, with a concrete example ('e.g. a specific past month'). It does not mention sibling tools for exclusion, but the specific verb+resource + listing of fields makes the differentiation clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_strainA

Get WHOOP daily strain data: cardiovascular strain score (0-21), average/max heart rate, and calories burned, per day (cycle). Accepts either the last N days or an explicit historical start/end range (e.g. a specific past month). Returns a summary with averages/totals plus the daily records. Use this to answer questions about daily exertion or workload, now or in the past — including things like 'what was my average strain in March'.

ParametersJSON Schema
NameRequiredDescriptionDefault
endNoEnd date, exclusive, as YYYY-MM-DD. Use together with "start".
daysNoNumber of most recent days to look back (1-90). Omit if using "start"/"end" instead.
startNoStart date, inclusive, as YYYY-MM-DD. Use together with "end" to query a specific historical period instead of "days" — e.g. for all of March 2026: start="2026-03-01", end="2026-04-01".

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries a high burden. It thoroughly describes safety implications (an explicit read operation with no destructive action implied), usage modes (last N days vs. date range), and return format ('summary with averages/totals plus the daily records'). It is very transparent about what the tool does and its non-mutating nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (three sentences) and front-loaded: it states the core purpose first, then details parameters, then use cases. Every sentence contributes unique value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description appropriately summarizes what is returned ('summary with averages/totals plus the daily records'). The tool is straightforward with 3 simple parameters and no nested objects, and the description covers all critical aspects: data type, range constraints, modes of use, and example queries. Complete for a simple read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant value by explaining how to use start and end together for a historical range, giving a concrete example for March 2026. It also clarifies the mutual exclusivity of days vs. start/end, adding meaning beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('Get', 'returns') and clearly identifies the resource: 'WHOOP daily strain data'. It distinguishes itself from siblings like get_recovery or get_sleep by explicitly listing the data points it retrieves (cardiovascular strain score, heart rate, calories burned) and the context (daily/cycle).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (e.g., 'answer questions about daily exertion or workload, now or in the past') and gives an explicit example ('what was my average strain in March'). It does not, however, explicitly state when not to use it or mention sibling alternatives like get_workouts for exercise-specific data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_training_recommendationA

Get a coaching recommendation for today based on today's WHOOP recovery score and the last 3 days of sleep performance. Returns a recovery band (green/yellow/red) with guidance on training load, plus a warning if sleep debt has been building. Use this to answer 'should I train today' or 'how hard should I push today' style questions.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the tool uses today's recovery score and last 3 days of sleep, returns a recovery band, guidance, and a sleep debt warning. This implies a read-only operation with no side effects. It does not mention authentication or rate limits, but for a simple read tool, the disclosure is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states what it does and inputs; second provides usage examples and an additional behavioral note (sleep debt warning). Every word earns its place. Front-loaded with essential purpose. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, no annotations, and zero parameters, the description is nearly self-contained. It explains inputs, output format (recovery band, guidance, warning), and use case. Could be slightly more complete by stating it is read-only or clarifying that data is real-time, but overall sufficient for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters (0 params, schema coverage 100%), so baseline is 4 per the rule. The description adds context about what internal data the tool uses (recovery score, sleep performance) but does not describe parameter semantics since none exist. No contradiction with schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific language: 'Get a coaching recommendation for today based on today's WHOOP recovery score and the last 3 days of sleep performance.' It clearly defines the verb (get), resource (coaching recommendation), and scope (today, using recovery and sleep). It also gives example questions that differentiate it from raw data siblings like get_recovery and get_sleep.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this to answer

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_workoutsA

Get a list of logged WHOOP workouts, each with sport type, duration, strain, average/max heart rate, and calories burned. Accepts either the last N days or an explicit historical start/end range (e.g. a specific past month). Returns a summary plus the individual workout records. Use this to answer questions about specific exercise sessions, now or in the past.

ParametersJSON Schema
NameRequiredDescriptionDefault
endNoEnd date, exclusive, as YYYY-MM-DD. Use together with "start".
daysNoNumber of most recent days to look back (1-90). Omit if using "start"/"end" instead.
startNoStart date, inclusive, as YYYY-MM-DD. Use together with "end" to query a specific historical period instead of "days" — e.g. for all of March 2026: start="2026-03-01", end="2026-04-01".

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It describes the return format (list + summary) and parameter options. However, it does not explicitly state that this is a read-only operation, mention authentication needs, rate limits, or pagination behavior. The description is adequate but missing these behavioral hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loaded with the key fields and purpose. Every sentence adds value: first sentence lists what is returned, second explains the parameter options, third gives a usage directive. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 optional parameters, no output schema, no annotations), the description is mostly complete. It covers the purpose, parameter semantics, and usage context. However, it does not mention behavior when no workouts are found, whether results are sorted, or any error conditions. Still, it is fairly thorough for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the three parameters well. The description restates the two ways to specify time range (days or start/end) but does not add significant new meaning beyond what the schema provides. It adds value by mentioning the return structure (summary + records), but that is not parameter-specific.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a list of logged WHOOP workouts with specific fields (sport type, duration, strain, heart rates, calories). It distinguishes itself from sibling tools like get_recovery or get_sleep by focusing on exercise sessions, and explicitly mentions both current and historical queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this to answer questions about specific exercise sessions, now or in the past.' It also explains the two date range options (days or start/end). While no explicit 'when not to use' or alternatives are given, the sibling tools are distinct enough that this guidance is sufficient for an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 6 tool updatesv1.0.0
    • First observedget_profile
    • First observedget_recovery
    • First observedget_sleep
    • First observedget_strain
    • First observedget_training_recommendation
    • First observedget_workouts
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

Each tool addresses a distinct WHOOP domain (recovery, sleep, strain, workouts, profile, training recommendation) with no overlap. The descriptions clearly differentiate the data each returns, making it easy for an agent to select the correct tool for a given question.

Naming Consistency4/5

All tool names follow a consistent 'get_' prefix with a noun representing the data type (recovery, sleep, strain, etc.). This is predictable and clear. The only minor deviation is the slightly longer 'get_training_recommendation' compared to the others, but it still fits the pattern.

Tool Count5/5

With 6 tools, the set is well-scoped for a WHOOP fitness tracker integration. Each tool represents a core data category a user would query, and there are no extraneous or missing tools that would make the surface too large or too small for the domain.

Completeness4/5

The tools cover the most common queries about WHOOP data: recovery, sleep, strain, workouts, profile, and training recommendations. A minor gap is the lack of tools to query cycle/physiological data, meal logging, or team features, but the core personal health metrics are well represented.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • WHOOP MCP Server

    maangy
    A
    license
    A
    quality
    D
    maintenance
    Gives Claude access to your WHOOP health data including recovery, sleep, workouts, cycles, body measurements, and profile via the WHOOP Developer API.
    7
    10
    MIT

  • whoop-mcp

    ab75173
    F
    license
    A
    quality
    C
    maintenance
    Enables Claude to read your WHOOP health data including recovery, sleep, strain, and workouts through the official WHOOP API, so you can ask natural language questions about your fitness metrics.
    7
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vaibhavgoel63-arch/Whoop-MCP'

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