SCHEDULED MCP TOOL CALLS WITH RECURRENCE CLOUD
Scheduled MCP tool calls with Recurrence Cloud
MCP servers answer tool calls on demand — but what about calls that need to happen on a schedule? Learn how Recurrence Cloud adds cron-style recurrence to MCP tool calls with signed webhooks.
The Model Context Protocol (MCP) has quickly become the connective tissue between AI agents and the tools they use. An agent asks for a tool, the MCP server answers, everyone goes home.
But there’s a gap: MCP is fundamentally reactive. A tool call only happens inside a live session, when someone (or something) is driving. A huge class of real-world work doesn’t work that way — daily digest reports, nightly cleanups, weekly invoice pulls, reminders that fire hours after a conversation ends. Agents can reason about “every weekday at 9am”, but MCP servers have no built-in way to act on that schedule.
The missing piece: cron for tool calls
Recurrence Cloud turns “run this tool every day at 9am” from a chat message into production infrastructure. Instead of trying to keep a long-lived MCP session alive to self-schedule, your MCP server registers a webhook endpoint with Recurrence Cloud, and we call it on a cron schedule — with a signed payload that your server resolves to a tool invocation.
The pattern looks like this:
- Create an app / API token in the Recurrence Cloud dashboard.
- Register your MCP server’s webhook URL against that token.
- Create a schedule — any cron expression, any timezone.
- Attach an event to the schedule that describes the tool call: the tool name and its arguments.
- When the schedule fires, Recurrence Cloud POSTs a signed request to your webhook. Your handler verifies the signature and dispatches the MCP tool call.
No cron daemons, no sleepy containers, no glue code between a message queue and a timer. The schedule lives outside your process entirely — it survives deploys, restarts, and scale-to-zero.
Defining a scheduled tool call
Creating a schedule is a single API call using your app token:
curl -X POST https://api.recurrence.cloud/v1/schedules \
-H "Authorization: Bearer $RECURRENCE_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "engineering-daily-digest",
"cron": "0 9 * * 1-5",
"timezone": "America/New_York",
"webhookUrl": "https://mcp.yourcompany.dev/webhooks/recurrence",
"events": [
{
"type": "mcp.tool_call",
"subject": "reporting",
"payload": {
"tool": "generate_daily_digest",
"arguments": {
"channel": "eng-team",
"period": "24h"
}
}
}
]
}'
The event.payload is yours — Recurrence Cloud just delivers it on schedule. Mapping it to tools and arguments is a convention you control, which means any MCP server can adopt this without changing its tool surface. An agent could even create these schedules itself through a schedule_tool_call tool backed by our REST API, so the schedule is created as part of the conversation instead of being pre-configured by hand.
Signed requests — no open webhooks
Every outbound call is signed with a JWT whose HMAC secret is your app’s API token. Your handler verifies it in a few lines — for a Hono-based MCP server:
import { Hono } from "hono";
import { verify } from "hono/jwt";
const app = new Hono();
app.post("/webhooks/recurrence", async (c) => {
// Reject anything that isn't signed with our token
const token = c.req.header("Authorization")?.replace("Bearer ", "");
const claims = await verify(token!, [
new TextEncoder().encode(process.env.RECURRENCE_API_TOKEN!),
]);
// Claims.event.payload maps to an MCP tool invocation
const { tool, arguments: toolArgs } = claims.event.payload;
await dispatchToolCall(tool, toolArgs);
return c.json({ ok: true });
});
If the signature doesn’t verify, the call never reaches your tools. If your server responds with an error, the delivery is recorded with its status code and can be retried — the full activity trail (status codes, response bodies, latency) is visible in the dashboard, so a failed 9am digest is something you find out about, not something that silently doesn’t happen.
Beyond a single tool call
Because events are grouped by subject and deliveries are batched, one scheduled fire can carry a whole set of related tool calls — a nightly “close out the day” job that archives sessions, syncs a CRM, and posts a summary, all in one delivery grouped under the eod-cleanup subject.
It’s also not just MCP. The same scheduling surface speaks plain webhooks today, and A2A (agent-to-agent) support is on the roadmap for calling scheduled agents directly. The webhook you register is just an HTTP endpoint — which means existing cron-replacement setups, CI jobs, and agents can all share the same schedules and observability.
Try it
The docs cover authentication, schedule creation, and activity monitoring in detail, and the features page gives the full tour. If you’re running an MCP server today, the fastest way to evaluate the pattern is to register one schedule firing a tool you’d have wanted at 9am yesterday.
Recurrence Cloud is in active development — sign up to get started.