Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
WHOOP_MODENoMode of operation: 'remote' or 'direct'
WHOOP_BASE_URLNoBase URL of WHOOP-connected app (required for remote mode)
WHOOP_CLIENT_IDNoClient ID from WHOOP developer dashboard (required for direct mode)
WHOOP_CLIENT_SECRETNoClient Secret from WHOOP developer dashboard (required for direct mode)

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
whoop_get_statsB

Full biometric snapshot: recovery, strain, HR, HRV, SpO2, skin temp, sleep, latest workout

whoop_get_recoveryB

Recovery score and details: score (0-100), resting HR, HRV, SpO2, skin temp

whoop_get_strainC

Daily strain: strain score (0-21), kilojoules, average and max heart rate

whoop_get_workoutB

Latest workout: sport, duration, strain, distance, heart rate zones, altitude

whoop_get_heart_rateB

Current heart rate with context: HR value, source (live/decay/resting), resting HR baseline

whoop_get_sleepB

Latest sleep data: performance %, stages, efficiency, respiratory rate, disturbances, nap flag

whoop_get_sleep_needC

Sleep need analysis: baseline need, sleep debt, strain-based need, nap offsets

whoop_get_recovery_historyA

Recent recovery scores: daily recovery, resting HR, HRV, SpO2 trends over multiple days

whoop_get_strain_historyA

Recent daily strain: strain scores, calories, heart rate trends over multiple days

whoop_get_workout_historyC

Recent workouts: sport, duration, strain, calories for multiple past workouts

whoop_get_sleep_historyB

Recent sleep data: performance, duration, efficiency, stages over multiple nights

whoop_authorizeA

Start OAuth flow to connect a WHOOP account. Returns an authorization URL to open in your browser. Direct mode only.

whoop_check_healthB

Connection and endpoint health: status per endpoint, token expiry, connection state

whoop_get_cache_statusB

Cache freshness: cached data status, age, TTL remaining

whoop_invalidate_cacheA

Force fresh data on next request by invalidating the cache

whoop_get_configA

Server configuration: mode, base URL or API target, enabled scopes, cache TTL

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 16 tools

Disambiguation4/5

Most tools are clearly distinct by metric and time range, but whoop_get_stats overlaps with specific getters like whoop_get_recovery and whoop_get_sleep, which could cause an agent to misselect. The descriptions help, but the boundary between the aggregate and specific tools is slightly unclear.

Naming Consistency5/5

All tools follow a consistent whoop_get_<metric> pattern with snake_case and descriptive names. The pattern is uniform and predictable across the entire set.

Tool Count4/5

With 16 tools, the server is slightly above the typical 3-15 range but still remains well-scoped. Each tool has a distinct role in retrieving or managing WHOOP data, so the count feels reasonable rather than excessive.

Completeness5/5

The tool set comprehensively covers core WHOOP biometrics—recovery, strain, workout, sleep, and heart rate—with both current and historical data views. The inclusion of health, cache, and config management tools fills the operational gaps, leaving no significant missing operations for the domain.

Maintenance

ActivityInactive
ResponsivenessNo issues