Skip to main content
Glama

scheduleDashboardRefresh

Schedule, change, or stop automatic dashboard page refreshes using cron-based local times, and check upcoming runs. Use it to keep Garmin dashboard data current 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). last is the last automatic run: its time and the pages that it could not update, with the error. A page shows a note when its update is more than 1 hour late: last tells why. 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 observedv0.10.0

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 so thoroughly: it discloses the underlying scheduler (launchd/cron/Task Scheduler), that it runs with no assistant open, that it destroys coach notes, that the computer must be on at that time, and what `last`/`next` report. These are the kinds of destructive side effects and constraints an agent needs before calling.

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 is front-loaded in the first sentence and the rest is organized from usage rules to side effects to parameter details. It is on the long side and a few clauses (e.g. the late-update note for `last`) are tangential, but almost every sentence adds operative 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?

There is no output schema, yet the description explains the reply shape (`next` with upcoming local-time runs and instruction to relay them), plus `last` diagnostics. Combined with the prerequisites and scheduling constraints, an agent has enough to call and report results correctly.

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 100%, so baseline would be 3, but the description goes well beyond the schema: it explains the 5-field cron format in local time, gives an example, requires a minimum 1-hour gap between runs, defines `path` defaulting to the main page, and specifies that `off` without `path` stops every page. Each parameter's interaction with the others is made explicit.

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?

The first sentence gives a specific verb (enables/changes/stops) and resource (automatic refresh of a dashboard page), immediately distinguishing this from the sibling dashboard tools (writeDashboard, editDashboard, showDashboard, getDashboardData). An agent can select 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?

It states an explicit precondition ('only when the user asks for it or says yes to the question of a dashboard prompt') and a prerequisite ('The page must exist (writeDashboard first)'). The `off` semantics and no-argument read-only mode are also spelled out, leaving no ambiguity about when to invoke it.

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