MCP scheduler: how to schedule a task from Claude Desktop or Cursor

You ask your agent to check a page every morning and message you if the price drops. It says yes. Nothing happens the next morning. This is the gap an MCP scheduler fills: a tool your agent can call to set up work that fires later, on time, without you sitting in the session waiting for it.

There are three real ways to do this in 2026, and they are not interchangeable. One runs on your laptop, one is built into your client, and one lives on a server you don't own. Which you pick depends on a single question: does the job need to run when your machine is off?

Why MCP itself can't schedule anything

The Model Context Protocol has no timer. It's a request-response protocol: the client calls a tool, the server answers, the exchange ends. The 2026-07-28 spec pushed further in that direction and made MCP stateless by default, dropping the initialize handshake and tying most notifications to the response stream of the request they belong to. A server can stream progress back during a call. It cannot wake your agent up at 8am tomorrow.

So "scheduling over MCP" never means MCP holding the clock. It means the agent making one normal tool call that hands the waiting to something durable somewhere else. Every option below is a different answer to where else.

Option 1: a local scheduler MCP server

Several community MCP servers do this on your own machine. scheduler-mcp takes cron expressions and runs shell commands, API calls, AI tasks, and desktop notifications, with a history of past runs. claudecron and mcp-cron are similar in shape. You clone the repo, run the process, point your client's MCP config at it.

What you get: full control, no cost per run, and access to everything on your box. Shell commands, local files, private network. Nothing leaves the machine.

What you give up: the machine. The scheduler is a process on your laptop, so the job runs when your laptop is awake and that process is alive, and not otherwise. You're also now the operator. If a target endpoint 500s at 3am, retry behaviour, alerting, and a record of what failed are yours to build or live without. Fine for personal automation. Thin ice for anything a user is depending on.

Option 2: your client's built-in scheduling

Some clients now ship this themselves, which changes the calculus. Claude Code Desktop has a Routines page with two kinds of scheduled work, and the docs are clear about the trade:

• Local scheduled tasks run on your machine, get your files and your MCP servers, and fire at a one-minute minimum interval. They only run while the app is open and the computer is awake. Sleep through a scheduled time and the run is skipped, though Desktop starts one catch-up run when you wake up.
• Cloud routines run on Anthropic-managed infrastructure whether your computer is on or not, with a one-hour minimum interval and no access to your local files.

If your client has this and it covers your case, use it. It's free, it's already there, and no third-party tool beats "already installed." The honest limit is that it schedules an agent session, not an arbitrary HTTP call, and it's tied to that client. If the thing that needs to run on a timer is a feature inside an app you're shipping, your users don't have your Claude Desktop.

Option 3: a hosted scheduler behind an MCP tool

The third shape moves the clock off your machine entirely. Your agent calls a tool, a server records the schedule, and that server fires the call at the right time. Your laptop is irrelevant. Your session ended hours ago. The job still runs.

This is the only one of the three where the agent can set up work that outlives both the conversation and the machine it happened on. It's also the only one that works when the "agent" is a product you're shipping rather than an assistant you're using. The cost is that you're paying someone for uptime, and that the call goes over the network to a service you don't run.

For the wider version of this argument, including the do-it-yourself cron plus queue plus worker path, see cron for AI agents.

Comparing the three

The rows that decide it are usually the first and the last. Everything else is preference.

Using Omniyond as your MCP scheduler

Omniyond is the third shape. It's a pay-per-use HTTP API with a scheduler as its keystone, and it ships an MCP server so your agent can reach it directly. Add it to Claude Desktop, Cursor, or any MCP client in one line:

npx omniyond-mcp

From there the agent has the scheduler as a normal tool. It gives a URL, a method, headers, a body, and a cadence (every 5 minutes, hourly, daily, or a single future run), and Omniyond owns the rest. Retries back off on a 30s, then 5m, then 30m ladder. Calls that keep failing land in a dead-letter queue with a notification instead of vanishing. Every run is recorded, and the result is either stored for you to read or POSTed to a callback URL.

A scheduled run costs $0.01. There's no subscription and no monthly floor: you prepay a credit pack ($9, $29, or $99) and the credits never expire. If your agent holds a wallet, it can pay per call with x402 in USDC on Base instead, which means a 402 challenge and a signature rather than a signup, an API key, and a human. Scheduling is also not the only thing on the balance. Page extraction, PDFs, OG images, QR codes, and short links come out of the same credits and the same MCP server.

Omniyond is live. If you're weighing it against the heavier background-job platforms rather than against a local cron script, Omniyond vs Inngest and Omniyond vs Trigger.dev go through those trade-offs in detail.

Common questions

Can the agent create the schedule itself, or do I have to? The agent can. That's the point of exposing it over MCP: the scheduler is a tool it discovers and calls like any other, so "check this every morning and ping me" becomes one tool call instead of a task for you.

Do I need the MCP server at all? No. It's a plain HTTP API underneath. The MCP server is there so agents and MCP clients can use it without glue code, but you can call the endpoints from any app or script.

What if my client already schedules tasks? Then start there. Native scheduling in your client is free and closer to your files. Reach for a hosted scheduler when the job has to run with your machine off, or when it belongs to something you're shipping to other people.

What happens if the target endpoint is down? It retries on the 30s, 5m, 30m ladder, then drops to a dead-letter queue and notifies you. Nothing is silently lost, and every attempt is recorded.

The takeaway

MCP has no clock, so an MCP scheduler is always a tool call that hands the waiting to something durable. A local server keeps everything on your machine and ties the schedule to it. Client-native scheduling is free and already installed, and it schedules agent sessions rather than arbitrary calls. A hosted scheduler survives your laptop, your session, and the end of the conversation, which is what you need the moment real users depend on the job firing.

If that's the one you want, grab a $9 starter pack, add npx omniyond-mcp to your client, and have your agent schedule its first job. Or point your wallet at the endpoint and pay the 402 with no account at all.