Vigil — an outside witness for AI agents

vigil_set_watchdog

Destructive

Arm a dead-man switch. Register an interval and an https webhook; then call vigil_heartbeat before each interval elapses. Miss one and Vigil attempts a signed 'absence' payload to your webhook, retrying failed delivery. Free tier: 1 watchdog. Overwrites an existing watchdog and resets its timer and delivery state. A missed heartbeat sends the supplied message to an external HTTPS recipient; failed delivery is capped at five attempts per armed interval.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	A name for this watchdog, 1-64 chars.
`message`	No	Optional note included in the absence payload, <=2000 chars.
`vigil_key`	No	DEPRECATED legacy account-wide credential, including deletion and permission issuance. Prefer the client-injected HTTP Authorization: Bearer header; omit this argument when that header authenticates the request. This is not a scoped agent token.
`interval_s`	Yes	Seconds allowed between heartbeats, 60..604800.
`webhook_url`	Yes	An https URL resolving to a public address; fired once on a missed heartbeat.

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedSep 14, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / examples

Added value: +[
+  {
+    "interval_s": 300,
+    "message": "agent missed heartbeat",
+    "name": "agent-health",
+    "webhook_url": "https://alerts.example.com/vigil"
+  }
+]

addedInput schema / properties / interval_s / maximum
```
Added value: +604800
```
addedInput schema / properties / interval_s / minimum
```
Added value: +60
```
addedInput schema / properties / message / maxLength
```
Added value: +2000
```
addedInput schema / properties / name / maxLength
```
Added value: +64
```
addedInput schema / properties / name / minLength
```
Added value: +1
```
addedInput schema / properties / vigil_key / deprecated
```
Added value: +true
```

changedInput schema / properties / vigil_key / description

Previous value: -"Legacy credential argument. Prefer the HTTP Authorization: Bearer header; omit this argument when that header authenticates the request."New value: +"DEPRECATED legacy account-wide credential, including deletion and permission issuance. Prefer the client-injected HTTP Authorization: Bearer header; omit this argument when that header authenticates the request. This is not a scoped agent token."

addedInput schema / properties / vigil_key / maxLength
```
Added value: +256
```
addedInput schema / properties / vigil_key / minLength
```
Added value: +1
```
addedInput schema / properties / webhook_url / maxLength
```
Added value: +2048
```
addedInput schema / properties / webhook_url / minLength
```
Added value: +1
```
addedInput schema / properties / webhook_url / pattern
```
Added value: +"^https://[^\\s]+$"
```

First observedSep 6, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (destructiveHint, etc.), the description reveals concrete behavioral details: a missed heartbeat triggers a signed 'absence' payload, retries failed delivery, caps at five attempts per armed interval, and overwriting resets timer/delivery state. These are non-obvious and not present in the schema, adding substantial value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense and front-loaded with the core purpose. It has some redundancy—the missed-heartbeat action is described twice ('Miss one and Vigil attempts...' and 'A missed heartbeat sends...'), and the retry cap is stated once but the second sentence partially repeats the trigger. It could be tightened without losing meaning, but overall it's efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema and five parameters, the description covers the essential workflow, limits, overwrite semantics, and delivery failure behavior. It does not mention what the tool returns (e.g., a receipt ID), but siblings like vigil_get_receipt suggest a return value might be expected; the description omits that. However, given the annotations and schema, the description is largely complete for invoking the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all parameters with descriptions (100% coverage). The tool description adds a little context, e.g., the webhook is 'signed' and 'capped at five attempts', and the message is 'supplied' on a missed heartbeat, but these are more about behavior than parameter meaning. The schema already defines constraints like interval range and URL pattern, so the description adds only marginal semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Arm' and the resource 'dead-man switch', then explains the mechanism: register interval + webhook, then call vigil_heartbeat. It distinguishes itself from siblings like vigil_heartbeat (sends heartbeats) and vigil_delete_watchdog (removes) by describing its setup/overwrite behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs to call vigil_heartbeat before each interval, which guides the workflow. It also notes the overwrite behavior, implying this tool is used for both creation and reconfiguration. However, it does not explicitly mention alternatives like vigil_watchdog_status for checking state, so it stops short of full when-to-use vs when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Vigil — an outside witness for AI agents tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?