cron.cool

# Scheduled operations with Croncool This skill drives the Croncool MCP connector. The user must connect Croncool and authorize an account with live access to the intended organization. If authorization fails, ask the user to connect Croncool; never request, embed, or repeat an API key, password, token, or webhook secret. ## Resource identifiers Keep these identifiers distinct: - `projectId` selects one tenant-scoped Croncool project. - `jobId` selects one scheduled job whose target request is already configured in Croncool. - `runId` selects one durable workflow run. It is not a job execution id. - A job execution id appears only in `get_job_runs`; there is no connector tool that returns its response body. Resolve names with a list tool and then use the returned exact id. Never guess an id, reuse an id from another organization, or treat a project name as a job id. ## Available read tools | Tool | Use | | ---------------------------- | ------------------------------------------------------------------------- | | `list_projects` | Find accessible project ids and names | | `list_jobs` | Page through jobs, optionally within one exact project | | `get_job` | Inspect one job's safe schedule, method, target origin, and latest status | | `get_job_runs` | Inspect bounded execution status, HTTP code, duration, and time | | `list_workflows` | Summarize workflow run counts in one project | | `list_workflow_runs` | Page through safe workflow-run metadata by name/status | | `get_workflow_run` | Inspect one run and a bounded safe step trace | | `list_webhook_subscriptions` | Audit endpoint origins, event filters, state, and failure counts | | `show_project_overview` | Render one bounded project/job overview | `list_jobs` and `list_workflow_runs` can return an opaque `nextCursor`. Reuse that cursor only with identical filters. Other list/detail tools are bounded; when a result says it is truncated or uses a `+` count, report it as a lower bound rather than an exact total. ## Data boundary Safe results include ids needed for follow-up, display names, schedules, methods, HTTP(S) origins, enabled/status flags, bounded counts, timestamps, HTTP status, duration, attempts, and machine error codes. Do not ask tools to expose or infer: - job request inputs or arbitrary target payloads; - URL userinfo, path, query, or fragment; - execution response bodies or error text; - workflow inputs, outputs, errors, deployment details, or ownership fields; - webhook signing secrets, full callback URLs, or delivery bodies; or - passwords, credentials, tokens, billing records, users, roles, or raw logs. The connector intentionally cannot supply those fields. Offer safe origin/status/health metadata instead. If an authorized operator needs to change configuration, direct them to first-party Croncool controls without asking them to paste secrets into chat. ## Job diagnosis workflow 1. Use `list_projects` if the project is not already unambiguous. 2. Use `list_jobs` with the exact project id and page only as needed. 3. Call `get_job` for the intended job. Report its id, name, schedule, enabled state, method, target origin, and last execution status. 4. Call `get_job_runs` to compare recent status, HTTP code, duration, and time. 5. Distinguish “Croncool recorded a failure” from the hidden downstream error details; do not invent a root cause from an HTTP status alone. ## Durable workflow diagnosis 1. Resolve the project with `list_projects`. 2. Call `list_workflows` to identify the exact workflow and status counts. 3. Use `list_workflow_runs` with project, workflow name, and optional status. Page with the opaque cursor only when needed. 4. Call `get_workflow_run` for one exact run and inspect its bounded steps. 5. Report run/step statuses, attempts, timestamps, and machine error codes. State clearly when steps are truncated. Workflow input, output, and error messages are deliberately absent. Do not reconstruct them from names or ask the user to paste sensitive payloads. ## Webhook health audit Use `list_webhook_subscriptions` with an exact project when possible. Report endpoint origin, event filters, active state, consecutive failures, last delivery time, and whether Croncool identifies the subscription as auto-disabled after twenty failures. Croncool makes one best-effort webhook attempt with a five-second timeout and no retry. An endpoint disabled after repeated failures must be repaired and re-enabled in Croncool; this connector has no re-enable tool. Full paths, queries, signing secrets, and delivery bodies are intentionally unavailable. ## State-changing tool `run_job` is the only write tool. It invokes the request already configured on one existing job. It does not accept an arbitrary URL, code, headers, or payload. Treat every call as destructive, open-world, and non-idempotent: - the downstream target can write data, send messages, perform billable work, trigger third parties, or make purchases; - Croncool does not add an idempotency key; - the target request has no Croncool application timeout; - a transport/platform failure can leave the target outcome unknown; and - repeating the call can duplicate effects. Before `run_job`: 1. Call `get_job`. 2. Show the exact job id, name, schedule, method, enabled state, and target origin. 3. Explain likely downstream effects from the user's known configuration. If those effects are unknown, say so and ask the user to confirm them. 4. Get explicit confirmation for that exact job and one invocation. A prior generic “run my jobs” instruction is insufficient. After confirmation, call `run_job` exactly once. The returned `invoked` status means Croncool invoked the job; it is not proof that the target completed successfully. Call `get_job_runs` to inspect the recorded result. Never retry automatically after a timeout, connection loss, server error, or ambiguous result. First inspect `get_job_runs`, explain the uncertainty, and ask the user how to proceed. A second invocation requires a new explicit confirmation. Do not turn “run everything,” “keep retrying,” or a broad automation request into loops of `run_job` calls. Require one exact target at a time. ## Interactive views `show_project_overview` renders a bounded project/job card and `get_job` renders a job-detail card in MCP App hosts. Add analysis the card cannot show (pagination caveats, trend comparison, failure concentration, or next safe step) instead of merely restating every visible field.