Skip to main content
Glama

Training plan and progress

get_plan
Read-only

Displays an interactive training-plan card to answer how training is going: week-by-week sessions marked done, missed, or ahead, plus the next session and recent runs or rides.

Instructions

How the user's training is going, drawn as an interactive plan card: their plan week by week, each session done, missed or ahead, and the next one; with nothing scheduled, their recent weeks of running and riding.

Call it first for any general question about training or a plan ("how's my training going", "how am I doing", "this week", "show my plan", "what's next", "today's session", "am I on track"), wherever the plan came from: a coach, an app, Garmin Coach or create_plan. Call it alone: its situation says where the user is (a block under way, about to start or just done; a race ahead with nothing scheduled; regular running; or getting going) and offers one next step. Recovery, readiness or fitness follow only when asked, or when the user takes up that offer. Without a create_plan plan it reads the calendar around this week. Sessions carry workout_id and schedule_id for moving or retuning; the next one carries its steps and target paces. For any other session's steps, paces, recoveries or cool-down, call get_workout with its workout_id: never guess them.

Done means run within a day either side of its date, or any day that week if started from its workout on the watch. A strength session counts if any strength activity is recorded in its own week, early included, never another week's. Off its own day it shows as moved.

When the user says they have just done a session, call this before saying whether Garmin has it: don't guess. A strength activity is the session done even if it was logged in a gym app; the sets and weights aren't needed to count it. If a session isn't in Garmin but the user says they did it, trust them and suggest recording it on the watch next time. If what they did matters for what comes next and they haven't said, ask for a line. After a hard or long session in the last two days, ask once, in one short line, how it felt, and use the answer; not after an easy run.

The card draws the plan, so don't list it: add what it can't say, such as how the week is going. Each call draws it again, so answer follow-ups from that result; call again only when something may have changed (a session done, a workout moved or added, a new day) or the user asks to see it again: runs sync through the day, so after any of those the earlier answer goes stale. Don't call it for a specific question about a run, sleep, readiness, recovery, fitness or shoes.

Args: label: The code of a plan made with create_plan, e.g. "HM". Omit it for the plan running now, or the calendar.

Input Schema

NameRequiredDescriptionDefault
labelNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark it read-only/non-destructive, and the description layers on substantial operational context: the freshness/staleness model ('runs sync through the day, so the earlier answer goes stale'), the matching semantics for what counts as 'done' (within a day either side, watch-started, strength-in-own-week), and the card-drawing side effect plus the instruction not to re-list the plan.

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?

Long but justified by the amount of routing and state-management behavior it has to encode, and it is front-loaded with purpose then usage before edge cases. There is some redundancy ('don't guess' restated, repeated emphasis on what counts as done) that could be tightened without losing information.

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 not be described, and the description still covers what the schema cannot: cross-tool handoff for session details (get_workout with workout_id), the caching contract, how to reconcile Garmin data with the user's claim of having done a session, and when to probe about how a hard session felt. 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.

Parameters4/5

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

Schema coverage is 0%, so the description must carry the single parameter, and the Args block does: 'the code of a plan made with create_plan, e.g. "HM"' and 'Omit it for the plan running now, or the calendar.' This adds real meaning over a bare nullable string, though 'the calendar' as a fallback is left somewhat underspecified.

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 ('How the user's training is going, drawn as an interactive plan card') and enumerates exactly what the card contains: plan week by week, each session done/missed/ahead, next session. It explicitly separates itself from get_workout (session steps/paces) and from the recovery/readiness/fitness siblings, so an agent can pick it without opening the 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?

Gives explicit trigger phrases ('how's my training going', 'this week', 'what's next'), states 'Call it first for any general question about training', and names the exclusions ('Don't call it for a specific question about a run, sleep, readiness, recovery, fitness or shoes'). It also states when to re-call versus answering from the prior result (session done, workout moved, new day, user asks to see it again).

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