Cron MCP Skills

Cron MCP Skills

Use this skill when an agent needs to:

• poll for pending scheduled work
• act as the worker that processes claimed cron jobs
• mark jobs as completed after successful handling
• mark jobs as failed when execution cannot be completed
• inspect learned workflow candidates and stored workflow patterns

Do not use this skill when the agent needs to:

• create, update, remove, or manually enqueue cron jobs as the primary task
• debug or modify the cron server codebase
• answer general product questions about cron configuration without processing live queued work
• perform unrelated MCP tasks where no cron_poll call is needed

Routing Guide

Use this skill when:

• there may be pending work in the cron queue
• the agent must claim a lease with cron_poll
• the agent must process returned payloads and close the run with cron_complete or cron_fail
• the agent needs workflow-memory inspection before deciding whether to trust workflowMatch

Do not use this skill when:

• the user is only asking to register or edit cron definitions Use the cron management MCP tools directly instead.
• the task is to inspect source code or implement repository changes Use the coding workflow instead.
• there is no intention to call cron_poll, cron_renew, cron_complete, or cron_fail This skill is for worker-side execution, not generic reasoning.

Outputs and success criteria:

• a pending job is either completed or failed using the exact leaseToken returned by cron_poll
• long-running work renews its lease before expiry when needed
• workflow-related success or failure preserves outcomeMeta so workflow memory stays accurate
• if no actionable job exists, the agent says so clearly instead of fabricating work

See the reference guide for tool semantics and queue-state expectations. Use the example payloads when you need concrete job shapes for systemEvent and agentTurn work.

Workflow

1. Call cron_poll to fetch pending jobs.
2. Check whether the returned job includes workflowMatch.
3. If a workflow match is present, prefer the stored pattern version as guidance and fall back to direct payload handling when the live situation has drifted.
4. Choose the next job to process.
5. Execute the requested task using the job payload.
6. Report the outcome:
   • use cron_complete when processing succeeds
   • use cron_fail when processing fails

Edge Cases

• No jobs returned by cron_poll: Report that no scheduled work is currently available and stop.
• workflowMatch is absent: Execute directly from the returned job payload instead of assuming a learned workflow exists.
• workflowMatch exists but the live environment has drifted: Fall back to direct reasoning from the payload and fail the run with workflow metadata if the stored pattern should be deprecated.
• The task will exceed the lease TTL: Call cron_renew before the lease expires.
• A pattern is already deprecated: Treat it as inactive memory and do not trust it as execution guidance until a later active version exists.

Inspection Workflow

Use these MCP tools when the agent needs to inspect learned workflow memory:

• cron_workflow_candidates for repeated run candidates that are not yet execution control
• cron_workflow_patterns for active or deprecated frozen patterns
• cron_workflow_pattern_versions for version history, DAG nodes, and edges of a specific pattern group

When a pattern has been deprecated after a failed run, treat it as inactive until the server re-learns a later successful version.

Negative Examples

Do not call this skill for these requests:

• "Create a cron job that runs every hour." This is cron management, not worker-side execution.
• "Explain how the workflow pattern tables are implemented." This is code or architecture inspection, not queued work processing.
• "Check whether the weather briefing cron exists." This is inventory or inspection; use list or status tooling directly unless the agent is also expected to process pending jobs.

Notes

• Jobs may be created manually or enqueued automatically when they become due.
• One-shot jobs may be disabled or removed after completion depending on job settings.
• cron_poll claims a short lease and returns a leaseToken for each job it hands out.
• cron_poll may also return workflowMatch when the server has a single high-confidence active pattern for the job family.
• Pass the same leaseToken to cron_complete or cron_fail.
• When reporting workflow-related failures, pass outcomeMeta.candidateKey when available so pattern invalidation can target the correct workflow group.
• See the Agent Skills specification for general skill format guidance: https://agentskills.io/specification

Worked Templates

Template: Basic poll and complete

1. Call `cron_poll`.
2. If no jobs are returned, report that no work is available.
3. If a job is returned, inspect `workflowMatch`.
4. Execute the payload.
5. Call `cron_complete` with:
   - `jobId`
   - `leaseToken`
   - `note`
   - `executionLog`
   - `outcomeMeta` when the task belongs to a known workflow family

Template: Workflow drift failure

1. Call `cron_poll`.
2. Inspect `workflowMatch` and any stored pattern version if needed.
3. Start execution.
4. If the frozen workflow no longer matches the real environment:
   - stop trusting the pattern
   - call `cron_fail`
   - include `outcomeMeta.candidateKey`
   - describe the drift in `reason`
5. Tell the user the job failed and that the stored workflow may be deprecated until re-learned.

Template: Long-running work

1. Call `cron_poll`.
2. Begin execution.
3. Before the lease expires, call `cron_renew`.
4. Repeat renewal if necessary.
5. Finish with `cron_complete` or `cron_fail`.