Wever Labs Agent Products

Delegation revocation check

wever_delegation-revocation-check

Read-only

Agent Delegation: submit a delegation setup: who can revoke it (the principal, the principal or an operator, only an operator, only the delegate, or no one) and how the principal does (on their own, by asking, or not at all), whether it can be revoked while a task is under way, when a revocation takes hold (at once, at the delegate’s next call, at its next task, at the next sync or by hand) and how long it takes against a stated target, what happens to work in flight when it lands (halted, rolled back, allowed to finish the step, or left running on the old authority), what happens to authority the delegate passed on and whether the principal is told, plus optionally the revocations seen with when each was made and took hold and whether work went on after. The signed report says whether the principal can revoke the delegation mid-task, how fast the revocation takes effect and what happens to work already in flight, and names no way to revoke, revocation only by an operator or the delegate, revocation only between tasks, work left running and every revocation work went on after, then revocation on request, a revocation deferred to the next task, a sync or a hand step, a revocation slower than the target, authority passed on that survives, no confirmation and every revocation that took hold late, with the fix for each. This reads pulling a delegation back early: the end set in advance is wever_delegation-expiry-check, halting a whole agent system is wever_kill-switch-check and whether a delegation document states revocation terms is wever_delegation-check. Verdict cannot_pull_back, revocation_gaps, revocation_unverified or revocable_mid_task. POST /api/delegation-revocation-check. Reads only the material in the call: no network request, fetch, money movement, message, sharing, configuration change or external write. Paid URL: 0.10 USDC per call on Base via x402 exact, with the shared 10 signed-wallet free calls per rolling 30 days. Bind X-Wever-Wallet-Proof to the exact JSON arguments and the tool route. Returns a report with an Ed25519 signed receipt. Contract: /api/agent-delegation-contract. Human page: https://weverlabs.com/agent-delegation/.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "revocation": "<revocation>"
    },
    "name": "wever_delegation-revocation-check"
  }
}

Input Schema

Name	Required	Description
`label`	No	Optional name recorded in the report.
`target`	No	How soon a revocation should take hold, such as 1 minute.
`principal`	No	Who the delegation acts for, such as the finance director.
`delegation`	No	The delegation, such as the vendor payments mandate.
`revocation`	Yes
`revocations`	No	Revocations seen or tested, with when each took hold.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Beyond the read-only/closed-world annotations it discloses pricing (0.10 USDC per call on Base via x402 exact), a rate limit (10 signed-wallet free calls per rolling 30 days), an authentication requirement (bind X-Wever-Wallet-Proof to the exact JSON arguments and the tool route), the side-effect boundary (no network request, fetch, money movement, message, sharing, configuration change or external write), and the return shape (a report with an Ed25519 signed receipt). It also enumerates the possible verdicts. That is a lot of behavior an agent cannot get from the annotations alone.

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

Conciseness2/5

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

The definition is a dense run-on that spends its opening clauses re-listing input fields already documented in the schema, and the actual purpose appears mid-paragraph. Sentences such as 'This reads pulling a delegation back early' are grammatically awkward and slow comprehension. The pricing, auth and verdict details earn their place, but the front-loading and structure do not.

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?

There is no output schema, so the description carries the return-value burden, and it does: it names the report's contents, the four verdicts, the failure findings the report surfaces, and links the contract and human page. For a nested six-parameter read-only check, that is close to complete; only the uncovered schema parameter and pagination/limits on the revocations array are left implicit.

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?

Schema description coverage is 83%, so the schema already explains most fields, including every revocation enum. The description's prose list of revocation options (who can revoke, how, mid-task, in-flight, passed_on, takes_effect) largely restates those enum descriptions and adds no format or validation detail. Baseline 3 applies; the description neither compensates for the uncovered 17% nor adds meaning beyond the schema.

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

Purpose4/5

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

The description does state a specific verb and resource: it takes a delegation setup and a signed report says 'whether the principal can revoke the delegation mid-task, how fast the revocation takes effect and what happens to work already in flight.' It also names what it is not (expiry-check, kill-switch-check, delegation-check). The purpose is real but buried behind a long enumeration of input fields, so it is clear on a second read rather than a first.

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 routes the agent to alternatives: 'the end set in advance is wever_delegation-expiry-check, halting a whole agent system is wever_kill-switch-check and whether a delegation document states revocation terms is wever_delegation-check.' That is clear when-to-use-this-vs-that guidance. It does not state any exclusion or precondition for using this tool itself, and the routing sentence is phrased obliquely ('This reads pulling a delegation back early').

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

All Wever Labs Agent Products 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.