Skip to main content
Glama

writeDashboard

Generates or updates a Garmin training dashboard HTML page with recent weekly data and returns a data digest for coach notes; preview mode shows results without writing.

Instructions

Writes the training dashboard page (default /garmin-dashboard.html) with the data of the last weeks weeks, and returns its path and a short digest of the data (totals, weekly sums, load, best efforts, races, long runs, race predictions, strength top sets, readiness, fitness and form, HRV, recovery, fitness age, sync) for the coach notes. Without HRV and sleep data the digest has no readiness: give the verdict as n/a. An existing page keeps all its code, layout and widgets: its data is replaced. A page with different page code gets the page code of the server and keeps its layout and widgets; the result then has page: "upgraded", previousServer (the server version that wrote the page, n/a when unknown) and server. Every page from the template also gets the custom widgets of the widget library (/widgets.json), not placed on a board. On a page from the template, an edited board also gets the widgets that a release adds to its preset, one time; the result lists the ones that the page shows in addedWidgets (board -> widget ids). layout writes a new page from the template: preset (the default widgets) or blank (empty boards). It keeps the languages added with editDashboard languages. page writes your own page code instead; it must contain /* garmin-data:start /null/ garmin-data:end */. A replaced page is kept as .bak. The .bak keeps the page from before the build: a write that follows within 15 minutes (the notes, a new title) does not replace it. notes: at most 5 plain-text coach notes; the server escapes them. settings replace the page's settings (title, headline, sports, data to leave out, languages, themes); without them the page keeps its own. The page holds only the data, languages and themes they keep. pageLanguages in the result lists the languages of the page's Language menu, and settings the settings that the page keeps. missingProfileLanguage is the language of the Garmin profile when the page has no texts in it (it shows English); editDashboard languages adds it. missingWidgetTexts lists the custom widgets that miss texts in a language of the page, with those languages; editDashboard widgetTexts adds them. preview: true writes nothing: it returns the digest, the activities of each board and the settings of the page.

Input Schema

NameRequiredDescriptionDefault
pageNoYour own page code, with an empty garmin-data block, instead of the template
pathNoThe .html file; relative paths are inside the data dir
notesNoCoach notes, plain text; without notes the page has none
weeksNoWeeks to cover, default 12, max 52
layoutNoWrite a new page from the template with this layout
previewNoWrite nothing: return the digest, the activities of each board and the page settings
settingsNoThe page settings; replaces the page's own

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.0

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses that existing page data is replaced while code/layout/widgets survive, that a different page code triggers an upgrade with `page: "upgraded"`/`previousServer`/`server` in the result, that the prior page is kept as `<file>.bak` except within a 15-minute window, that notes are escaped and capped at 5, and that preview writes nothing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and return value are correctly front-loaded, and most sentences carry real information. However, the bulk arrives as a dense run-on with backticked identifiers interleaved mid-sentence and no segmentation, so the agent must parse carefully to extract the individual rules about upgrades, backups, and settings precedence.

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 mutation tool with 7 parameters, a nested settings object, no annotations, and no output schema, the description covers side effects, backup behavior, upgrade results, missing-language/widget-text signals, and preview mode. An agent could call it correctly and interpret the result without further information.

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 100%, so the baseline is 3; the description goes beyond it by specifying that `page` code must contain /* garmin-data:start */null/* garmin-data:end */, that `settings` fully replace the page's own settings, and that `layout` retains languages added via editDashboard. It adds meaningful semantics rather than restating the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb (writes) and resource (the training dashboard page), names the default file path, and states what is returned (path plus digest). Sibling differentiation is only implicit — editDashboard and showDashboard are referenced in passing for language/widget text edits, but the description never says outright which sibling to use for which job.

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?

It establishes clear usage contexts: `layout` for a fresh template page, `page` for your own code, `settings` to replace page settings, and `preview: true` to inspect without writing. It also routes two tasks to the alternative (editDashboard `languages` and `widgetTexts`), though it never states when NOT to use this tool versus editDashboard or showDashboard.

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