AI coding agents are getting good at writing application code. The gap is the operational layer — the cron jobs, health checks, and monitoring that keep a production app running. Tickstem's MCP server closes that gap by letting Claude Code provision infrastructure directly, without you switching context to another dashboard.
The problem with AI-built apps in production
You build a feature with Claude Code in an afternoon. The code is clean, the tests pass, it deploys. Then the background job that sends daily digests silently stops running. Nobody notices for three days because there is no monitoring. The job was scaffolded by the agent, but the operational layer — the heartbeat check, the cron schedule, the alert on failure — was never set up.
This is the gap. AI agents are excellent at writing application logic. They are bad at the surrounding infrastructure, not because they lack the ability, but because the tools for provisioning that infrastructure are not natively available to them. They can generate curl commands and tell you what to run — but they cannot actually register the monitor.
Tickstem's MCP server changes this. Once it is configured, Claude Code can register cron jobs, create uptime monitors, set up heartbeat checks, and verify email addresses as part of the normal development workflow.
Installing the Tickstem MCP server
First, get a Tickstem API key from app.tickstem.dev/dashboard/keys. The free tier is enough to follow this walkthrough.
Download the tsk-mcp binary for your platform from github.com/tickstem/mcp/releases and place it somewhere on your PATH. Then add Tickstem to your Claude Code MCP configuration:
# Add to your Claude Code project via CLI
claude mcp add tickstem tsk-mcp --env TICKSTEM_API_KEY=tsk_your_key_here
Or add it manually to .claude/settings.json in your project:
{
"mcpServers": {
"tickstem": {
"command": "tsk-mcp",
"env": {
"TICKSTEM_API_KEY": "tsk_your_key_here"
}
}
}
}
Restart Claude Code. When the MCP server connects successfully, Claude has access to Tickstem's tools and can use them without any further instructions.
Registering a cron job
Suppose you have just built a daily digest endpoint at /api/cron/digest. Instead of manually logging into a dashboard to schedule it, you ask Claude directly:
You: Register a cron job that hits POST /api/cron/digest on my production app every day at 9am UTC, Monday through Friday.
Claude Code:
I'll register that with Tickstem now.
✓ Created cron job daily-digest
- Schedule:
0 9 * * 1-5- Endpoint:
https://yourapp.com/api/cron/digest- Method: POST
The job is active. You'll receive an email alert if it fails. You can view execution history at app.tickstem.dev/dashboard/jobs.
The job is now registered and running. No dashboard visit, no copy-pasting a webhook URL, no configuring retry logic — that is all handled by Tickstem's scheduler.
Setting up a heartbeat monitor
A cron job tells Tickstem when to run your endpoint. A heartbeat monitor is the reverse: your job tells Tickstem it ran successfully. If the ping stops arriving, you get an alert. This catches a different failure mode — the scheduler fires but the job itself crashes or times out silently.
You: Add a heartbeat monitor for the digest job. It should alert me if no ping arrives within 25 hours — that gives a 1-hour buffer on the daily schedule.
Claude Code:
Created heartbeat monitor daily-digest-heartbeat
- Interval: 86400s (24h)
- Grace: 3600s (1h)
- Ping URL:
https://api.tickstem.dev/v1/heartbeats/a3f8...c2d1/pingI'll add the ping call to your digest handler. At the end of a successful run, your job should POST to that URL — no auth header needed, the token in the URL is the credential.
Claude then updates your handler to include the ping:
import httpx
async def send_digest():
# ... your existing digest logic ...
# Ping Tickstem at the end of a successful run
# Non-fatal — don't let a monitoring outage block your job
try:
httpx.post(
"https://api.tickstem.dev/v1/heartbeats/a3f8...c2d1/ping",
timeout=5,
)
except Exception:
pass # log this, but don't raise
Two monitors for one job — the scheduler fires it, the heartbeat confirms it completed. If either fails, you know immediately.
Verifying email addresses at signup
Email verification is the same pattern. You are adding a signup form and want to reject disposable addresses before they reach your database:
You: Add email verification to the signup handler. Reject disposable and role-based addresses with a clear error message.
Claude Code:
I'll add Tickstem email verification to your signup handler. The free tier gives you 500 verifications per month — enough for early-stage signups.
from tickstem import VerifyClient
import os
verify = VerifyClient(os.environ["TICKSTEM_API_KEY"])
async def signup(email: str):
result = verify.verify(email)
if not result.valid:
raise ValueError(f"Email address not accepted: {result.reason}")
if result.disposable:
raise ValueError("Disposable email addresses are not accepted.")
if result.role_based:
raise ValueError("Please use a personal email address.")
# safe to store
await db.users.insert(email=email)
What this looks like end to end
In a typical Claude Code session building a production feature, the full ops setup now takes one conversation:
- Build the feature and deploy the endpoint
- Ask Claude to register the cron schedule
- Ask Claude to add a heartbeat monitor and update the handler
- Ask Claude to add email verification to any signup flows
The agent provisions everything, writes the integration code, and confirms what was created. You end up with a production-ready feature — scheduler, monitoring, and validation — without touching a separate dashboard.
What Claude Code can do via MCP: register and manage cron jobs, verify email addresses, list existing jobs and their execution history.
What requires direct API calls (code Claude generates for you): heartbeat ping calls, uptime monitor creation, heartbeat monitor creation. Claude writes the integration code; you run it once to provision.
Why this matters beyond convenience
The practical benefit is obvious — fewer context switches, faster setup. But there is a structural argument too.
The operational layer of most applications is set up manually, inconsistently, and often incompletely. Developers know they should add a heartbeat monitor. They do not, because it means opening another tab, finding the dashboard, creating the resource, copying the URL, and updating the code. It takes twenty minutes and breaks flow.
When that setup is a two-sentence conversation with the agent already open in your editor, it gets done. Every time. The gap between "application code" and "production-ready application" closes because the tooling for both lives in the same place.
Get your API key and add Tickstem to Claude Code: app.tickstem.dev — free tier includes 1,000 cron executions, 5 heartbeats, 5 uptime monitors, and 500 email verifications per month.
Top comments (0)