Skip to main content
Glama
Sign In
WHOOP MCP

WHOOP MCP

by myke239
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_whoop_workout

Read-onlyIdempotent

Retrieve a single WHOOP workout by its v2 UUID to inspect recorded heart-rate zones and strain data.

Instructions

Retrieve one workout by v2 UUID with recorded HR zones and strain.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workout_id": "<workout_id>"
    },
    "name": "get_whoop_workout"
  }
}

Input Schema

NameRequiredDescriptionDefault
workout_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds useful return-content context ('recorded HR zones and strain'), telling the agent what payload to expect. It does not address error behavior for unknown or malformed UUIDs, which is a modest gap for a keyed lookup.

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?

A single sentence with no filler: action, cardinality, key format, and returned fields in that order. Nothing could be removed without losing information.

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

Completeness3/5

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

With one param, no output schema, and annotations covering safety, the definition is nearly sufficient. Missing is the provenance of the UUID (presumably list_whoop_workouts) and any note on not-found behavior, which keeps it from being fully self-sufficient.

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 coverage is 0%, with a bare 'Workout Id' string and no format detail, so the description carries the burden. 'v2 UUID' adds real meaning about the expected format. It still omits how the agent should source that ID, leaving a genuine gap against the 0% coverage baseline.

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

Purpose4/5

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

States a specific verb and resource ('Retrieve one workout') and scopes it to a single record, which implicitly separates it from the plural sibling list_whoop_workouts. It also names the identifier flavor ('v2 UUID'), so an agent knows what kind of lookup this is. It stops short of explicitly naming the sibling it differs from.

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

Usage Guidelines3/5

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

The singular 'one workout' plus 'by v2 UUID' implies this is the single-record fetch to use when an ID is already known, versus the listing tool. However, there is no explicit when-to-use, no note on where to obtain the UUID, and no stated alternative for fetching workouts without an ID.

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