Skip to main content
Glama
lastping-dev

LastPing

by lastping-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

Reconcile discovered jobs as monitors

discover_monitors_reconcile
Idempotent

Turn a repo or host scan into monitors: create one per unmonitored source while leaving existing monitors untouched, so re-runs give safe drift detection.

Instructions

Requires the write scope or higher. Turns a scan of a repository or host (sources, every scheduled job found) into monitors. Creates one monitor per source not already monitored; never deletes, pauses or edits existing monitors, so a scheduled re-run is safe drift detection. Returns created, existing (unmodified, hand-tuned values intact) and orphaned (source not in this scan; still running and alerting). Each created monitor can page a person; this endpoint has no delete path. source_kind plus source_ref is the diff key, so source_ref has to stay stable: a changed ref creates a duplicate; a crontab ref names the file and the command, so each line is its own source. Kinds: 'crontab' (crontab -l, /etc/cron.d/*, /etc/crontab), 'github-actions' (on.schedule.cron), 'k8s-cronjob' (spec.schedule), 'systemd-timer' (OnCalendar=). A source without schedule_cron becomes on-demand. crontab and systemd-timer fire in the host's local time (timedatectl show -p Timezone --value or readlink /etc/localtime prints it); github-actions and k8s-cronjob in UTC. A stated tz is stored as given: the API cannot tell a guessed 'UTC' from one read from the host. list_monitors shows each source.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourcesYesThe full scan as a JSON array string, e.g. '[{"source_kind":"crontab","source_ref":"/etc/cron.d/backup:/usr/local/bin/backup.sh","schedule_cron":"0 3 * * *","tz":"Europe/Berlin"}]'. Fields: source_kind, source_ref (required), name (default source_ref), schedule_cron (5-field, when one was read), tz (IANA zone the cron fires in; required on a crontab or systemd-timer entry with schedule_cron), suggested_expect_every_s (overrides the silence floor). An omitted source is reported orphaned; '[]' orphans every discovered monitor, deleting none. At most 1000 entries; a repeated source_kind/source_ref pair is rejected. The 100-monitor cap covers the whole batch; one invalid entry rejects it all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.17
    • changedInput schema / properties / sources / description
      Previous value: -"The complete scan result: a JSON ARRAY supplied as a string, one entry per scheduled job, e.g. '[{\"source_kind\":\"crontab\",\"source_ref\":\"/etc/cron.d/backup:/usr/local/bin/backup.sh\",\"name\":\"nightly backup\",\"schedule_cron\":\"0 3 * * *\",\"tz\":\"Europe/Berlin\"}]'. Fields per entry: source_kind and source_ref (both REQUIRED — an entry missing either cannot be matched against an existing monitor and would be re-created on every scan), name (optional display name; falls back to source_ref), schedule_cron (optional 5-field cron expression, sent only when you actually read one), tz (the IANA zone that cron fires in — REQUIRED for a crontab or systemd-timer entry carrying a schedule_cron, read from the host, never guessed), and suggested_expect_every_s (optional; state the silence floor outright when you know the real cadence better than the cron expression does — it WINS over the value derived from the cron). Send the WHOLE scan in one call: this is a diff, so a source you leave out is reported as orphaned rather than ignored. Send '[]' to report that the scan found nothing — every discovered monitor is then listed as orphaned, and none of them is deleted. At most 1000 entries per call, each source_kind/source_ref pair at most once (a duplicate is rejected outright, not merged), and the project's 100-monitor cap is applied to the whole batch at once — if the batch would exceed it, NOTHING is created. Nothing is written unless every entry validates: one bad entry rejects the entire payload and leaves no monitors behind."New value: +"The full scan as a JSON array string, e.g. '[{\"source_kind\":\"crontab\",\"source_ref\":\"/etc/cron.d/backup:/usr/local/bin/backup.sh\",\"schedule_cron\":\"0 3 * * *\",\"tz\":\"Europe/Berlin\"}]'. Fields: source_kind, source_ref (required), name (default source_ref), schedule_cron (5-field, when one was read), tz (IANA zone the cron fires in; required on a crontab or systemd-timer entry with schedule_cron), suggested_expect_every_s (overrides the silence floor). An omitted source is reported orphaned; '[]' orphans every discovered monitor, deleting none. At most 1000 entries; a repeated source_kind/source_ref pair is rejected. The 100-monitor cap covers the whole batch; one invalid entry rejects it all."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (idempotentHint, destructiveHint=false) by spelling out that no existing monitor is deleted, paused, or edited, that hand-tuned values stay intact, that orphaned sources keep running/alerting, and that there is no delete path. It also discloses the source_ref stability trap that silently creates duplicates.

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 the scope requirement and the core action, and every sentence carries information. It is dense to the point of being a wall of text, and some tz detail sits awkwardly after the kind list, but nothing is truly wasted.

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 single-parameter tool with no output schema, the description supplies the return contract (created/existing/orphaned) and the safety profile an agent needs. Batch limits live in the schema and the destructive/idempotency picture is fully covered, leaving no material gap.

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 already 100%, so the baseline is 3, but the description adds meaning the schema lacks: source_kind+source_ref as the diff key, the stability requirement on source_ref, the enumerated kind values, and the local-time vs UTC firing rules per kind.

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: turning a scan of a repo/host into monitors, creating one per unmonitored source. It distinguishes itself from single-target siblings like create_monitor by describing the batch diff/reconcile semantics and naming list_monitors for the read-side view.

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?

Gives clear context (after a repository/host scan) and the recommended cadence (a scheduled re-run is safe drift detection), plus the write-scope prerequisite. It stops short of explicitly naming when to prefer create_monitor instead, so no explicit exclusion is provided.

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

Deploy Server

Other Tools