Skip to main content
Glama

create_plan

Create a whole training block at once: each session built as a structured workout and scheduled on its date in the user's Garmin calendar. Every session is checked before anything is created, so a mistake leaves no half plan. Each workout's name ends with the plan code after a middle dot, "Threshold 5x1k · HM"; nothing is stored outside Garmin. The result is the new block drawn as an interactive plan card.

Args: goal: What the block is for, e.g. "Half marathon, 1:40, 15 November". sessions: One per session, any order, at most 150: "date" (YYYY-MM-DD, today to 30 weeks out), "name" (short, as on the watch: "Long run 18k"), "steps" (as for a single workout), and optional "sport" (running by default), "description", "pool_length_meters" (25 by default) and "phase" (one short word such as "Base", "Build", "Peak" or "Taper"; the card bands the weeks by it). Days without a session are rest days. label: 2 or 3 letters or digits for the plan code, e.g. "HM", "10K", "MAR". From the goal when omitted. name: A short name for the block, shown as the card's title, e.g. "Marathon build". method: The methodology in a few words, shown under the name, e.g. "80/20". milestones: Up to 4 points on the way to the goal, drawn as a timeline: {"label": "Half check", "date": "2026-11-29", "target": "1:22"}, date and target optional.

Input Schema

NameRequiredDescriptionDefault
goalYes
nameNo
labelNo
methodNo
sessionsYes
milestonesNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only give the basic profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), but the description adds substantive behavior: validation happens before anything is created so a failed call leaves no half plan, nothing is stored outside Garmin, and workout names get the plan code appended after a middle dot. These are the exact details an agent needs to reason about failure modes and side effects.

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 action and atomicity guarantee, then a structured Args block that is easy to scan. It is on the long side and includes some polish detail (the card bands weeks by phase, the middle-dot naming rule), but nearly every sentence provides decision-relevant 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?

For a six-parameter, nested-array write tool with no schema descriptions, the description supplies everything missing: parameter semantics, constraints, atomicity, storage location, and the result ('a new block drawn as an interactive plan card'). The output schema covers return shape, so nothing essential is absent.

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 coverage is 0%, so the description carries the full burden and does so thoroughly: every parameter is explained, including defaults (running, 25 m pool, label derived from goal) and the shape of each session object with its date range (today to 30 weeks out) and nested steps/phase fields. The milestones structure is spelled out with an example.

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 with scope: 'Create a whole training block at once' where each session becomes a structured workout scheduled on the Garmin calendar. The 'whole block at once' framing distinguishes it cleanly from the single-item sibling create_workout without needing to name it.

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?

Clearly conveys the batch context (all sessions validated first, days without a session are rest days, at most 150 sessions) so an agent knows when this tool fits. It never explicitly says to use create_workout for one-off sessions or how this relates to schedule_workout, so the alternative routing is left implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources