Connect CronAlert's MCP server to Claude Code and ask it to "monitor our Postgres box at 203.0.113.5," and a stock agent will do the obvious thing: call create_monitor with an HTTP URL built from the IP. The monitor is created, the first check fails with a 403, and the agent explains that your database is down. It is not. Cloudflare Workers cannot fetch bare IP addresses, the right call was a TCP monitor on port 5432, and nothing in the tool schema says so. Ask the same agent to "watch the nightly backup" and it may create an HTTP monitor on the backup bucket's URL, which will be green forever while the backup silently stops running.

The tools were fine. What was missing is the know-how that a person who has used the product for a week has and the agent does not: which monitor type fits which situation, which fields matter, which failures the product can and cannot see. The Agent Skills standard exists to package exactly that, and CronAlert now ships one. This post covers what is in it, how to install it in Claude Code, Codex, and Cursor, what changes in a session, and how to write a smaller skill of your own on top of it.

Tools versus judgment

The Model Context Protocol gives an agent a set of callable tools with typed inputs. cronalert-mcp exposes twelve: list and get monitors, create, update, and delete them, read check results and incidents, post status-page updates, and import from other monitoring services. Each has a schema and a one-paragraph description, and that is what the agent reasons from.

A skill is different in kind. It is a folder with a SKILL.md file, YAML frontmatter with a name and a description, then Markdown instructions. The agent reads the description to decide when the skill applies and loads the body when it does. The body is procedural: when the user says X, do Y first, never do Z. Anthropic published the format as an open standard in December 2025 after shipping it in Claude, and Codex, Cursor, and a long list of other agents read the same file now, so a skill written once is portable in a way agent-specific config never was. MCP is capability; the skill is judgment about how to use it.

What is in the CronAlert skill

The skill lives in the cronalert-mcp repository under skills/cronalert-uptime-monitoring/, MIT licensed, one file. It assumes the MCP server is connected and covers five things.

Setup, if the server is missing. How to create an account and an API key, with a read-only key as the default recommendation, and the install line for each client. It tells the agent never to ask the user to paste a key into chat.

Choosing the monitor type. A table and a set of rules: URLs get http, cron jobs and queue workers get heartbeat, databases and bare IPs get tcp. Then the constraints the schema does not express: HTTP checks cannot reach a bare IP, port 25 is blocked, ICMP is impossible, the check interval is set by the plan and not the user, a monitor carries one content assertion, HTTP monitors send no request body, and alert channels are team-wide and configured in the web app rather than through the tools.

Workflows. Step-by-step procedures for the things people actually ask: monitor a deployed service (prefer a health endpoint, add a keyword so a 200 error page counts as down), monitor a cron job (convert the schedule to seconds, pick a grace period, append the ping to the job with && so it fires only on success), check a TCP service, set multi-region thresholds, answer "is anything down right now" by walking incidents to check results to a cause, pause for a deploy with a maintenance window rather than an open-ended pause, post status-page updates, migrate from another tool without creating duplicates, and delete with confirmation.

Plan limits. A table of what Free, Pro, Team, and Business include, so when a call fails with a plan error the agent says which feature needs which plan and links the pricing page instead of looping on the 403.

Safety. Prefer read-only keys. Confirm before delete and import. Never create monitors against hosts the user does not control. Keep API keys and heartbeat ping URLs out of logs and repositories, because a leaked ping URL lets anyone mark a job healthy.

Installing it

Two steps in every client: connect the MCP server, then put the skill folder where the agent looks for skills.

Claude Code

# 1. the MCP server (once per machine or per project)
claude mcp add cronalert -e CRONALERT_API_KEY=ca_xxx -- npx -y cronalert-mcp

# 2. the skill, project-scoped (commit it) or personal (~/.claude/skills/)
git clone --depth 1 https://github.com/jaredhobbs/cronalert-mcp /tmp/cronalert-mcp
mkdir -p .claude/skills
cp -r /tmp/cronalert-mcp/skills/cronalert-uptime-monitoring .claude/skills/

Claude Code picks the skill up on the next session from the folder name and the frontmatter; the name must match the folder exactly, which the repository already guarantees. It triggers from the description when a request is about monitoring, downtime, cron jobs failing silently, or outages, and it is also available by name as /cronalert-uptime-monitoring.

Codex CLI

mkdir -p ~/.codex/skills
cp -r /tmp/cronalert-mcp/skills/cronalert-uptime-monitoring ~/.codex/skills/

Add the MCP server to Codex's config as a stdio server running npx -y cronalert-mcp with CRONALERT_API_KEY in its environment, the same shape as the Cursor configuration.

Cursor

Cursor 2.4 and later read SKILL.md skills from the project. Add the MCP server to .cursor/mcp.json as the Cursor guide shows, then copy the skill folder into Cursor's project skills directory; check Cursor's current documentation for the path, which has moved between versions. Windsurf and Claude Desktop run the MCP server the same way; where a client has no skills directory, the skill's body pastes cleanly into project rules or custom instructions.

Skill marketplaces are the third route: directories that index SKILL.md files and install them with one command into whichever agents you use. CronAlert's skill is listed on Agensi, free, under the same license, and installs from there into Claude Code, Codex, Cursor, and the other agents Agensi supports.

A session with the skill

The difference shows up in the first exchange. Without the skill, "set up monitoring for our nightly database backup" tends to produce an HTTP monitor on whatever URL the agent can find. With it:

You: Our nightly pg_dump sometimes fails silently. Set up monitoring for it.

Agent: A scheduled job that can fail without producing an error is what a
heartbeat monitor is for: CronAlert waits for the job to ping it and alerts
when the ping is late. Two questions before I create it:
  1. How often does the dump run? (I'll assume nightly, so a 24h interval.)
  2. How late is acceptable before you want an alert? (Default is 1h grace;
     for a backup that can run long I'd suggest 2h.)

You: Nightly at 3am, 2h is fine.

Agent: [create_monitor type=heartbeat name="Nightly pg_dump"
        checkInterval=86400 gracePeriod=7200]
Created. Append this to the cron line so it pings only when the dump succeeds:

  0 3 * * * pg_dump mydb > /backups/mydb.sql && curl -fsS --retry 3 https://cronalert.com/api/heartbeat/<token>

The monitor shows "unknown" until the first ping arrives, then alerts if a
ping is ever more than 26 hours after the previous one. Don't put the curl
in a trap or finally block; that would hide failures.

Every move there came from the skill: the type choice, the two questions, the interval math, the &&, the warning about finally, and the explanation of what "unknown" means. Triage works the same way. "Is anything down?" becomes list_incidents, then get_monitor and get_check_results on each affected monitor, then a summary that separates one service timing out from everything failing at once, with the note that a 403 on a bare-IP HTTP monitor is Cloudflare and not your server.

Writing your own on top

The CronAlert skill is general. Your team's conventions are not, and a second, smaller skill is the right place for them. Skills compose: the agent loads every skill whose description matches, so a team skill can assume the CronAlert one is present and only add rules. A complete example:

---
name: acme-monitoring-conventions
description: Acme's conventions for CronAlert monitors. Use alongside the cronalert-uptime-monitoring skill whenever creating or changing monitors for Acme services.
---

# Acme monitoring conventions

- Name monitors `<env>/<service>`, e.g. `prod/billing-api`. Never bare service names.
- Every production HTTP service gets two monitors: `/healthz` expecting 200 with
  keyword `"status":"ok"`, and the same URL with no auth header expecting 401
  (the inverse monitor; see references/inverse-monitor.md).
- Production monitors use regions `us-east,eu-west` with `failureThreshold: 2`.
  Staging monitors are single-region.
- Heartbeat grace is 15 minutes for anything hourly or faster, 2 hours for daily.
- Never delete a monitor named `prod/*` without asking twice. Suggest pausing
  with a maintenance window instead.
- After creating monitors, remind the user that alert channels are team-wide and
  that Acme's prod team routes to PagerDuty, staging to Slack #alerts-staging.

Three rules of the format keep it working across agents. The name must equal the folder name and use only lowercase letters, numbers, and hyphens. The description should say what the skill does in one sentence and when to use it in the next, because that sentence is the only thing the agent reads before deciding to load the body. And keep the body short, moving long reference material into a references/ folder the body points to, so the skill costs the agent little when it is loaded and nothing when it is not.

Teams that create monitors from CI can commit the same conventions skill next to the pipeline so the agent and the pipeline agree on naming.

Safety is in the key, not the prompt

A skill is instructions, and instructions can be overridden by a later prompt, a stray injection in a web page the agent read, or a model that simply decides otherwise. CronAlert's safety boundaries are therefore not in the skill. They are on the API key, enforced by the server:

  • Read-only keys are rejected on every write endpoint with a 403, regardless of plan and regardless of what any prompt says. Hand an agent a read-only key and it can triage all day and change nothing. This is the recommended default and the first thing the skill tells the agent to ask for.
  • Require-confirmation, an opt-in flag on a read-write key, makes delete_monitor return a preview and a short-lived, resource-bound token on the first call. Nothing is deleted until the agent sends the token back. A single stray or injected call cannot destroy data.
  • Key scope is one team, so the blast radius of any key is that team's monitors.

The skill reinforces these in prose, which helps the common case; the key enforces them, which covers the rest. The REST API guide covers key scopes in detail.

Frequently asked questions

Do I need the skill if the MCP server already works?

No, and most people start without it. Add it when you notice the agent making a product-shaped mistake: an HTTP monitor on an IP, a promise of a 30-second interval, a heartbeat without a grace period, a confident delete. Each of those is a sentence in the skill.

Does the skill send anything to CronAlert?

Nothing. It is a Markdown file your agent reads locally. All traffic to CronAlert goes through the MCP server, which calls the same REST API the dashboard uses, with your key.

Will it conflict with my existing CLAUDE.md or project rules?

Skills and project instructions coexist; where they disagree, the agent weighs both, so keep monitoring rules in one place. If you already have monitoring conventions in a project file, either move them into a skill like the example above or leave them and skip the team skill.

How do I know the skill loaded?

Ask the agent to monitor something on a bare IP address. With the skill, it proposes a TCP check and explains why. Without it, it builds an HTTP URL.

Which plan?

The skill and the MCP server are free and open source. Reading monitors and incidents through them works on the free plan. Creating, updating, deleting, and importing monitors through the API, from an agent or otherwise, needs Pro ($5/mo, or $4/mo billed annually).

Give the agent the week of experience

The MCP server made monitoring a conversation. The skill makes it a conversation with someone who has read the manual: the right monitor type the first time, a grace period that fits the job, a confirmation before the irreversible step. Create a free account, connect the server, drop the skill into .claude/skills/, and ask it to watch your flakiest cron job. Related reading: the setup guides for Claude Code, Cursor, Windsurf, and Claude Desktop, monitoring an MCP server you run yourself, and cron job heartbeat monitoring for the pattern the skill reaches for most.