Vigil — an outside witness for AI agents

vigil_grant_lease

Destructive

Grant a short-lived, Ed25519-signed LEASE authorizing an agent to perform an action until it expires. A customer-run gateway verifies the lease offline (fail-closed) before letting the action through. This is the guard on a money/data-moving action. Free tier: 1 active lease (guarded agent). Security-sensitive: grants authority. Keep this account key outside the controlled agent. A signed lim string is enforced only by the customer's gateway.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "lim": "amount<=100usd",
      "agent": "refund-agent",
      "ttl_s": 60,
      "action": "stripe.refund"
    },
    "name": "vigil_grant_lease"
  }
}

Input Schema

Name	Required	Description
`lim`	No	Optional limit string the gateway enforces, e.g. 'amount<=50usd'.
`agent`	Yes	Identifier for the agent being authorized (1-128 chars).
`ttl_s`	Yes	Lease lifetime in seconds, 5..604800. Keep it short; renew to extend.
`action`	Yes	The action class this lease authorizes, e.g. 'stripe.refund' (1-128 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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedSep 14, 2026

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

addedInput schema / examples

Added value: +[
+  {
+    "action": "stripe.refund",
+    "agent": "refund-agent",
+    "lim": "amount<=100usd",
+    "ttl_s": 60
+  }
+]

addedInput schema / properties / action / maxLength
```
Added value: +128
```
addedInput schema / properties / action / minLength
```
Added value: +1
```
addedInput schema / properties / agent / maxLength
```
Added value: +128
```
addedInput schema / properties / agent / minLength
```
Added value: +1
```
addedInput schema / properties / lim / maxLength
```
Added value: +256
```
addedInput schema / properties / ttl_s / maximum
```
Added value: +604800
```
addedInput schema / properties / ttl_s / minimum
```
Added value: +5
```
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/5.0

Behavior4/5

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

Annotations already declare destructive/non-read-only behavior, but the description adds real behavioral context: the gateway verifies offline and fail-closed, free tier caps active leases, this is security-sensitive, the account key should be kept out of the controlled agent, and the lim string is enforced only by the customer's gateway. It stops short of disclosing what happens if another lease already exists.

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?

Six sentences, with the core action front-loaded and every sentence contributing a distinct fact. The structure is good, though the caveats (free tier, security note, account key, lim enforcement) are a little list-like and could be organized more tightly.

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

Completeness3/5

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

For a sensitive mutating tool there is solid behavioral coverage: offline fail-closed verification, security warnings, and free-tier limits. Yet with no output schema and no return-type mention, an agent cannot confidently know that the call returns a signed lease to hand to the gateway—what the caller receives or how to route it is left implicit.

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 baseline is 3. The description raises that by adding semantic value beyond the schema: it explains that lim enforcement is entirely the customer's gateway's job, and points to the short-lived nature of ttl. It does not need to repeat param definitions since the schema already has them.

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 names a specific verb ('grant'), resource ('Ed25519-signed LEASE'), and intent ('authorizing an agent to perform an action until it expires'), and it positions itself as the guard on money/data-moving actions. This makes it easy to distinguish from the sibling lease tools (verify, renew, revoke, enumerate).

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

Usage Guidelines3/5

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

It implies the usage context—registering the lease before a customer gateway lets the action through—and notes the free-tier one-lease limit. However, it never explicitly contrasts the tool with vigorsh like vigil_renew_lease or vigil_revoke_lease, nor states when not to use it beyond the security warning.

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?