Skip to main content
Glama
benhursenabathi

whoop-mcp-server

Get Workout Data

whoop_get_workouts
Read-onlyIdempotent

Fetch workout data from Whoop including strain, heart rate zones, calories, and distance, with filters for date range and record count.

Instructions

Retrieves workout data from Whoop including strain, heart rate zones, calories, and distance.

Strain is measured on a 0-21 scale:

  • 0-10: Light activity

  • 10-14: Moderate activity

  • 14-18: High strain (strenuous)

  • 18-21: All out (maximal effort)

Parameters:

  • limit: Number of records (1-25, default: 10)

  • start: Filter workouts after this date (ISO 8601)

  • end: Filter workouts before this date (ISO 8601)

Returns for each workout:

  • sport_name: Type of activity

  • strain: Workout strain score (0-21)

  • kilojoule: Energy burned

  • average/max_heart_rate: Heart rate data

  • distance_meter: Distance covered (if applicable)

  • zone_durations: Time spent in each HR zone

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoEnd date filter (ISO 8601 format)
limitNoNumber of workout records to fetch (1-25, default: 10)
startNoStart date filter (ISO 8601 format)
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read operation. The description adds valuable behavioral context by explaining the strain scale (0-21) and enumerating return fields, going beyond the schema and 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: it opens with the purpose, then the strain scale, then parameters, then return fields. Every sentence contributes useful information without redundancy or fluff.

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?

With no output schema, the description compensates by listing return fields and explaining strain interpretation. It omits details like pagination or error handling, but these are not critical for this simple read-only tool, making it sufficiently complete.

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?

The input schema fully describes all three parameters with details (limit range/default, start/end ISO format). The description repeats this information without adding new semantic nuances beyond a minor clarification of filter direction. With 100% schema coverage, the baseline of 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 clearly states the tool retrieves workout data including specific fields (strain, heart rate zones, calories, distance), using a specific verb and resource. It distinguishes from sibling tools like whoop_get_recovery or whoop_get_sleep through the workout-specific content.

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 implicitly conveys when to use the tool by listing workout-specific fields and the strain scale, making it appropriate for workout data retrieval. It does not explicitly mention alternatives, but the context and sibling tool names provide enough differentiation.

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

Install Server

Other Tools

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/benhursenabathi/whoop-mcp-server'

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