Wellness Project

list_workouts

Read-onlyIdempotent

List workout sessions in a date range plus user-marked Rest Day, Sick Day, or Travel Day context. Day context is returned even when that date has no workout. Treat context labels as explanatory context, not workouts; Travel Day can coexist with training.

Use before get_workout to find a session ID, or to answer training-history questions. Each workout row includes ID, date, focus type, location, and session-level NSI with rating.

DATE RANGE: one call covers the requested span, internally reading bounded 90-day slices. Explicit ranges can be up to 3660 days. Do not make sequential list_workouts calls to cover one user-requested range.

ALL HISTORY: when the user asks for "all", "ever", or their full workout history, set all_history=true. The tool finds the earliest stored workout (respecting activity_type when supplied). If history exceeds 3660 days, it covers the most recent 3660 days and explicitly reports the older stored start date instead of throwing.

OUTPUT BOUND: at most 250 workout rows are emitted. When more match, the response reports how many were omitted (or an honest lower bound for an exercise filter), the earliest returned/scanned date, and tells you to narrow with activity_type, exercise_name, or dates.

FILTERS: activity_type matches the stored workout focus type case-insensitively. exercise_name keeps only sessions containing that exercise in workout sets. Use activity_type for imported modalities such as Stair Stepper; use exercise_name for strength-history questions. Both filters may be combined.

INFER: default start_date to 7 days ago, end_date to today. User-specified dates or years are authoritative. Widen freely for the period the user actually requested.

SAVED WORKOUTS: set saved_workouts=true to list the user's reusable Saved Workouts library instead of completed workout history. Saved workout IDs are separate from workout session IDs.

Input Schema

TableJSON Schema

Name	Required	Description
`end_date`	No	End of date range. Format: YYYY-MM-DD. Optional — defaults to today.
`start_date`	No	Start of date range. Format: YYYY-MM-DD. Optional — defaults to 7 days ago.
`all_history`	No	Set true for all stored workout history instead of the recent default. Finds the earliest stored workout automatically; activity_type narrows that earliest-date lookup when present.
`activity_type`	No	Stored workout focus type to match case-insensitively, for example Stair Stepper. Defaults to no activity-type filter.
`exercise_name`	No	Exercise name that must appear in the workout sets, matched case-insensitively. Defaults to no exercise filter.
`saved_workouts`	No	When true, list reusable Saved Workouts instead of completed workout sessions. Defaults to false.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes	Human-readable result text returned by the tool.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 2, 2026

addedInput schema / properties / all_history

Added value: +{
+  "description": "Set true for all stored workout history instead of the recent default. Finds the earliest stored workout automatically; activity_type narrows that earliest-date lookup when present.",
+  "type": "boolean"
+}

Changed2 schema fields changedOct 1, 2026

addedInput schema / properties / activity_type

Added value: +{
+  "description": "Stored workout focus type to match case-insensitively, for example Stair Stepper. Defaults to no activity-type filter.",
+  "type": "string"
+}

addedInput schema / properties / exercise_name

Added value: +{
+  "description": "Exercise name that must appear in the workout sets, matched case-insensitively. Defaults to no exercise filter.",
+  "type": "string"
+}

Changed1 schema field changedSep 7, 2026

addedInput schema / properties / saved_workouts

Added value: +{
+  "description": "When true, list reusable Saved Workouts instead of completed workout sessions. Defaults to false.",
+  "type": "boolean"
+}

First observedAug 2, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds substantial operational context beyond them. It discloses internal 90-day slicing, a 3660-day cap, output bound of 250 rows, what happens when results are omitted, and how all_history handles older stored start dates. These details are exactly the kind of behavioral context an agent needs to invoke the tool correctly.

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 long but well-structured with capitalized section headers that front-load the core purpose and then handle date ranges, all-history behavior, output bounds, filters, inference, and saved workouts. Most sentences earn their place by preventing incorrect invocations, though some return-field detail overlaps with the existing output schema. It is appropriately sized for a complex, multi-mode listing tool, but not maximally tight.

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 six optional parameters, a rich schema, an output schema, and many siblings, the description is complete enough for correct invocation. It covers filtering, defaults, pagination-like bounds, all-history edge cases, saved workouts, and sibling routing. Nothing critical to selecting or calling the tool is missing.

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?

Although schema coverage is 100%, the description adds meaningful parameter semantics beyond the schema. It explains when to set all_history, how activity_type and exercise_name differ in practice, that both filters may be combined, and that saved_workouts switches to a separate Saved Workouts library with distinct IDs. It also gives date-inference rules and treats user-specified dates as authoritative.

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 states a specific verb and resource: list workout sessions in a date range, plus Rest Day/Sick Day/Travel Day context. It clearly distinguishes the tool from siblings by explaining that it returns session IDs for use before get_workout and that it handles training-history questions. The added warning that context labels are not workouts further sharpens the tool's purpose.

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 gives explicit when-to-use guidance: before get_workout to find a session ID, for training-history questions, for all-history queries, and for saved-workout library listing. It also provides when-not guidance by saying not to make sequential list_workouts calls to cover one range and by distinguishing activity_type from exercise_name filter use cases. Alternative sibling tools are not exhaustively named, but the key routing decisions are covered.

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

All Wellness Project tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.