Direct MCP candidate from ai_catalog
direct:watchfor.io:84560094dfDeclared as an MCP endpoint by ai_catalog; probed directly.
Score: 100/100
Handshake verified by our own probe.
Tools · 63
How is my infrastructure right now: monitors by effective status (up / down / degraded / paused / pending, active count, health score), hosts running the agent (online / stale / offline / never), the …
Aggregate incident statistics over a period: totals by severity, MTTR (mean time to resolve), MTBF and the five most unstable monitors.
Org report for a period, always compared with the previous equal-length period: uptime, incidents, MTTR/MTBF, downtime, response-time trend, per-monitor rows (worst first), type-aware sections (SSL/do…
The organization's two scheduled report-email cadences (weekly + monthly): enabled state, recipients (max 5) and any recipients who unsubscribed themselves.
Enable/disable the weekly or monthly report email and/or replace its recipient list (up to 5 addresses). Enabling needs at least one recipient; clearing the recipients disables the cadence; adding the…
Current subscription plan with limits (-1 = unlimited, 0 = feature off) and live usage counts. usage.monitors_by_type matches limits.max_monitors_by_type (browser = page speed / Core Web Vitals, playw…
List monitors (cursor-paginated, slim items: id/name/type/target/status/tags — use get_monitor for full detail). Filter by type, status, tag, or search by name/target with q.
Get one monitor by id — includes config, available_metrics (the alert metrics valid for its type), last_check and `latest`: what the latest check found, in the terms of its type (certificate days left…
Discovery catalog of all 30 monitor types: target format, default alert rules, per-type alert metrics (exact `metric` strings, operators, value types) and config fields. Consult this BEFORE creating m…
Create a monitor (write scope). Location ids come from list_locations; check get_monitor_types for the target format and config fields of the chosen type — config is validated against that type (wrong…
Update monitor fields (write scope). Send only what changes. config is MERGED into the stored config: an omitted key is kept, a key set to null is removed, any other value replaces it (arrays and nest…
Pause or resume a monitor (write scope). Idempotent.
Permanently delete a monitor (write scope). Removes its scheduler job, alert rules and open incidents. This cannot be undone — confirm with the user before calling unless they explicitly asked for del…
Dispatch an immediate on-demand check for a monitor (write scope, plan-limited per hour). The result lands in get_monitor_checks within ~a minute.
IRREVERSIBLE (write scope): delete a monitor's entire recorded history — every check and latency record, every incident with its timeline, delivery history, internal notes, post-mortems and auto-publi…
Page integrity monitors only: the accepted baseline each watched page is compared against — per page whether it has one, when it was captured and how (auto = first check, manual = accepted in the dash…
Page integrity monitors only (write scope): accept what the newest check saw as the new baseline — all watched pages, or only `pages` — so an intended change (a deploy, a new vendor script) stops aler…
Release marker for an MCP monitor (write scope, owner/admin): for the next `window_minutes` (1–60, default 15) tool-inventory drift on that monitor does not page — only its Tool Inventory Changed rule…
Browser checks: run a Playwright Test script once in a sandboxed browser without saving it (write scope; counts against the plan's test runs per hour). The script is a normal `@playwright/test` file —…
Browser checks: one run in detail — pass monitor_id + run_id for a scheduled / Run-now run (ids from list_playwright_runs), or test_run_id for a test run from test_playwright_script. Returns steps (st…
Browser checks: a check's runs, newest first — status (passed / flaky / failed / timed_out / script_error / infra_error = could not run on our side, never an incident), duration, failed step, console-…
Uptime for a monitor over a period — confirmed critical incidents only (the same formula as the dashboard; failed checks that never became an incident do not count), plus check success ratio, check to…
Recent check results for a monitor (status, latency, per-location performance). Pass success=false to fetch only FAILED checks — one-call failure forensics. hours widens the window (up to 720, and nev…
Everything the probe saw on ONE check run — the full recorded result (HTTP headers and timings, TLS chain and grade, DNS answers, assertion outcomes, the error) with sensitive values redacted server-s…
Probe locations available for monitors — use these ids in create_monitor's locations array.
List a monitor's alert rules (system defaults + custom). Rules define when incidents fire.
Create an alert rule on a monitor (write scope). `metric` must come from the monitor type's alert metrics (see get_monitor_types or get_monitor.available_metrics); value is always a string. At most on…
Update an alert rule (write scope) — fix a noisy threshold, change severity, or enable/disable. Send only the fields that change; metric/operator/value are validated against the monitor type's catalog…
Delete a custom alert rule (write scope). System default rules cannot be deleted (403) — disable them with update_alert_rule enabled=false instead.
Alert recipients (people) with their group memberships — answers 'who gets notified?'. Cursor-paginated.
One contact's detail: name, email, phone, group memberships.
Create an alert recipient (write scope). Optionally place them straight into notification groups (ids from list_contact_groups). Duplicate email (case-insensitive) returns the existing-contact conflic…
Update a contact (write scope). Send only what changes; group_ids replaces ALL memberships ([] removes from every group, omitted keeps them).
Delete a contact (write scope) — removes them from all notification groups. Irreversible; confirm with the user unless they explicitly asked.
Notification groups (contact groups) — where alerts are delivered. Use these ids to answer 'where do alerts for this monitor go?' (monitor config's notificationGroupIds) or when wiring alert rules to …
One notification group's detail INCLUDING its member list (who exactly gets paged).
Create a notification group (write scope), optionally with initial members (contact ids from list_contacts).
Update a notification group (write scope). contact_ids replaces the FULL member list ([] empties the group, omitted keeps it).
Delete a notification group (write scope). The org's default group cannot be deleted (conflict). Monitors routed to it stop notifying through it — confirm with the user first.
The org's public status pages: slug, public URL, visibility and what each currently says (overall_status). Use get_status_page for the components and their status.
One status page with what visitors see right now: overall_status, every component with its status and the monitors and hosts behind it (tag rules resolved), its public_cause (how much auto-published n…
Announcements published on a status page — incidents and scheduled maintenance as customers saw them, with their update timeline (investigating → identified → monitoring → resolved), scheduled start/e…
Who is on call right now and until when, who is next (upcoming shifts), the schedule's layers and participants, active overrides, and whether the current person can actually be paged (reachable). Use …
Where alerts are delivered: every notification channel (Slack, Discord, Telegram, PagerDuty, email, webhook, …) with its type, enabled flag, severity filter, the contact groups routed to it, and a red…
List incidents newest first (cursor-paginated). Filter by status (firing/acknowledged/resolved), severity, a single monitor (monitor_id) and a started_at time range (since/until). Each incident carrie…
Full detail of one incident: the humanised message, the fire-time rule, root_cause (expected vs detected — e.g. 'HTTP Status Code = 404'), the trigger snapshot (metrics the probe reported, which probe…
Acknowledge a firing incident (write scope) — pauses repeat notifications while someone investigates.
Manually resolve an incident (write scope). Accepted asynchronously — the alerting engine's failure state is reset; if the underlying problem persists the incident will re-fire.
Drift incidents only — an MCP monitor's Tool Inventory Changed (write scope, owner/admin): mark the change as intended, e.g. the user shipped a release that added or reworded tools. An open incident i…
Mark a RESOLVED incident as a false positive (excluded: true, write scope) or undo that mark (excluded: false). An excluded incident stays on record with its timeline, notes and post-mortem, but is le…
The incident's post-mortem (plan feature): title, status (draft/completed), is_public, severity (minor/major/critical), root_cause_category, `sections` (summary, impact, root_cause, detection, resolut…
Create or fill the incident's post-mortem draft (write scope; any member may, as in the dashboard). Creates it with the dashboard template on first use, then applies only what you pass: `sections` rep…
Alerting delivery history — every notification attempt with channel, delivery status (sent/failed/silenced), severity, incident and monitor. Answers 'did the Slack alert actually go out?' and 'which d…
The organization's audit trail — who changed what and when (monitors, alert rules, contacts, maintenance, channels; dashboard AND API actions). Great for correlating incidents with recent config chang…
Servers running watchfor-agent, with liveness (online / stale = no batch for three push intervals, never sooner than 90 s / offline = none for 10 min / never = not reported yet) and the latest CPU, me…
One host: OS, kernel, agent version, hardware, addresses (private, public, and the one it reports from), current CPU / memory / disk gauges and its monitor_id.
Metric time series for a host over 1h–30d, bucketed like the host page's charts. Metric names are the agent's catalogue: cpu.usage_pct, cpu.iowait_pct, cpu.steal_pct, load.1, mem.used_pct, swap.used_b…
Scheduled maintenance windows, most recent first, each with its state (active / upcoming / ended / disabled) and next_run_at. Filter with state=active ('is maintenance running right now') or state=upc…
Schedule a maintenance window (write scope): alerts are suppressed and downtime excluded from uptime for the covered monitors during the window. Times are ISO 8601; duration in minutes.
Cancel a maintenance window (write scope) — removes future occurrences and lifts any active silences. Use when a window was scheduled with a wrong time or is no longer needed.
Catalog of the live checks WatchFor can run from its probe fleet, with the question each answers, its options, and THIS organization's remaining allowance for each. Call it when you need a check's exa…
Run ONE live check against any public target from WatchFor's probe fleet and get the raw result. This MEASURES right now from real machines in 20+ locations — it is not a lookup of stored monitoring d…
Investigate a host or URL in ONE call: DNS, DNS propagation across every location, TLS grade, HTTP headers, and ping from up to 3 different regions — run in parallel and returned as one verdict (a sta…
Resources · 4
Every monitor type: target format, config fields and the EXACT alert-metric strings to use in alert rules. Read this before creating monitors or alert rules.
https://watchfor.io/api/v1/meta/monitor-types
When to use WatchFor, how to authenticate (API key or OAuth 2.1) and the first calls to make.
https://watchfor.io/agents.md
Structured overview of the WatchFor platform, monitor types, tools and key pages.
https://watchfor.io/llms.txt
Full machine-readable spec of the REST API (/api/v1): every operation, schema, parameter and error shape.
https://watchfor.io/openapi.json
Prompts · 3
Assess the organization's current health and explain every active incident with its likely cause.
Create a correctly-configured monitor for a target, choosing the right type and sensible defaults.
Summarise reliability over a period: uptime, incident counts and the least reliable monitors.
How to use
Claude Desktop or claude.ai: add a custom connector (Customize → Connectors; on Team and Enterprise plans an owner adds it under Organization settings → Connectors) with this server URL: https://watchfor.io/api/mcp
Cursor or Cline: add to your MCP config:
{
"mcpServers": {
"direct_mcp_candidate_from_ai_catalog": {
"url": "https://watchfor.io/api/mcp",
"transport": "streamable-http"
}
}
}