Skip to main content
Glama
Sign In
deenesjakoruzh
WHOOP MCP Server

WHOOP MCP Server

by vaibhavgoel63-arch
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Servidor MCP de WHOOP

Un servidor MCP (Protocolo de Contexto del Modelo) que permite a Claude consultar tus datos personales de salud de WHOOP: recuperación, sueño, esfuerzo, entrenamientos y perfil — a través de la API REST oficial OAuth 2.0 de WHOOP (v2).

Cada persona que lo usa ejecuta su propia copia contra su propia cuenta de WHOOP: registras tu propia aplicación de desarrollador gratuita con WHOOP, y tus tokens/credenciales permanecen en archivos locales de tu máquina (ignorados por git) — nada se comparte ni se envía a ningún sitio excepto directamente entre tu máquina y la API de WHOOP.

git clone https://github.com/vaibhavgoel63-arch/Whoop-MCP.git
cd Whoop-MCP

1. Obtener credenciales de la API de WHOOP

  1. Ve al Panel de Desarrollador de WHOOP e inicia sesión.

  2. Crea (o abre) una aplicación.

  3. En la configuración de la API de la aplicación, establece la URI de Redirección exactamente como:

    http://localhost:8080/callback

  4. Copia el ID de Cliente y el Secreto de Cliente — los pegarás en .env en el paso 3 a continuación.

Related MCP server: whoop-mcp

2. Requisitos previos

  • Node.js 18+ (necesario para la API fetch integrada). Verifica con node --version.

3. Instalar y configurar

npm install
cp .env.example .env

Abre .env y pega tu ID de Cliente y Secreto de Cliente del paso 1:

WHOOP_CLIENT_ID=your-client-id-here
WHOOP_CLIENT_SECRET=your-client-secret-here
WHOOP_REDIRECT_URI=http://localhost:8080/callback

⚠️ Debes rellenar manualmente WHOOP_CLIENT_ID y WHOOP_CLIENT_SECRET — el servidor se negará a iniciar cualquier flujo OAuth hasta que estén configurados.

4. Compilar e iniciar sesión (una sola vez)

npm run build
npm run login

Esto:

  1. Inicia un servidor local temporal en http://localhost:8080.

  2. Abre tu navegador en la pantalla de consentimiento de WHOOP (solicitando los ámbitos de recuperación, sueño, ciclo, entrenamiento, perfil, medición corporal y offline/refresco).

  3. Después de que apruebes, WHOOP redirige de vuelta a localhost:8080/callback con un código de autorización.

  4. El script intercambia ese código por un token de acceso + de actualización y los guarda en token.json (ignorado por git) en la raíz del proyecto.

Solo necesitas hacer esto una vez. El servidor MCP actualiza automáticamente el token de acceso usando el token de actualización cuando caduca (los tokens de acceso de WHOOP duran aproximadamente 1 hora). Si tu token de actualización alguna vez se revoca o caduca, simplemente vuelve a ejecutar npm run login.

5. Conectar a Claude Desktop

Abre tu archivo de configuración de Claude Desktop:

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

Nota: si instalaste Claude Desktop desde Microsoft Store, el archivo anterior puede ser solo un marcador de posición — la aplicación realmente lee %LOCALAPPDATA%\Packages\<carpeta del paquete Claude>\LocalCache\Roaming\Claude\claude_desktop_config.json. Si las herramientas no aparecen después de seguir los pasos a continuación, verifica allí.

Añade una entrada whoop bajo mcpServers. Reemplaza la ruta a continuación con la ruta absoluta a este proyecto dist/server.js en tu máquina (encuéntrala con pwd en macOS/Linux o cd en Windows desde dentro de la carpeta del proyecto):

{
  "mcpServers": {
    "whoop": {
      "command": "node",
      "args": ["/absolute/path/to/whoop-mcp/dist/server.js"]
    }
  }
}

⚠️ Debes rellenar manualmente esta ruta absoluta hasta donde hayas clonado este repositorio. Usa barras inclinadas incluso en Windows (ej. C:/Users/tu/whoop-mcp/dist/server.js) — funcionan bien dentro de este archivo JSON.

Luego reinicia completamente Claude Desktop (sal de la bandeja del sistema, no solo cierres la ventana).

6. Probarlo

  1. En Claude Desktop, haz clic en el icono de herramientas/martillo en el cuadro de chat y confirma que ves whoop con 6 herramientas listadas: get_recovery, get_sleep, get_strain, get_workouts, get_profile, get_training_recommendation.

  2. Prueba estos mensajes:

    • "¿Cómo fue mi recuperación esta semana?"

    • "¿Debería entrenar fuerte hoy?"

    • "¿Cómo dormí las últimas 3 noches?"

    • "Muéstrame mis entrenamientos de los últimos 7 días."

    • "¿Cuál es mi esfuerzo actual y cómo se compara con ayer?"

    • "¿Cuál fue mi esfuerzo promedio en marzo de 2026?" (rango histórico, no solo "últimos N días")

  3. Verifica un resultado (ej. la puntuación de recuperación de hoy) contra la aplicación de WHOOP para confirmar que los números coinciden.

Referencia de herramientas

Herramienta

Descripción

get_recovery(días | inicio+fin)

Puntuación de recuperación, VFC, frecuencia cardíaca en reposo, SpO2, temperatura de la piel — más un resumen de promedios

get_sleep(días | inicio+fin)

Rendimiento del sueño %, eficiencia % y desglose de etapas (ligero/profundo/REM) — más un resumen de promedios

get_strain(días | inicio+fin)

Esfuerzo diario, frecuencia cardíaca promedio/máxima, calorías por día — más un resumen de promedios/totales

get_workouts(días | inicio+fin)

Entrenamientos registrados con deporte, duración, esfuerzo, frecuencia cardíaca, calorías — más un resumen

get_profile()

Nombre, correo electrónico, altura, peso, frecuencia cardíaca máxima

get_training_recommendation()

Combina la recuperación de hoy + los últimos 3 días de sueño en una recomendación de entrenamiento verde/amarillo/roja, con una advertencia de deuda de sueño si el rendimiento ha estado por debajo del 80% durante 2+ noches

Las cuatro herramientas basadas en rangos aceptan ya sea días (ventana móvil, ej. días=7 para la última semana) o un par explícito de fechas inicio/fin (AAAA-MM-DD, fin exclusivo) para consultar un período histórico específico, ej. inicio="2026-03-01", fin="2026-04-01" para todo marzo de 2026. Cada una devuelve un objeto resumen (promedios/totales) junto con los registros diarios/nocturnos individuales.

Solución de problemas

  • "No se encontraron tokens de WHOOP" — ejecuta npm run login.

  • Errores 401 / de token después de haber funcionado antes — el servidor actualiza automáticamente los tokens de acceso; si ves un fallo de actualización, es probable que tu token de actualización haya sido revocado (ej. eliminaste el acceso de la aplicación en la configuración de WHOOP). Vuelve a ejecutar npm run login.

  • 403 Prohibido — a tu token le falta un ámbito. Los ámbitos se fijan al iniciar sesión, así que vuelve a ejecutar npm run login para obtener un token nuevo con el conjunto completo de ámbitos.

  • 429 Demasiadas solicitudes — has alcanzado el límite de velocidad de WHOOP (100 solicitudes/minuto, 10,000/día). Espera e inténtalo de nuevo.

  • Las herramientas no aparecen en Claude Desktop — verifica la ruta absoluta en claude_desktop_config.json, que ejecutaste npm run build (la configuración apunta a dist/server.js, no a src/server.ts), y que reiniciaste completamente Claude Desktop.

Estructura del proyecto

src/
  auth.ts        # OAuth constants, token load/save, refresh logic
  login.ts        # One-time login script (npm run login)
  whoopClient.ts  # Authenticated WHOOP API client + response normalizers
  server.ts       # MCP server exposing the 6 tools
.env.example      # Template for WHOOP_CLIENT_ID / WHOOP_CLIENT_SECRET / WHOOP_REDIRECT_URI

Tanto .env (credenciales) como token.json (tokens de acceso/actualización) están ignorados por git — nunca confirmes ninguno de los dos archivos.

Available Tools

6 tools
get_profileA

Get the WHOOP user's basic profile: name, email, height (cm), weight (kg), and max heart rate. Use this for identity or body-metric questions.

NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden of behavioral transparency. The description indicates this is a read operation ('Get') and lists the returned data fields, which implies no destructive side effects. It does not mention authentication needs, rate limits, or data freshness, but given the simplicity (no parameters, no output schema), these gaps are minor and acceptable.

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 two sentences long with no wasted words. It front-loads the core action ('Get the WHOOP user's basic profile') and then lists the fields and usage context efficiently. Every sentence serves a purpose.

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?

Given that the tool has no parameters, no output schema, and no nested objects, the description is fully complete. It tells the agent exactly what the tool does, what information it retrieves, and when to use it. There are no missing details that would hinder correct invocation.

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?

There are 0 parameters, so the baseline is 4. The schema description coverage is 100% (trivially satisfied), and the description adds meaning beyond the empty schema by explicitly naming the returned fields. No further parameter documentation is needed.

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 uses a specific verb and resource ('Get the WHOOP user's basic profile') and lists the exact fields returned: name, email, height, weight, and max heart rate. This clearly distinguishes it from sibling tools like get_recovery, get_sleep, or get_workouts, which focus on different data domains.

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 explicitly states when to use this tool ('Use this for identity or body-metric questions'), providing clear context for its purpose. However, it does not explicitly state when not to use it or mention alternatives among siblings, but the sibling names are distinct enough that the agent can deduce this.

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

get_recoveryA

Get WHOOP recovery data: recovery score (0-100), HRV (ms), resting heart rate, SpO2, and skin temperature, per day. Accepts either the last N days or an explicit historical start/end range (e.g. a specific past month). Returns a summary with averages plus the daily records. Use this to answer questions about how recovered/rested the user is, now or in the past.

NameRequiredDescriptionDefault
endNoEnd date, exclusive, as YYYY-MM-DD. Use together with "start".
daysNoNumber of most recent days to look back (1-90). Omit if using "start"/"end" instead.
startNoStart date, inclusive, as YYYY-MM-DD. Use together with "end" to query a specific historical period instead of "days" — e.g. for all of March 2026: start="2026-03-01", end="2026-04-01".

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the output format (summary with averages plus daily records) and the two parameter modes. However, it does not mention any potential side effects, authentication requirements, rate limits, or data freshness limitations. For a read-only data retrieval tool, this is adequate but not exceptional.

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 three sentences, front-loaded with the purpose and metrics, followed by parameter modes and usage guidance. Every sentence earns its place; there is no redundancy or unnecessary detail.

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?

Given the tool has 3 parameters, no output schema, and no annotations, the description covers purpose, parameters, output format, and usage. It does not detail the exact JSON structure of the return value, but that is acceptable without an output schema. It is mostly complete for a moderately simple tool.

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 baseline is 3. The description adds value by explaining the two mutually exclusive parameter modes (days vs. start/end) and provides a clear example of the date range usage. This helps the agent understand correct parameter combinations, going beyond the raw schema descriptions.

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 WHOOP recovery data, enumerates specific metrics (recovery score, HRV, resting heart rate, SpO2, skin temperature), and distinguishes from siblings like get_sleep and get_strain. It is a specific verb+resource with clear scope.

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 provides explicit usage guidance: 'Use this to answer questions about how recovered/rested the user is, now or in the past.' It also explains the two parameter modes (last N days vs. explicit range). While it does not explicitly mention when not to use it or alternatives, the sibling tool names are distinct enough, and the context is clear.

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

get_sleepA

Get WHOOP sleep data: sleep performance %, efficiency %, time in bed, time asleep, and a breakdown of light/deep/REM sleep stages, per night (excludes naps). Accepts either the last N days or an explicit historical start/end range (e.g. a specific past month). Returns a summary with averages plus the nightly records. Use this to answer questions about sleep quality or duration, now or in the past.

NameRequiredDescriptionDefault
endNoEnd date, exclusive, as YYYY-MM-DD. Use together with "start".
daysNoNumber of most recent days to look back (1-90). Omit if using "start"/"end" instead.
startNoStart date, inclusive, as YYYY-MM-DD. Use together with "end" to query a specific historical period instead of "days" — e.g. for all of March 2026: start="2026-03-01", end="2026-04-01".

TDQS

A4.1/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It correctly states it is a read operation (no mutation implied) and discloses that data is per night (excludes naps). However, it does not mention pagination, rate limits, data freshness, or any auth requirements beyond what might be implicit, though none are needed given the tool's simplicity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3 sentences) and front-loaded with the most important information (what data is returned). Every sentence adds value: first sentence specifies fields and excludes naps, second explains the two input modes, third states the use case and return format. Loses 1 point for including the e.g. inside the schema description rather than in the main description, but that's a minor issue.

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?

The tool has 3 parameters (all optional, no output schema) and no annotations, so the description needs to compensate for the missing output schema. It does well by stating the return format ('summary with averages plus nightly records'). It covers all input modes and use case. A 5 would require explicit disclaimer about max date range or mention of any data source limitations.

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 100%, so the parameters are already well-documented in the schema. The description adds value by explaining the two query modes ('last N days' vs 'explicit start/end range') and provides a concrete example of the start/end format, which goes beyond the schema's description. Baseline 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 uses specific verbs ('Get') and clearly identifies the resource ('WHOOP sleep data'). It lists key fields (sleep performance %, efficiency %, time in bed, etc.) and distinguishes itself from other tools by explicitly noting it excludes naps, focusing on nightly data.

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 clearly states when to use this tool ('to answer questions about sleep quality or duration') and provides explicit guidance on using either 'last N days' or an explicit historical range, with a concrete example ('e.g. a specific past month'). It does not mention sibling tools for exclusion, but the specific verb+resource + listing of fields makes the differentiation clear.

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

get_strainA

Get WHOOP daily strain data: cardiovascular strain score (0-21), average/max heart rate, and calories burned, per day (cycle). Accepts either the last N days or an explicit historical start/end range (e.g. a specific past month). Returns a summary with averages/totals plus the daily records. Use this to answer questions about daily exertion or workload, now or in the past — including things like 'what was my average strain in March'.

NameRequiredDescriptionDefault
endNoEnd date, exclusive, as YYYY-MM-DD. Use together with "start".
daysNoNumber of most recent days to look back (1-90). Omit if using "start"/"end" instead.
startNoStart date, inclusive, as YYYY-MM-DD. Use together with "end" to query a specific historical period instead of "days" — e.g. for all of March 2026: start="2026-03-01", end="2026-04-01".

TDQS

A4.6/5.0
Behavior4/5

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

No annotations are provided, so the description carries a high burden. It thoroughly describes safety implications (an explicit read operation with no destructive action implied), usage modes (last N days vs. date range), and return format ('summary with averages/totals plus the daily records'). It is very transparent about what the tool does and its non-mutating nature.

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 concise (three sentences) and front-loaded: it states the core purpose first, then details parameters, then use cases. Every sentence contributes unique value without redundancy.

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?

Given no output schema, the description appropriately summarizes what is returned ('summary with averages/totals plus the daily records'). The tool is straightforward with 3 simple parameters and no nested objects, and the description covers all critical aspects: data type, range constraints, modes of use, and example queries. Complete for a simple read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant value by explaining how to use start and end together for a historical range, giving a concrete example for March 2026. It also clarifies the mutual exclusivity of days vs. start/end, adding meaning beyond the schema descriptions.

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 uses specific verbs ('Get', 'returns') and clearly identifies the resource: 'WHOOP daily strain data'. It distinguishes itself from siblings like get_recovery or get_sleep by explicitly listing the data points it retrieves (cardiovascular strain score, heart rate, calories burned) and the context (daily/cycle).

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 provides clear context for when to use this tool (e.g., 'answer questions about daily exertion or workload, now or in the past') and gives an explicit example ('what was my average strain in March'). It does not, however, explicitly state when not to use it or mention sibling alternatives like get_workouts for exercise-specific data.

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

get_training_recommendationA

Get a coaching recommendation for today based on today's WHOOP recovery score and the last 3 days of sleep performance. Returns a recovery band (green/yellow/red) with guidance on training load, plus a warning if sleep debt has been building. Use this to answer 'should I train today' or 'how hard should I push today' style questions.

NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool uses today's recovery score and last 3 days of sleep, returns a recovery band, guidance, and a sleep debt warning. This implies a read-only operation with no side effects. It does not mention authentication or rate limits, but for a simple read tool, the disclosure is adequate.

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 sentences: first states what it does and inputs; second provides usage examples and an additional behavioral note (sleep debt warning). Every word earns its place. Front-loaded with essential purpose. No waste.

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?

Given no output schema, no annotations, and zero parameters, the description is nearly self-contained. It explains inputs, output format (recovery band, guidance, warning), and use case. Could be slightly more complete by stating it is read-only or clarifying that data is real-time, but overall sufficient for a simple tool.

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?

There are no parameters (0 params, schema coverage 100%), so baseline is 4 per the rule. The description adds context about what internal data the tool uses (recovery score, sleep performance) but does not describe parameter semantics since none exist. No contradiction with schema.

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 uses specific language: 'Get a coaching recommendation for today based on today's WHOOP recovery score and the last 3 days of sleep performance.' It clearly defines the verb (get), resource (coaching recommendation), and scope (today, using recovery and sleep). It also gives example questions that differentiate it from raw data siblings like get_recovery and get_sleep.

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 explicitly says 'Use this to answer

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

get_workoutsA

Get a list of logged WHOOP workouts, each with sport type, duration, strain, average/max heart rate, and calories burned. Accepts either the last N days or an explicit historical start/end range (e.g. a specific past month). Returns a summary plus the individual workout records. Use this to answer questions about specific exercise sessions, now or in the past.

NameRequiredDescriptionDefault
endNoEnd date, exclusive, as YYYY-MM-DD. Use together with "start".
daysNoNumber of most recent days to look back (1-90). Omit if using "start"/"end" instead.
startNoStart date, inclusive, as YYYY-MM-DD. Use together with "end" to query a specific historical period instead of "days" — e.g. for all of March 2026: start="2026-03-01", end="2026-04-01".

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It describes the return format (list + summary) and parameter options. However, it does not explicitly state that this is a read-only operation, mention authentication needs, rate limits, or pagination behavior. The description is adequate but missing these behavioral hints.

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 three sentences long, front-loaded with the key fields and purpose. Every sentence adds value: first sentence lists what is returned, second explains the parameter options, third gives a usage directive. No wasted words.

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?

Given the tool's simplicity (3 optional parameters, no output schema, no annotations), the description is mostly complete. It covers the purpose, parameter semantics, and usage context. However, it does not mention behavior when no workouts are found, whether results are sorted, or any error conditions. Still, it is fairly thorough for a list tool.

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 100%, so the schema already documents the three parameters well. The description restates the two ways to specify time range (days or start/end) but does not add significant new meaning beyond what the schema provides. It adds value by mentioning the return structure (summary + records), but that is not parameter-specific.

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 a list of logged WHOOP workouts with specific fields (sport type, duration, strain, heart rates, calories). It distinguishes itself from sibling tools like get_recovery or get_sleep by focusing on exercise sessions, and explicitly mentions both current and historical queries.

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 explicitly says 'Use this to answer questions about specific exercise sessions, now or in the past.' It also explains the two date range options (days or start/end). While no explicit 'when not to use' or alternatives are given, the sibling tools are distinct enough that this guidance is sufficient for an agent.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv1.0.0
    • First observedget_profile
    • First observedget_recovery
    • First observedget_sleep
    • First observedget_strain
    • First observedget_training_recommendation
    • First observedget_workouts
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored across 6 tools

Disambiguation5/5

Each tool addresses a distinct WHOOP domain (recovery, sleep, strain, workouts, profile, training recommendation) with no overlap. The descriptions clearly differentiate the data each returns, making it easy for an agent to select the correct tool for a given question.

Naming Consistency4/5

All tool names follow a consistent 'get_' prefix with a noun representing the data type (recovery, sleep, strain, etc.). This is predictable and clear. The only minor deviation is the slightly longer 'get_training_recommendation' compared to the others, but it still fits the pattern.

Tool Count5/5

With 6 tools, the set is well-scoped for a WHOOP fitness tracker integration. Each tool represents a core data category a user would query, and there are no extraneous or missing tools that would make the surface too large or too small for the domain.

Completeness4/5

The tools cover the most common queries about WHOOP data: recovery, sleep, strain, workouts, profile, and training recommendations. A minor gap is the lack of tools to query cycle/physiological data, meal logging, or team features, but the core personal health metrics are well represented.

Maintenance

ActivityStale
ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Related MCP Servers