No. An MCP server does not start a client conversation or wake an editor on a timer. MCP gives a running client tools; it is not a scheduler. For recurring work, use a client automation to run a prompt, a Crontap HTTP schedule to call a deployed endpoint, or a Crontap heartbeat to watch an independently scheduled job for missed check-ins.
What MCP does, and what it does not
MCP lets a running client discover and call tools, read resources, and exchange other protocol messages with a server. The current MCP specification supports request-related notifications and opt-in change notifications on a long-lived stream opened by the client.
Those messages still depend on the client being connected. They do not launch a closed application, create a new chat, or authorize an unattended prompt. Crontap's MCP server gives your client management tools. A Crontap schedule keeps sending its saved HTTP request after the client disconnects, while a heartbeat only watches for expected check-ins.
Choose what should run on schedule
- Should an agent run a prompt? Use that client's automation or scheduled-task feature.
- Should a deployed API route receive an HTTP request? Use a Crontap schedule.
- Does another platform already start the job, but you need to detect silence? Keep its scheduler and add a Crontap heartbeat.
You rarely need all three. An agent automation may use MCP tools during a run. A scheduled endpoint may send a heartbeat after downstream work finishes. In both cases, the automation or HTTP scheduler starts the work; the heartbeat only watches it.
Current agent scheduling options
These products are not equivalent. The comparison reflects official documentation checked on 2026-09-15.
- Cursor Automations
Runs in: Cursor Cloud Agent
Recurring triggers accept presets or cron. Runs can start late, but not before the scheduled time. Cron triggers default to no repository, so select one when the task must change code.
- Claude Routines
Runs in: Anthropic cloud or your configured environment
Research preview for Pro, Max, Team, and Enterprise. Routines can include repositories and MCP connectors. The minimum custom interval is one hour, and starts may be staggered by a few minutes.
- ChatGPT Scheduled Tasks
Runs in: ChatGPT web or mobile
Availability depends on the account and workspace. Active-task caps are 3 for Free and Go, 5 for Plus, 10 for Business and Edu, and 15 for Pro and Enterprise. Free tasks run no more than daily; exact times and hourly schedules need an eligible paid plan.
- Codex scheduled tasks
Runs in: ChatGPT web or desktop
The Codex documentation URL now calls these ChatGPT scheduled tasks. Web tasks cannot use a local folder. For local projects, keep the computer on and the ChatGPT desktop app running. Git projects can use the checkout or a worktree. Advanced schedules use RFC 5545 RRULE.
Features and limits change quickly, so recheck the linked source before depending on a plan limit, minimum interval, or runtime requirement.
Outcome 1: schedule an HTTP endpoint
Use this path when the work is already behind a deployed route such as POST /jobs/daily-digest. Crontap sends the recurring request even after your editor or MCP client closes. The route should authenticate requests, handle retries safely, and record its result.
Step 1
Preview the cadence
Connect through the Crontap MCP hub, then preview the cadence with an explicit IANA timezone. Review the returned cron, timezone, and three upcoming runs. Preview is read-only and creates no schedule.
Use only Crontap MCP. Preview "weekdays at 07:30" in Europe/Paris. Do not create or update anything. Show the resolved cron, timezone, and three upcoming runs.Step 2
Create the HTTP schedule
Create a POST schedule for the deployed endpoint using the approved cadence.
Keep authorization values out of the prompt. Add any required secret header on
the Crontap schedule page after creation, then retrieve the schedule by its
returned ID.
Create one POST schedule named "weekday daily digest" for https://api.example.com/jobs/daily-digest using the cadence we previewed. Repeat the non-secret URL, method, cron, timezone, and label before approval. Do not include Authorization or another secret.Step 3
Check history and application output
After a timed run, call get_schedule_history for the exact ID. Match its
startedAt, statusCode, durationMs, and runId with application logs.
Then check the digest, database row, or other saved result.
A 2xx history entry means the endpoint returned HTTP success. It does not show whether queued or downstream work finished. For a deeper verification flow, follow Schedule API calls with an AI assistant.
Outcome 2: watch for a missed agent run
Use this path when a platform already schedules the agent. That platform starts each run. The heartbeat alerts when expected check-ins stop arriving.
Step 1
Create the heartbeat
This example uses the Crontap UI so the one-time ping URL can move directly into the automation's secret settings without passing through agent chat. Match the period to the automation and allow enough grace for normal runtime and start delay. The complete heartbeat pattern also shows the MCP creation path when you can safely transfer its one-time tool result.
Step 2
Store the ping URL as a secret
For this example, create a Cursor Automation with a scheduled trigger and a
Cloud Agent environment. In the Cursor dashboard Secrets tab, add
CRONTAP_HEARTBEAT_URL as a Runtime Secret. Cursor documents that Runtime
Secret values are redacted from tool results, transcripts, commits, and commit
messages. If outbound traffic is restricted, allow the generated ping URL's
host.
Run the morning repository review and save the report. Only after the report is saved, run curl --fail --silent --show-error --max-time 10 "$CRONTAP_HEARTBEAT_URL". Do not print the variable or response URL. If the review fails, preserve the failure and do not send the success check-in.Step 3
Check the run and heartbeat
Let the Cursor Automation start through its normal scheduled trigger. Confirm its run record and report first. Then check the heartbeat status and retained pings in Crontap. The ping shows that the run reached its final check-in; the report shows that useful work was saved.
If the automation should report known failures, add the heartbeat's /fail variant through the same secret-aware wrapper without building or exposing it in the prompt. The heartbeat monitoring guide covers success, failure, and recovery check-ins.
Verification checklist
- Agent automation: the client shows a scheduled run with the expected repository or task access.
- HTTP schedule: the saved Crontap resource matches the approved URL, method, cadence, timezone, and next run; history aligns with application logs.
- Heartbeat: the separately scheduled job saved its result, sent a final ping, and received a new deadline.
Each check answers a different question. Calling a tool in chat does not mean a future run has been scheduled.
Troubleshooting
The editor was closed and nothing happened
You probably chose a local or session-only feature. Check where that client's scheduled tasks run. Move the prompt to a supported cloud automation, or put deterministic work behind a deployed HTTP endpoint.
MCP tools work manually but not in the automation
Add the connector to the automation's own configuration and connect only the MCP servers that run needs. Cursor and Claude expose all tools from each connected server, so review a server's write tools before enabling unattended runs.
Crontap history shows 2xx but the result is missing
Follow the request into application logs, queues, and storage. HTTP success and completion of the application work are separate outcomes.
The heartbeat stays pending
Creating a heartbeat does not start its deadline. Run the automation normally and make sure the check-in happens after useful work, not at startup.
Next steps
- Return to the Crontap MCP hub for supported clients and tools.
- Compare the editor flow in the Cursor guide.
- See session tasks and cloud Routines in the Claude Code guide.
- See current ChatGPT and Codex task wording in the Codex guide.
- Read Scheduled tasks for AI-built apps before exposing a recurring endpoint.
Ready to schedule your HTTP endpoint? Free forever tier. No credit card. Create your Crontap account →
Verified against the current MCP specification, vendor scheduling documentation, and Crontap API documentation on 2026-09-15. Sources: MCP base protocol, MCP Streamable HTTP, Cursor Automations, Cursor secret protection, Claude Routines, ChatGPT Scheduled Tasks, Codex scheduled tasks, and Crontap public API.
FAQ
MCP scheduling questions
- Can an MCP server send notifications to a client?
- Yes, within protocol flows the client opens. Current MCP supports request-related notifications and opt-in change notifications on a client-opened subscription stream. That does not launch a closed client, create a conversation, or provide a timer.
- Can an MCP tool run automatically?
- A client automation can call an enabled MCP tool during a scheduled run when that client supports connectors in automations. The client schedules the run and grants access; the MCP server supplies the tool.
- Should I schedule an MCP server or my HTTP endpoint?
- If a deployed endpoint performs the job, schedule that HTTP endpoint. Keep the MCP server available so your agent can manage the schedule; do not expect the MCP connection to start future runs.
- How do I detect when a recurring agent stops running?
- Keep the platform that already starts the agent, then add a heartbeat check-in after useful work completes. Crontap can alert on a missed deadline, but it does not launch or recover the agent.