A2A (Agent2Agent)
Let other AI agents delegate monitoring tasks to WatchFor over the Agent2Agent protocol — diagnose incidents, check status, and take operator actions.
WatchFor is an A2A (Agent2Agent) agent, so other AI agents can delegate monitoring tasks to it — check status, diagnose what's broken and why, report on incidents and reliability, and take operator actions — without a bespoke integration.
A2A is the horizontal counterpart to our MCP server: MCP connects an agent to WatchFor as a tool; A2A lets an autonomous agent hand WatchFor a task and get a result back.
Endpoint: https://watchfor.io/api/a2a (JSON-RPC 2.0)
Agent Card: /.well-known/agent-card.json
Authentication
Same credentials as the REST API and MCP server (details):
a wf_live_… API key or an OAuth 2.1 access token, passed as a Bearer header.
Read skills need the read scope; the write skills (create monitor,
acknowledge/resolve incident, schedule maintenance) need write. The Agent Card
advertises both schemes so OAuth-capable clients can discover and connect on
their own.
Skills
WatchFor is a deterministic skill executor: a peer agent selects a skill by id and passes its input; WatchFor runs it and returns a completed task with a short human summary plus the structured facts behind it.
The 13 skills are deliberately task-shaped, not raw CRUD: they cover understanding your monitoring and taking the operator actions an agent realistically performs mid-task. Full administrative CRUD (editing alert-rule thresholds, managing contacts, billing) lives on the REST API and MCP server.
Understand & report (read):
| Skill | What it answers / does |
|---|---|
list-monitors | What is being watched — id, name, type, status |
check-status | Is it up right now? (one monitor or the whole org) |
diagnose-incidents | What is broken and why — every active incident, what failed, category, duration |
explain-monitor | Describe one monitor: what it watches, health, uptime, alert rules, recent checks & incidents |
incident-report | What happened in one incident — trigger + full timeline |
list-incidents | Incident history with filters (status, severity, monitor, time range) |
reliability-report | Incident counts and MTTR over a period |
describe-monitor-types | What can be monitored + each type's config fields and alert metrics |
list-locations | Available probe locations (ids for create-monitor) |
Act (write):
| Skill | What it does |
|---|---|
create-monitor | Start watching a target |
manage-monitor | Pause / resume / run-check / update / delete a monitor |
manage-incident | Acknowledge or resolve an incident |
manage-maintenance | Create / list / cancel maintenance windows (e.g. silence alerts during a deploy) |
Calling a skill
Send a JSON-RPC message/send whose message carries a data part selecting
the skill and its input:
curl https://watchfor.io/api/a2a \
--header "Authorization: Bearer wf_live_YOUR_KEY" \
--header "Content-Type: application/json" \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "message/send",
"params": {
"message": {
"role": "user",
"messageId": "1",
"parts": [
{ "kind": "data", "data": { "skill": "diagnose-incidents", "input": {} } }
]
}
}
}'The response is a completed A2A task; the first artifact part is a plain-language summary and the second is the structured data:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"kind": "task",
"status": { "state": "completed" },
"artifacts": [
{
"name": "diagnose-incidents-result",
"parts": [
{ "kind": "text", "text": "2 active incidents: api.example.com — HTTP status code (…)" },
{ "kind": "data", "data": { "active_count": 2, "incidents": [ /* … */ ] } }
]
}
]
}
}If you omit the skill selector, the task comes back input-required with the
list of available skills — so an agent can discover them at runtime.
Notes
- Synchronous. Every skill completes inside
message/send; there are no long-running tasks to poll andmessage/streamis not offered (capabilities.streaming = false). - Behaviour is the API. Each skill calls
/api/v1with your credential, so scopes, per-plan rate limits and validation apply identically.