Skip to main content
Glama

timers/list

Read-onlyIdempotent

List systemd timers to see scheduled jobs, their next and last runs, persistence, and results. Read-only; use it to answer what runs on a schedule and when.

Instructions

Lists the systemd timers of the host - systemd's scheduler, the modern counterpart of cron - each with the unit it starts, its schedule (OnCalendar= and monotonic settings such as OnBootSec=), its next and last run, whether it is Persistent (catches up runs missed while the host was off) and its last result. Read-only. Use it to answer "what runs on a schedule, and when next": services/list shows only .service units, so timers never appear there. To inspect the unit a timer starts, use linuxctl describe system <name> or the service://<name>/status resource; a timer's own state is in this listing. Times are RFC 3339 UTC, and never means systemd reports none (a timer that has not fired yet, or one with no upcoming trigger). pattern accepts a leading and/or trailing * (apt*, *.timer, *daily*); the timer name includes .timer. Unprivileged calls need the host's systemd bus (a bare-metal or VM host); inside a container use privileged: true, which joins the host. output_format: json returns an array with the same fields; text is the default. Empty result means no timer matched. Managing timers (start, stop, enable) is not offered by this tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
patternNoWildcard on the timer name (e.g. 'apt*', '*.timer', '*daily*'); no other wildcards
privilegedNoRun as root (needed inside a container to reach the host's systemd; needs a grant)
active_stateNoOnly timers in this active state (e.g. 'active', 'inactive', 'failed')
output_formatNo'json' (also yaml/table/wide, which return the same JSON) for an array of objects; default is text

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, so safety is covered; the description adds genuinely new behavioral context beyond that: unprivileged calls require the host's systemd bus, containers need `privileged: true` (which joins the host), `never` means systemd reports no trigger, and an empty result means no timer matched. This is rich disclosure that goes well past the structured fields.

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 the key sibling distinction, then behavior and edge cases. It is dense and lengthy, but nearly every sentence carries operational content (RFC 3339 UTC, `never` semantics, container privilege, empty-result meaning) rather than padding.

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?

With no output schema, the description compensates by describing the returned fields (unit started, schedule, next/last run, Persistence, last result), the JSON array shape, timestamp format, and edge-case meanings. An agent has everything needed to call and interpret this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description restates `pattern` wildcard rules, `output_format: json` returning an array, and the `privileged` container rationale, adding only slight emphasis rather than new semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Lists the systemd timers of the host') and immediately grounds it with a definition ('systemd's scheduler, the modern counterpart of cron'). It explicitly distinguishes itself from the closest sibling by noting `services/list` shows only `.service` units, so an agent can tell them apart without opening a 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?

Explicitly names the question it answers ('what runs on a schedule, and when next'), routes inspection of a started unit to `linuxctl describe system <name>` or the `service://<name>/status` resource, and states the exclusions outright ('Managing timers (start, stop, enable) is not offered by this tool'). When-to-use, alternatives, and when-not are all present.

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