MCP
The same scheduling is available to an AI assistant over MCP. An assistant holding a token lists the jobs, adds a check for a service being deployed, pauses a noisy one and reads the last runs, all inside the conversation where the work is already happening.
Connecting
The endpoint speaks Streamable HTTP and takes an API token from settings as a bearer token.
claude mcp add --transport http cronjob https://cronjob.dev/mcp \ --header "Authorization: Bearer $TOKEN"
Clients configured from a file take the same three values:
{
"mcpServers": {
"cronjob": {
"type": "http",
"url": "https://cronjob.dev/mcp",
"headers": { "Authorization": "Bearer <token>" }
}
}
}
Tools
| Tool | Purpose |
|---|---|
| list_jobs | List jobs, filtered by state or hostname. |
| get_job | Read one job. |
| create_job | Create a job. |
| update_job | Change a job. |
| delete_job | Delete a job and its history. |
| pause_job | Pause a job. |
| resume_job | Resume a job, with a fresh stop token. |
| run_job | Run a job once, outside the schedule. |
| job_runs | Read the recent runs of a job. |
What an assistant sees
Header values read back masked, so a shared transcript keeps a secret a secret. Every tool is scoped to the account behind the token and reaches nothing else. Validation is the same code the forms and the REST API use, so a schedule refused in the dashboard is refused here, with the same message. Both surfaces spend one budget of six hundred requests an hour per token.