Skip to main content
Glama

scheduleDashboardRefresh

Schedule, change, or stop automatic dashboard refreshes with a cron expression so Garmin training data updates at set times, even without an assistant open.

Instructions

Turns on, changes or stops the automatic refresh of a dashboard page. Use it only when the user asks for it or says yes to the question of a dashboard prompt. A job in the scheduler of the computer (launchd, cron or Task Scheduler) replaces the data of the page at the given times, also with no assistant open. The refresh removes the coach notes, because old notes do not agree with new data. The computer must be on at that time. The page must exist (writeDashboard first). cron: convert what the user says, in any language, into a 5-field cron expression in local time: minute hour day-of-month month weekday, numbers only (0 = Sunday), e.g. "0 7 * * 1-5" for weekdays at 7. Two runs must be at least 1 hour apart. The cron is for all scheduled pages; path adds that page (default the main page); off stops the refresh of path, or of every page when no path is given. Without arguments it only reads. The reply has next, the next runs in local time: tell them to the user in their language, so they can check the schedule.

Input Schema

NameRequiredDescriptionDefault
offNoStop the refresh
cronNominute hour day-of-month month weekday, e.g. "0 7 * * *"; default 0 7 * * *
pathNoThe .html file; relative paths are inside the data dir

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/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: it discloses that a real OS scheduler (launchd/cron/Task Scheduler) runs the job outside the assistant, that the machine must be powered on, that coach notes are destroyed on refresh, and that runs must be >=1 hour apart. These are exactly the side effects and constraints an agent must know before mutating state.

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 and the user-consent rule are front-loaded, and nearly every sentence carries needed information. It is dense and long, and the trailing note about reporting `next` to the user is slightly tangential, but the cron semantics justify most of the length.

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?

No output schema exists, yet the description explains the reply contains `next` with upcoming runs in local time and instructs the agent to relay them. Combined with prerequisites, side effects, and full parameter semantics, an agent can call this correctly without further inference.

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 already 100%, but the description goes well beyond it: it specifies cron as a 5-field local-time expression, numbers only, 0=Sunday, gives a worked example, states the 1-hour spacing rule, explains that cron applies globally while `path` scopes to one page (default main page), and that `off` without `path` stops every page.

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 triad and resource: 'Turns on, changes or stops the automatic refresh of a dashboard page.' That clearly separates it from writeDashboard/editDashboard, which author page content rather than scheduling.

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 an explicit activation condition ('only when the user asks for it or says yes'), a prerequisite ('The page must exist (writeDashboard first)'), and a no-arg read-only mode. The agent knows both when to call it and when not to.

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