Back to WatchFor
Card snapshot
watchfor.io
·
2026-10-15 20:25:59 UTC
·
66f7549d31cd30f511a2c7aa799bdf374d9ebcecba36bd4b9431569ee01925d1
This is a frozen copy of the agent's agent-card.json as we observed it at the timestamp above. We capture a new snapshot every time the card's content hash changes. Useful for: forensic drift analysis, verifying downstream callers see the right version, reproducing routing decisions made historically.
{
"protocolVersion": "0.3.0",
"name": "WatchFor",
"description": "Modern uptime and infrastructure monitoring for humans and AI agents. Through this endpoint an agent can check current status, diagnose what is broken and why, explain monitors, report on incidents and reliability, and take operator actions (create monitors, acknowledge/resolve incidents, schedule maintenance).",
"url": "https://watchfor.io/api/a2a",
"preferredTransport": "JSONRPC",
"provider": {
"organization": "WatchFor",
"url": "https://watchfor.io"
},
"version": "1.0.0",
"documentationUrl": "https://watchfor.io/docs/api/a2a",
"iconUrl": "https://watchfor.io/icon.png",
"capabilities": {
"streaming": false,
"pushNotifications": false,
"stateTransitionHistory": false
},
"defaultInputModes": [
"application/json",
"text/plain"
],
"defaultOutputModes": [
"application/json",
"text/plain"
],
"securitySchemes": {
"apiKey": {
"type": "http",
"scheme": "bearer",
"description": "WatchFor API key (Settings \u2192 API keys): Authorization: Bearer wf_live_\u2026"
},
"oauth2": {
"type": "oauth2",
"description": "OAuth 2.1 (dynamic client registration + PKCE). Discovery: /.well-known/oauth-authorization-server",
"flows": {
"authorizationCode": {
"authorizationUrl": "https://watchfor.io/api/auth/oauth2/authorize",
"tokenUrl": "https://watchfor.io/api/auth/oauth2/token",
"scopes": {
"read": "Read monitors, incidents, uptime and activity",
"write": "Create and change monitors, incidents and maintenance"
}
}
}
}
},
"security": [
{
"apiKey": []
},
{
"oauth2": [
"read",
"write"
]
}
],
"skills": [
{
"id": "check-status",
"name": "Check current status",
"description": "Answer 'is it up right now?' for a single monitor or the whole organization: current up/down/degraded status, and the health-score snapshot across everything being watched.",
"tags": [
"monitoring",
"status",
"health",
"uptime"
],
"examples": [
"Is watchfor.io up right now?",
"What's the overall status of my monitors?",
"Check the status of monitor <id>"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "list-monitors",
"name": "List monitors",
"description": "Enumerate what the organization is watching \u2014 id, name, type, target and current status \u2014 so an agent starting cold can discover monitors before checking or explaining one. Optionally filter by a search term, type or status.",
"tags": [
"monitoring",
"discovery",
"inventory",
"list"
],
"examples": [
"What are you monitoring?",
"List all down monitors",
"Show my SSL monitors"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "diagnose-incidents",
"name": "Diagnose what's wrong",
"description": "Explain what is currently broken and WHY. Returns every active incident with what failed (the exact alert rule and trigger value), a plain-language category (TLS certificate, HTTP 5xx, DNS, latency, reachability\u2026), which monitor, how long it has been down, and whether it has been acknowledged \u2014 everything needed to describe the problem to a human.",
"tags": [
"monitoring",
"incidents",
"diagnosis",
"root-cause",
"troubleshooting"
],
"examples": [
"What's wrong with my infrastructure right now?",
"Why is my site down?",
"Diagnose active incidents for monitor <id>"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "explain-monitor",
"name": "Explain a monitor",
"description": "Describe one monitor end to end so an agent can explain it: what it watches (type + target), its current status, recent uptime, its alert rules, and its recent incident history.",
"tags": [
"monitoring",
"explain",
"configuration",
"uptime"
],
"examples": [
"What does monitor <id> check and how healthy is it?",
"Explain the monitoring set up for api.example.com"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "incident-report",
"name": "Report on an incident",
"description": "Reconstruct one incident after (or during) the fact: what fired, the trigger values, the full timeline (detected \u2192 acknowledged \u2192 resolved) with durations, and which monitor it affected. Use it to answer 'what happened?'.",
"tags": [
"monitoring",
"incidents",
"post-mortem",
"timeline"
],
"examples": [
"What happened in incident 4210?",
"Give me a timeline for incident <id>"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "reliability-report",
"name": "Reliability report",
"description": "Summarise how reliable things have been over a period: incident counts by severity and mean time to resolution, plus the current health snapshot. Optionally scope to one monitor.",
"tags": [
"monitoring",
"uptime",
"reliability",
"reporting",
"mttr"
],
"examples": [
"How reliable was my infrastructure this week?",
"Give me a 30-day reliability report"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "org-report",
"name": "Organization report",
"description": "The full organization 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/domain expiry, Core Web Vitals, heartbeat check-ins, DNS blocklists, MCP tool drift, hosts running the agent) and plain-language insights \u2014 the same document behind the dashboard Reports page and scheduled report emails. For a lighter incident-only summary use reliability-report.",
"tags": [
"monitoring",
"uptime",
"reporting",
"trends",
"insights"
],
"examples": [
"Give me the weekly report",
"How did last month compare to the one before?"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "describe-monitor-types",
"name": "Describe monitor types",
"description": "Discover what WatchFor can monitor and how to configure it: every monitor type (http, ssl, dns, tcp, ping, api, playwright/browser checks, browser/Core Web Vitals, heartbeat, \u2026) with its target format and example, its config fields, and the exact alert metrics you can build rules from. Call this BEFORE create-monitor to choose a type and build a valid config. Optionally pass one type to get just its details.",
"tags": [
"monitoring",
"discovery",
"catalog",
"configuration",
"capabilities"
],
"examples": [
"What can WatchFor monitor?",
"What monitor types are available?",
"What config fields does the ssl monitor take?"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "list-locations",
"name": "List probe locations",
"description": "List the probe locations (cities/regions) a monitor can run from \u2014 their ids are what create-monitor's `locations` expects. Call this to pick where to check from.",
"tags": [
"monitoring",
"discovery",
"locations",
"regions"
],
"examples": [
"Where can WatchFor check from?",
"List the available monitoring locations"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "check-hosts",
"name": "Check servers",
"description": "Which servers running watchfor-agent are online, stale or offline right now, with their current CPU, memory and disk usage \u2014 the host-side counterpart of check-status. Pass status to narrow (e.g. offline). Each host's monitor_id links it to incidents and status pages.",
"tags": [
"hosts",
"servers",
"infrastructure",
"status",
"monitoring"
],
"examples": [
"Are all my servers online?",
"Which hosts are offline or stale?",
"Show CPU, memory and disk usage across my servers"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "who-is-on-call",
"name": "Who is on call",
"description": "Who is on call right now and until when, who takes over next, the schedule's layers and any active override \u2014 and whether the current person can actually be paged (reachable). Ask this before asserting that someone was notified.",
"tags": [
"on-call",
"escalation",
"incident-response",
"people"
],
"examples": [
"Who is on call right now?",
"Who takes over on-call tonight?",
"Can the person on call actually be reached?"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "create-monitor",
"name": "Create a monitor",
"description": "Start watching something on the user's behalf. Provide the target and monitor type \u2014 call describe-monitor-types first for exact type ids, target formats and config fields, and list-locations for location ids. Credentials (config fields marked secret, e.g. a mailbox password) are write-only: stored encrypted, returned as \"[redacted]\". Requires the write scope.",
"tags": [
"monitoring",
"provisioning",
"setup"
],
"examples": [
"Monitor https://api.example.com every minute from Europe",
"Watch the SSL certificate on example.com"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "manage-incident",
"name": "Acknowledge or resolve an incident",
"description": "Take ownership of an active incident: acknowledge it (I'm on it \u2014 pauses repeat notifications) or resolve it. Requires the write scope. Resolve is accepted asynchronously; if the underlying problem persists the incident re-fires.",
"tags": [
"monitoring",
"incidents",
"on-call",
"operations"
],
"examples": [
"Acknowledge incident 4210",
"Resolve incident 4210 \u2014 the deploy fixed it"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "manage-maintenance",
"name": "Schedule or manage maintenance windows",
"description": "Suppress alerts and exclude downtime during planned work \u2014 useful for an agent doing a deploy that would otherwise trip monitoring. action: create (default), list or cancel. Requires the write scope for create/cancel. Times are ISO 8601; duration in minutes.",
"tags": [
"monitoring",
"maintenance",
"deployments",
"operations"
],
"examples": [
"Silence alerts on my API for the next 30 minutes while I deploy",
"List scheduled maintenance windows",
"Cancel maintenance window <id>"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "manage-report-emails",
"name": "Manage scheduled report emails",
"description": "Every organization has two report-email cadences \u2014 weekly (Mondays) and monthly (the 1st) \u2014 with up to 5 recipients each. action: list (default) shows both with recipients and enabled state; set toggles a cadence and/or replaces its recipients. Enabling needs at least one recipient; clearing the recipients disables the cadence. Requires the write scope for set.",
"tags": [
"monitoring",
"reporting",
"email",
"settings"
],
"examples": [
"Who gets our weekly report?",
"Turn on the monthly report and send it to ops@example.com",
"Remove john@example.com from the weekly report"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "list-incidents",
"name": "List incidents",
"description": "List incidents newest first with filters \u2014 status (firing/acknowledged/resolved), severity, a single monitor, and a started-at time range. Use this for history and reporting; use diagnose-incidents for what is broken right now.",
"tags": [
"monitoring",
"incidents",
"history",
"reporting"
],
"examples": [
"Show resolved incidents from the last week",
"List all critical incidents"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "manage-monitor",
"name": "Manage a monitor",
"description": "Operate on an existing monitor: pause, resume, run an immediate check, update its fields (name/target/interval/config/tags), delete it, or \u2014 page integrity monitors \u2014 accept the latest state of the watched pages as the new baseline after a deploy (optional pages[]; fresh: true checks the pages first and accepts that check \u2014 use it right after a release; an open integrity incident resolves at once when nothing else differs), or \u2014 browser checks \u2014 test-script: run the check's saved Playwright script (or a new `script` before saving it with update) once in a sandboxed browser and return the result. Requires the write scope. Delete is permanent \u2014 confirm with the user first unless they explicitly asked. Never accept a baseline over unreviewed security findings (new scripts, forms, headers) without the user. Stored passwords read back as \"[redacted]\" \u2014 omit them (or send the mask) to keep them; changing the server, port, TLS mode or login they are used with needs the password again in the same update.",
"tags": [
"monitoring",
"operations",
"lifecycle"
],
"examples": [
"Pause monitor <id>",
"Change monitor <id> to check every 60 seconds",
"Run a check on <id> now",
"Delete monitor <id>",
"We just deployed \u2014 accept the new baseline on page integrity monitor <id>",
"Test the new login script on browser check <id> before saving it"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
},
{
"id": "diagnose",
"name": "Diagnose a target",
"description": "Investigate any public host or URL LIVE from WatchFor's probe fleet \u2014 20+ locations across 7 regions \u2014 whether or not it is monitored. By default it runs the whole bundle at once (DNS, DNS propagation everywhere, TLS grade, HTTP headers, and ping from up to 3 regions) and returns one verdict with a status per check, a machine-readable list of what looks wrong and the TLS and security headers grades. Pass `check` to run just one of: smart-audit (Everything at once for a site: domain expiry, HTTPS/TLS, DNS records and email anti-spoofing, as one scored report.); cwv-check (How fast does this page feel to a real browser \u2014 LCP, CLS, TBT and the Lighthouse performance score?); dns-lookup (What does DNS return for this name right now \u2014 A/AAAA/MX/TXT/NS/CNAME/SOA/CAA/SRV and more, optionally from a specific resolver?); dns-propagation (Has a DNS change propagated yet \u2014 what does every one of our probe locations see for this record?); dns-health (Is this domain's DNS set up well \u2014 at least two nameservers on separate networks, no lame delegation, parent and zone agreeing, SOA serials in sync, DNSSEC valid, CAA published \u2014 as an A+\u2026F grade? Add propagation:true to also grade whether every probe location sees the same answer.); whois (Who owns this domain, when does it expire, which registrar and nameservers does the registry list (live RDAP, cache bypassed)?); ping (Is this host reachable by ICMP from a given location, and what is the round-trip time and packet loss?); traceroute (Which network path do packets take to this host from a given location, and where do latency or loss appear?); port-checker (Is this TCP port open from a given location, and what banner does the service send?); blacklist (Is this IP or host listed on the major DNS blocklists (RBLs) that mail servers consult?); ssl-check (What certificate does this host serve \u2014 issuer, subject/SAN names, validity dates and days until expiry?); tls-grade (How good is this host's TLS configuration \u2014 an A+\u2026F grade with the protocol versions, cipher suites and weaknesses behind it?); mcp-check (Is this Model Context Protocol endpoint alive and spec-compliant \u2014 protocol version, capabilities and the tools it advertises?); http-headers (What does this URL actually return right now \u2014 status code, redirect chain, response headers and timing?); api-tester (What does this API endpoint answer to a full request (method, headers, body) \u2014 status, headers and the complete response body?); cdn-check (Which CDN serves this URL, which edge answers in each region, is it actually being cached, and where is delivery going wrong?); sitemap-check (Does this domain publish a valid sitemap, is it reachable from robots.txt, and do its URLs resolve?); brotli-check (Does this domain serve Brotli or gzip compression, and how much bandwidth is it saving?); redirect-chain (Where does this URL end up \u2014 every redirect hop with its status code and Location, the final URL, and whether the chain is longer, slower or less secure than it should be?); websocket-test (Can a WebSocket be opened to this URL \u2014 handshake time, the server's IP, a ping/pong round-trip, and does it answer a message with the expected reply?); smtp-test (Does this mail server accept connections \u2014 its banner, whether STARTTLS is offered, whether reverse DNS matches, and whether it relays mail for strangers?); mail-server-check (How secure are this domain's mail servers \u2014 an A+\u2026F grade per service (inbound MX, SMTP submission, IMAP, POP3) for TLS, certificates, STARTTLS, plain-text login, open relay, MTA-STS, TLS-RPT and DANE, checked from three regions?); ntp-test (Does this NTP server answer, and what stratum, clock offset, round-trip delay and leap indicator does it report per sample?); email-health (Is this domain protected against email spoofing \u2014 are SPF, DKIM and DMARC present and correctly configured?). Graded checks return a `grade`: the same A+ to F letter the WatchFor dashboard shows, its rubric id and the findings that cap it, each with its fix. This measures right now; use check-status or diagnose-incidents for what WatchFor already recorded. Each check spends the organization's per-plan allowance and the response says how much is left.",
"tags": [
"diagnostics",
"network",
"dns",
"tls",
"troubleshooting"
],
"examples": [
"Why can't I reach example.com?",
"Has the DNS change for app.example.com propagated yet?",
"Is port 443 open on db.example.com?",
"What TLS grade does example.com get?"
],
"inputModes": [
"application/json",
"text/plain"
],
"outputModes": [
"application/json",
"text/plain"
]
}
]
}