Vigil — an outside witness for AI agents

vigil_notarize

Notarize work: POST the sha256 (64 hex chars) of anything and get back an Ed25519-signed, timestamped, hash-chained, serial-numbered receipt. Chain position orders submitted records; the timestamp is a signed assertion of Vigil's clock. Free tier: 10/day. Irreversibly publishes the digest, label and account handle in the public chain; no deletion tool exists. It proves signed-data integrity, not that an action happened or a claim is true.

Input Schema

TableJSON Schema

Name	Required	Description
`label`	No	Optional human label, <=200 chars. Public — do not put secrets here.
`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.
`subject_sha256`	Yes	64 lowercase hex chars: the sha256 of the thing you are notarizing.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedSep 14, 2026

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

addedInput schema / examples

Added value: +[
+  {
+    "label": "public example digest",
+    "subject_sha256": "0000000000000000000000000000000000000000000000000000000000000000"
+  }
+]

addedInput schema / properties / label / maxLength
```
Added value: +200
```
addedInput schema / properties / subject_sha256 / maxLength
```
Added value: +64
```
addedInput schema / properties / subject_sha256 / minLength
```
Added value: +64
```
addedInput schema / properties / subject_sha256 / pattern
```
Added value: +"^[0-9a-fA-F]{64}$"
```
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
```

First observedSep 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations are sparse (readOnlyHint=false, destructiveHint=false, etc.), so the description carries the full burden. It discloses the irreversible publication of digest, label, and account handle in a public chain, states no deletion tool exists, explains the timestamp is a signed assertion of Vigil's clock, and clarifies the proof limits. This is exactly the kind of behavioral context that annotations don't provide.

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

Conciseness5/5

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

The description is compact and information-dense. Every sentence earns its place: the first explains the core operation and output, the second explains chain ordering and timestamp semantics, the third covers rate limits, the fourth covers irreversibility, and the fifth clarifies proof limits. No filler or repetition of schema details.

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

Completeness5/5

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

For a tool with no output schema, the description provides a thorough account of what the receipt contains (Ed25519-signed, timestamped, hash-chained, serial-numbered). It covers the key operational constraints: rate limit, irreversibility, public exposure, and proof limitations. An agent has enough information to decide whether to call this tool and what to expect.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds value by explaining the subject_sha256 format (64 hex chars) and the public nature of the label, which reinforces the schema's warning. It also clarifies that vigil_key is deprecated and not a scoped agent token, which is useful beyond the schema. The description doesn't add much about the output, but the parameters are well covered.

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 states a specific verb ('Notarize work'), the exact input (sha256 hex digest), and the full output (Ed25519-signed, timestamped, hash-chained, serial-numbered receipt). It also distinguishes itself from verification tools by noting it proves signed-data integrity, not action/claim truth. This is clearly differentiated from siblings like vigil_verify_receipt and vigil_verify_source.

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?

The description gives clear context for when to use the tool: to notarize a digest and get a signed receipt. It explicitly states the free tier limit (10/day) and warns about irreversibility, which helps an agent decide whether to call it. It doesn't explicitly name alternative tools for verification, but the closing sentence implies the distinction from verification tools. The irreversibility warning effectively serves as a 'when not to use' signal.

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?