Skip to main content
Glama

Create cron trigger

crons_create

Creates a cron trigger that fires on a schedule to launch agents from profiles or send inputs to agents, with missed firings coalesced.

Instructions

Creates a cron trigger that fires on a schedule. A trigger targeting an agent profile launches a new agent from the profile's current config on each firing; a trigger targeting an agent sends an input to that agent. Missed firings are coalesced, matching standard cron behavior: if one or more scheduled times pass while firing is delayed, the trigger fires once for the oldest missed time and then resumes its schedule from the current time, without retroactively firing for the other missed times.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cronYesStandard five-field cron expression (minute, hour, day of month, month, day of week). `TZ=`/`CRON_TZ=` prefixes are rejected; set the `timezone` field instead.
nameYesHuman-readable name. Spaces and punctuation are allowed; leading or trailing whitespace and invisible or control characters are not.
orgIDYes
targetYes
enabledNo
timezoneNoIANA time zone the schedule is evaluated in.
projectIDYes
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.8/5.0
Behavior4/5

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

Annotations establish a non-read-only, non-idempotent, open-world create. The description adds genuinely non-obvious runtime behavior: missed firings are coalesced, the trigger fires once for the oldest missed time, and the schedule resumes from the current time without retroactive firings. That is real operational context beyond the annotations, though it says nothing about authorization requirements or side effects of creating a trigger against an agent.

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, then target semantics, then firing behavior. The coalescing sentence is long and slightly overloaded, but every clause conveys distinct behavior an agent needs. No filler.

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?

With no output schema and 8 parameters including a discriminated nested `target`, the agent gets no indication of what the call returns (trigger ID, initial state) and no coverage of the integration target branch or the default state of `enabled`. The behavioral explanation of coalescing is valuable, but the definition is not fully complete for a tool 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 coverage is 50%, but the well-documented fields (cron, name, timezone, message_template) already carry strong inline descriptions, so the schema does the heavy lifting. The description does add semantic value for the polymorphic `target` parameter by describing profile vs agent firing behavior, but it omits the integration target variant entirely and says nothing about `enabled` or how orgID/projectID scope the trigger.

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 ("Creates a cron trigger that fires on a schedule") and immediately disambiguates the tool from its crons_list/get/update/delete siblings by explaining what the created trigger does at runtime. The agent knows exactly what artifact this produces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied through the target-type explanation: an agent profile target launches a new agent per firing, an agent target sends an input. That helps the caller pick a target, but there is no explicit when-to-use guidance, no prerequisites (org/project scoping, permissions), and no mention of crons_update as the alternative when a schedule already exists.

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