Skip to main content
Glama

Delegation expiry check

wever_delegation-expiry-check
Read-only

Agent Delegation: submit a delegation setup’s expiry: what ends it (a stated date, a length from issue, the task being done, or nothing) with when it was issued, the end date or the length, when the expiry is checked (before each use, at the start of each task, only at setup, or never), what a lapsed delegation does when used anyway (refused and the principal told, refused, allowed and logged, or allowed), how it is renewed (by the principal on purpose, by itself, or not at all) and whether the principal is warned before it lapses, plus optionally the uses seen with when each happened and whether it went ahead, and the date they are read at. The signed report says whether an expiry is set, whether it is checked before each use or only at setup and what a lapsed delegation does when used anyway, with its end and days left, and names no expiry, a length of forever, an expiry checked only at setup or never, a lapsed use allowed, every use that went ahead after the end and a delegation that renews itself, then an expiry checked only per task, a lapsed use refused without telling the principal, no warning before it lapses and an end with no date or length, with the fix for each. This reads the end set in advance and its enforcement: pulling a delegation back early is wever_delegation-revocation-check, whether a delegation document states an expiry at all is wever_delegation-check and a handoff grant that outlives its task is wever_handoff-scope-check. Verdict never_expires, expiry_gaps, expiry_unverified or expiry_enforced. POST /api/delegation-expiry-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": {
      "expiry": "<expiry>"
    },
    "name": "wever_delegation-expiry-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
usesNoUses seen, with when each happened, to find any after expiry.
as_ofNoThe date the delegation is read at, such as today.
labelNoOptional name recorded in the report.
expiryYes
delegationNoThe delegation, such as the standing vendor payments mandate.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, and the description adds important context beyond them: no network request, fetch, money movement, message, sharing, configuration change, or external write. It also discloses paid access, the X-Wever-Wallet-Proof binding requirement, and that the report carries an Ed25519 signed receipt.

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 description is a long run-on that repeats the expiry-check and lapsed-use behavior in both the input and report portions. It is front-loaded with purpose, but it is poorly compressed and would benefit from shorter structured phrasing.

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 nested five-parameter read-only tool with no output schema, the description supplies the report's verdicts and findings, the auth/payment requirements, and the endpoint details. Nothing critical to invocation or interpretation appears missing.

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 80%, so the schema already documents most nested fields and enum meanings. The description restates the expiry object's fields (set, checked, on_lapsed_use, renewal, warns, dates) and the optional uses/as_of inputs, adding prose clarity but little semantic detail beyond what the schema already provides.

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 the specific resource (a delegation setup's expiry and its enforcement), the inputs it accepts, and the verdicts it returns. It also explicitly distinguishes itself from wever_delegation-revocation-check, wever_delegation-check, and wever_handoff-scope-check.

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

Usage Guidelines5/5

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

It explicitly routes adjacent needs: pulling a delegation back early goes to wever_delegation-revocation-check, merely checking whether a document states an expiry goes to wever_delegation-check, and a handoff grant outliving its task goes to wever_handoff-scope-check. This gives clear when-not-to-use guidance and names alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.