Skip to main content
Glama
yuridivonis

Whoop MCP Server

by yuridivonis
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Recent workouts

get_workouts
Read-onlyIdempotent

Retrieve recent WHOOP workouts as a Markdown table with date, activity, duration, strain, heart rate, zone time, and calories. Use it for questions on specific sessions or training volume.

Instructions

Returns individual workouts from the last days days (default 14), newest first, as a Markdown table: local date and start time, activity, duration, strain (or "unscored" when WHOOP hasn't scored it), average and max heart rate, time in heart-rate zones 4–5 and calories; a details table with distance, elevation gain, altitude change, the share of heart-rate data recorded and time in each zone 0–5; then totals. Use it for questions about specific sessions or training volume; for whole-day strain including activity outside workouts, use get_strain_history. 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

TableJSON 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 include (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. Addedv1.1.1

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, non-destructive, open-world, so the safety bar is met structurally; the description adds genuinely new behavior beyond them: live fetch with no caching, 'unscored' handling for unprocessed WHOOP data, an explicit error message when WHOOP is unreachable, and an auth-not-connected path returning a prompt to call get_auth_url.

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-loads what is returned before routing advice and behavioral notes, and every sentence carries information — the long field enumeration is justified because there is no output schema. It is a dense single paragraph, though; the return-format inventory could be lightly compressed.

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 specifies the return shape (main table, details table, totals), the ordering, the null/'unscored' case, and both failure modes. Nothing an agent needs to call it correctly or interpret the result 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 coverage is 100% and the schema already documents min/max/default for `days`, so baseline is 3. The description goes further by mapping values to intent ('7 for the last week, 30 for the last month, up to 90'), which helps an agent choose a value rather than just validating 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?

States a specific verb+resource with scope: individual workouts from the last `days` days, newest first, and enumerates the returned fields. It explicitly contrasts itself with the sibling get_strain_history ('whole-day strain including activity outside workouts'), so an agent can route between them without opening either schema.

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?

Gives explicit when-to-use ('questions about specific sessions or training volume'), names the alternative and the exact condition that selects it (get_strain_history for whole-day strain), and even tells the agent how to pick `days` (7 for last week, 30 for last month, up to 90). Failure routing to get_auth_url is also specified.

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