Skip to main content
Glama

Update cron trigger

crons_update
Destructive

Updates a cron trigger's schedule, message template, or enabled state. To change its target, delete it and create a new trigger.

Instructions

Updates the schedule, message template, or enabled state. The target is immutable; delete the trigger and create a new one to retarget.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cronNoStandard five-field cron expression (minute, hour, day of month, month, day of week). `TZ=`/`CRON_TZ=` prefixes are rejected; set the `timezone` field instead.
nameNoHuman-readable name. Spaces and punctuation are allowed; leading or trailing whitespace and invisible or control characters are not.
orgIDYes
targetNo
enabledNo
timezoneNoIANA time zone the schedule is evaluated in.
projectIDYes
cronTriggerIDYes
message_templateNoGo text/template rendered on each firing to produce the message sent to the target. The template receives a `trigger` value with `name`, `fired_at`, `last_fired_at`, and `local_date` fields. Timestamps remain UTC; local_date is the scheduled occurrence's ISO date in the schedule timezone. Required for agent and profile targets; omitted for integration targets, which use their own settings. Rendering is capped at 64 KiB of output and one second of wall-clock time, and `printf` width and precision specifiers are capped at 1024; a firing whose template fails to render is recorded in `failure_report` without sending a message.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful immutability constraint, but it never clarifies whether this is a partial or full replacement update (schema hints suggest omitted fields are preserved) — a meaningful gap for a mutation tool.

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

Conciseness5/5

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

Two sentences, front-loaded with what is mutable and followed by the immutability caveat. No filler, no restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the tool has 9 parameters including a nested oneOf/discriminated target. The description addresses immutability but omits partial-update semantics, timezone handling, and the conditional requirement of message_template per target type. Adequate but leaves real gaps for a mutation of this complexity.

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 only 44% across 9 parameters, so the description is expected to compensate. It lists three updatable fields (schedule, template, enabled) but says nothing about name, timezone, or how narrow UUID/ID parameters and the nested target discriminator behave. The schema's own field descriptions for cron, message_template, and timezone carry most of the load.

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 description gives a specific verb plus the exact mutable surface ('schedule, message template, or enabled state') and separates itself from crons_create/crons_delete by naming the delete-and-recreate workflow for retargeting. An agent can distinguish this from the other crons_* siblings 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a clear when-not/alternative: the target is immutable, so changing it requires deleting and recreating. That is genuinely actionable routing guidance. It stops short of stating other conditions (e.g., that it is a partial update, or when to prefer this over reading first).

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