Skip to main content
Glama
Thecimal

Quantified Self MCP Server

by Thecimal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Read workout sessions

read_workout_sessions
Read-onlyIdempotent

Retrieve individual workout sessions, newest first, to review activity, timing, intensity, and heart rate instead of daily workout-minute 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.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum rows to return, 1 to 1000 (default 200).
end_dateNoOnly return sessions on/before this date (YYYY-MM-DD). Omit for no upper bound.
start_dateNoOnly return sessions on/after this date (YYYY-MM-DD). Omit for no lower bound.
activity_typeNoOnly return sessions of this activity type. Omit for all types.

Output Schema

NameRequiredDescriptionDefault
countYes
sessionsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.31
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum rows to return (default 200)."New value: +"Maximum rows to return, 1 to 1000 (default 200)."
  2. Addedv1.0.16
  3. Removedv1.0.15
  4. Addedv0.3.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuinely non-obvious behavioral disclosure the annotations cannot carry: returned data propagates into the conversation sent to a possibly-cloud model, which is an important privacy/egress consideration.

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?

Purpose, ordering, when/when-not and privacy note are front-loaded and each section earns its place. The privacy paragraph is longer than strictly needed for tool selection, which keeps this from a 5.

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?

An output schema exists so return values need no explanation, annotations cover the safety profile, and all four parameters are documented. Purpose, routing, ordering and data-egress caveats are all present — nothing an agent needs to call this correctly is missing.

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 coverage is 100%, so limit, start_date, end_date and activity_type are already fully documented in the schema with formats and defaults. The description adds only the implicit 'most recent day first' ordering, not parameter-level meaning, so the baseline 3 applies.

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+resource (read individual workout sessions) and immediately distinguishes it from the daily_metrics workout_minutes total. An agent can tell this apart from read_health_data/get_metric_history without opening any schema.

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' and 'Do not use this tool when' sections, with concrete user-phrasing examples and named alternatives (read_health_data, get_metric_history) for the excluded case. Routing is fully determined.

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

Deploy Server

Other Tools