Skip to main content
Glama
yuridivonis

Whoop MCP Server

by yuridivonis
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Recovery trends

get_recovery_trends
Read-onlyIdempotent

Retrieve daily recovery scores, HRV, resting heart rate, SpO2, and skin temperature for a chosen number of past days to analyze trends and compare changes over time.

Instructions

Returns daily recovery for the last days days (default 14), newest first, as a Markdown table: recovery score (%), HRV (ms), resting heart rate (bpm), SpO2 (%), skin temperature (°C) and whether WHOOP was still calibrating, for each of the user's local days, then averages over the days that have each value. Days WHOOP hasn't scored yet are listed as pending. Use it for patterns and comparisons, such as "how has my HRV changed this month?". For today alone, use get_today; for the sleep behind the numbers, use get_sleep_analysis. Set days to match the question: 7 for the last week, 30 for the last month, up to 90. Read-only: it never changes the user's WHOOP data. It fetches the data live from WHOOP on every call and keeps no copy, so the answer is current; if WHOOP can't be reached, it says so. If WHOOP isn't connected yet, it returns a message asking to call get_auth_url.

Input Schema

NameRequiredDescriptionDefault
daysNoHow many days to cover, counting back from today: 1 to 90, default 14.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.1.2
    • addedInput schema / properties / days / default
      Added value: +14
    • changedInput schema / properties / days / description
      Previous value: -"Number of days to analyze (default: 14, max: 90)"New value: +"How many days to cover, counting back from today: 1 to 90, default 14."
    • addedInput schema / properties / days / maximum
      Added value: +90
    • addedInput schema / properties / days / minimum
      Added value: +1
    • changedInput schema / properties / days / type
      Previous value: -"number"New value: +"integer"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, open-world behavior, yet the description adds substantial context beyond them: it fetches live data every call with no caching, reports explicitly when WHOOP is unreachable, lists unscored days as pending, and returns a get_auth_url prompt when WHOOP isn't connected. These are behavioral traits an agent needs and none are in the structured fields.

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?

Front-loaded with the return shape and scope before branching into alternatives and behavior, which is the right ordering. It is on the long side (roughly ten sentences) but nearly every sentence carries distinct information; only the calibration/pending detail borders on over-explanation.

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

Completeness5/5

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

With no output schema, the description fully compensates by naming the returned table columns, the averages aggregation, the newest-first ordering, and pending-day handling. Failure and auth paths are covered too, so an agent can call this correctly without further discovery.

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 the baseline is 3, but the description goes further by tying values to intent ('7 for the last week, 30 for the last month, up to 90') and by noting the default of 14 and the newest-first ordering. It meaningfully reduces ambiguity about how to choose a value rather than restating 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?

States a specific verb and resource ('Returns daily recovery for the last `days` days') and enumerates the exact columns returned, so the agent knows precisely what data it gets. It also distinguishes itself from get_today and get_sleep_analysis by name, making sibling selection unambiguous.

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?

Explicitly routes the agent: 'For today alone, use get_today; for the sleep behind the numbers, use get_sleep_analysis,' and gives a concrete use case ('how has my HRV changed this month?'). It further maps questions to parameter values ('7 for the last week, 30 for the last month'), which is unusually actionable guidance.

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

Deploy Server

Other Tools