Daash

Overview Schema Source Related Servers Discussions Admin

create_plan

Build and schedule a whole training block from a goal: creates structured sessions, assigns each to its date, and shows the plan for approval before writing to Garmin calendar.

Instructions

Create a whole training block at once: every session built and put on its date.

You design the plan, from the user's goal, current fitness (get_fitness), readiness, history and a methodology; this builds each session as a structured workout and schedules it, so the whole block is on the watch in one go. Show the user the plan and get their agreement first: it writes to their real calendar. It answers with the new block drawn as a card, the same as get_plan, so no other call is needed to show it.

Each workout is named with a short plan code after a middle dot, "Threshold 5x1k · HM", which is how get_plan finds the block; nothing is stored outside Garmin. Every session is checked before anything is created, so a mistake in session 40 leaves no half plan behind.

Args: goal: What the block is for, e.g. "Half marathon, 1:40, 15 November". sessions: One per session, any order: "date" (YYYY-MM-DD, today to 30 weeks out), "name" (short, as on the watch: "Long run 18k"), "steps" (as for create_workout), and optional "sport" (running by default), "description", "pool_length_meters" for a swim (25 by default) and "phase": one short word such as "Base", "Build", "Peak" or "Taper", the same for every session in that phase; the card bands the weeks by it. Rest days are days with no session. At most 150. label: 2 or 3 letters or digits for the plan code, short because it ends every workout name: "HM", "10K", "MAR", "B1" for a base block. From the goal when omitted. name: A short name for the block, as the card's title: "Base block", "Marathon build". Two or three words, not the goal. method: The methodology in a few words, shown under the name: "Norwegian singles", "80/20", "Pfitzinger 18/55". 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. The goal race is usually last.

Input Schema

Name	Required	Description	Default
`goal`	Yes
`name`	No
`label`	No
`method`	No
`sessions`	Yes
`milestones`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.1Oct 26, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations it discloses the important traits: it writes to the real Garmin calendar, validates every session before creating anything ('a mistake in session 40 leaves no half plan behind'), stores nothing outside Garmin, and encodes a plan code in every workout name that get_plan later relies on. Those are exactly the side effects and invariants an agent needs before a bulk write.

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 purpose and confirmation requirement, then a structured Args block. It is long, but nearly every line carries information; the plan-code paragraph is slightly belabored for the space it takes.

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 6-parameter bulk mutation with nested free-form objects and an output schema, nothing essential is missing: validation behavior, naming convention, defaults, limits and the returned card are all covered, so the agent can call it correctly in one pass.

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 must carry the load and does: each arg is defined with examples, the sessions object's fields and defaults are spelled out (sport running, pool_length_meters 25, date range today to 30 weeks out, max 150), and the milestone object shape is given. This is well beyond what the bare schema provides.

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?

Opens with a specific verb and resource plus scope: 'Create a whole training block at once: every session built and put on its date.' That immediately separates it from create_workout (one workout) and schedule_workout (one session), so the sibling distinction is clear 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 about when to use it and what to do first: design from goal, fitness (naming get_fitness), readiness and history, then 'Show the user the plan and get their agreement first: it writes to their real calendar.' It also removes a follow-up call by stating the response is drawn like get_plan.

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