Schedule a cron job with human-friendly frequency presets, eliminating the need to manually format cron syntax.
Create a cron job using a human-friendly schedule preset without manually formatting cron syntax
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Command or script to execute | |
| frequency | Yes | Human schedule preset |
Changes observed during successful MCP inspections.
v2.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It discloses the one meaningful trait beyond the schema — that frequency is a preset rather than a raw expression — but says nothing about execution context (the command runs on the server), whether the job is active immediately, permission requirements, or what happens on invalid commands.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the distinguishing concept (preset vs manual cron syntax) appears immediately and the sentence ends before adding anything redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with no annotations and no output schema, the definition covers what the tool does but not the operational context an agent needs — how it differs from create_cron_job / edit_cron_job, and any activation or permission behavior. Adequate but visibly thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the frequency enum with all nine presets is fully spelled out in the schema, so the baseline applies. The description reinforces that the preset is a human schedule abstraction but adds no constraint on the command string (e.g. shell vs binary path, character limits).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('Create') plus resource ('cron job') with a qualifier that distinguishes it from the raw-syntax sibling: it takes a 'human-friendly schedule preset' rather than a cron expression. The contrast with create_cron_job is implied but the sibling is never named, so differentiation requires an inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without manually formatting cron syntax' implies the when-to-use case (prefer this over the manual cron-expression tool), but there is no explicit routing statement, no mention of the alternative by name, and no exclusion or prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.