Skip to main content
Glama
yuridivonis

Whoop MCP Server

by yuridivonis
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Recent workouts

get_workouts
Read-onlyIdempotent

Retrieve recent Whoop workout details, including activity, duration, strain, heart rate, zones, and calories, to answer questions about 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, 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.9/5.0
Behavior5/5

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

Annotations already mark it read-only, idempotent, open-world, and non-destructive. The description adds substantial behavior beyond that: it fetches live data on every call, keeps no copy, reports if WHOOP can't be reached, and instructs the caller to use get_auth_url if not connected. It also explains the 'unscored' strain case, which is genuinely useful context.

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 front-loaded with the core result and output format, then adds usage guidance, behavioral notes, and error handling in a logical order. Every sentence earns its place, and the length is justified by the density of useful information.

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 single-parameter tool with no output schema, the description is remarkably complete: it details the return shape, sorting, field semantics, live-fetch behavior, failure mode, and authentication prerequisite. An agent has everything needed to call this correctly and interpret the result.

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 schema already documents the `days` parameter well. The description adds practical usage semantics by mapping day values to common questions ('7 for the last week, 30 for the last month') and reiterating the maximum of 90, which enriches the agent's understanding of parameter intent.

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 verb and resource ('Returns individual workouts from the last `days` days') with precise behavioral details like ordering ('newest first') and output format ('Markdown table'). It also distinguishes itself from the sibling get_strain_history by scoping its purpose to workouts only.

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 explicitly tells when to use the tool ('questions about specific sessions or training volume'), gives a direct alternative ('for whole-day strain... use get_strain_history'), and provides concrete day-range mapping (7, 30, up to 90). This gives an agent clear selection criteria.

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