Skip to main content
Glama

WHOOP Workout

whoop_get_workout
Read-onlyIdempotent

Retrieve a specific WHOOP workout by its UUID. Requires read:workout scope. Use for reviewing individual workout data.

Instructions

Get one WHOOP workout by UUID. Requires read:workout scope.

Input Schema

NameRequiredDescriptionDefault
idYesWHOOP resource id.
privacy_modeNoOptional per-call payload privacy override. Defaults to WHOOP_PRIVACY_MODE or structured. raw returns full WHOOP API payloads, not raw device sensor streams.
response_formatNomarkdown
explicit_user_intentNoRequired true when privacy_mode=raw (agent escalation of redaction).

Output Schema

NameRequiredDescriptionDefault
dataYes
endpointYes
privacy_modeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.6.6
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Addedv0.6.1
  3. Removedv0.5.4
  4. First observedv0.5.3

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful read:workout scope requirement. It does not mention that privacy_mode=raw demands explicit_user_intent=true, which is a notable behavioral gate, so the additional context is limited.

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?

Two short sentences, purpose first, prerequisite second. Zero filler and fully front-loaded.

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?

An output schema exists, so return-value explanation is unnecessary, and the annotations cover the safety profile. Purpose and scope are both present. The main gap is not surfacing the raw-mode escalation requirement or the privacy_mode override in the description, but the schema handles those.

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 description coverage is 75% (response_format lacks a description; privacy_mode and explicit_user_intent are well documented). The description only says 'by UUID,' adding nothing beyond the schema's 'WHOOP resource id.' and arguably narrowing the schema's anyOf string|integer id to a UUID. Baseline 3 is appropriate when the schema does the heavy lifting.

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+resource+scope: 'Get one WHOOP workout by UUID.' The singular 'one ... by UUID' implicitly distinguishes it from whoop_list_workouts in the sibling set, though it never names that alternative. Clear enough that an agent knows exactly what it retrieves.

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?

'Requires read:workout scope' provides a genuine prerequisite. However, there is no explicit when-to-use guidance and no routing against the obvious sibling whoop_list_workouts or the aggregated whoop_daily_summary. Usage is implied by the resource name rather than stated.

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