Quantified Self MCP Server

Overview Schema Source Related Servers Discussions Admin

Read workout sessions

read_workout_sessions

Read-onlyIdempotent

Retrieve individual workout sessions, most recent first, with activity, timing, intensity, and heart rate so you can review specific exercise sessions rather than daily totals.

Instructions

Read individual workout sessions (not the daily_metrics workout_minutes total), most recent day first. Use this to see what each workout actually was — activity, timing, intensity, heart rate — rather than just a day's summed minutes.

Use this tool when:

the user asks about workouts/exercise sessions specifically (e.g. "what workouts did I do this week?", "show my recent gym sessions").

Do not use this tool when:

the user just wants the daily workout_minutes total, not individual sessions -> use read_health_data or get_metric_history instead.

Privacy note: this server and its SQLite file are entirely local, but the data returned by this tool becomes part of the conversation sent to whatever model the calling client is configured with. If that model runs in the cloud rather than on your machine, treat this the same as pasting the data into a chat with that provider.

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": "read_workout_sessions"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum rows to return, 1 to 1000 (default 200).
`end_date`	No	Only return sessions on/before this date (YYYY-MM-DD). Omit for no upper bound.
`start_date`	No	Only return sessions on/after this date (YYYY-MM-DD). Omit for no lower bound.
`activity_type`	No	Only return sessions of this activity type. Omit for all types.

Output Schema

Name	Required	Description	Default
`count`	Yes
`sessions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.0.36Nov 5, 2026
- addedOutput schema / properties / sessions / items / properties / duration_minutes / anyOf
```
Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedOutput schema / properties / sessions / items / properties / duration_minutes / type
```
Removed value: -"integer"
```

Changed1 schema field changedv1.0.31Oct 20, 2026

changedInput schema / properties / limit / description

Previous value: -"Maximum rows to return (default 200)."New value: +"Maximum rows to return, 1 to 1000 (default 200)."

Addedv1.0.16Sep 15, 2026
Removedv1.0.15Sep 15, 2026
Addedv0.3.0Sep 13, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, but the description adds behavior they cannot express: result ordering ('most recent day first') and the fact the output is session-level rather than aggregated. The privacy note — that returned data enters the conversation sent to the calling client's model — is genuinely load-bearing context an agent would otherwise not have.

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?

Front-loaded with the core statement and sibling differentiation before the when/when-not lists, which is the right order. The privacy paragraph is several lines long and slightly over-weighted for a selection decision, but it is substantive rather than filler, so only a small deduction.

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?

With an output schema present, return values need no explanation, and the description covers scope, granularity, ordering, alternatives and data-handling. The only minor gap is truncation behavior — that limit defaults to 200 and caps at 1000 is left entirely to the schema, which matters for a session-listing tool that can silently omit older rows.

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%, with each of limit, start_date, end_date and activity_type already documented including format (YYYY-MM-DD) and omit-for-unbounded semantics. The description adds no meaning beyond that — the 'this week' example only implies date-range filtering. Baseline 3 applies when the schema carries the parameter burden.

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?

States a specific verb and resource ('Read individual workout sessions') and immediately disambiguates it from the aggregated daily workout_minutes total, so an agent can distinguish it from get_metric_history or read_health_data without opening any schema. It also names the record fields returned (activity, timing, intensity, heart rate), which pins down the granularity.

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?

Explicit 'Use this tool when' examples ('what workouts did I do this week?') and an explicit 'Do not use this tool when' branch that routes to read_health_data or get_metric_history for summed minutes. Both the positive condition and the exclusion are stated, which is the full bar for this dimension.

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