technogym-mcp

list_workout_sessions

Retrieve workout sessions in a date range, newest first, with session IDs, dates, duration, MOVEs, calories, and exercise counts. Filter to gym-floor workouts or include all activity types.

Instructions

List workout sessions in a date range, newest first. Each item has session_id and date, which together identify the session for the detail tools, plus name, duration, MOVEs, calories and exercise counts.

Args: from_date: ISO date (YYYY-MM-DD). Defaults to 30 days before to_date. to_date: ISO date (YYYY-MM-DD). Defaults to today. only_workouts: Only gym-floor workout sessions (default). False includes every activity type (classes, outdoor, ...).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_workout_sessions"
  }
}

Input Schema

Name	Required	Description	Default
`to_date`	No
`from_date`	No
`only_workouts`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 8, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the transparency burden and does so well: it states ordering (newest first), default date window (from_date defaults to 30 days before to_date, to_date defaults to today), and the filtering effect of only_workouts. It also enumerates the fields returned per item. It doesn't mention pagination or auth, but those are not central to this read-only list call.

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 compact and front-loaded: purpose and ordering first, then item fields, then a tidy Args block. Every sentence adds useful information with no redundancy.

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?

For a three-optional-parameter list tool with an output schema, the description covers the essentials: date semantics, sorting, filtering, and identification of sessions for detail calls. Minor omissions such as pagination and date-boundary inclusivity do not block correct invocation.

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 description coverage is 0%, so the description must define every parameter, and it does: from_date and to_date are ISO dates with documented defaults, and only_workouts controls activity-type filtering. This fully compensates for the empty 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 opens with a precise verb-resource pair ('List workout sessions') and immediately adds scope: 'in a date range, newest first.' It also distinguishes itself from detail-oriented siblings by stating that session_id and date 'identify the session for the detail tools.'

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 Args block gives concrete defaults and explains that only_workouts defaults to gym-floor sessions while false includes all activity types. It clearly implies when to use this list tool and points toward detail tools for per-session lookup, though it doesn't explicitly name a sibling or state when not to use it.

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

Deploy Server