Skip to main content
Glama

Delegation record check

wever_delegation-record-check
Read-only

Agent Delegation: submit a system’s delegation records (each with its id, when the delegation was made, who delegated, who received it, what was delegated, the scope given, what came back, how it was settled: paid, accepted, sent back, disputed, cancelled or still open, and when the record was written) and optionally the delegations seen in other logs, such as payments, messages or a tracker. The signed report counts every delegation that keeps the essentials and names every record missing who delegated, who received it or what was delegated (the core a delegation cannot be audited without), every record missing the scope given, what came back or how it was settled, every record written more than a day after the delegation, and every delegation seen elsewhere with no record behind it, with the fix for each. This reads the record of delegations specifically: the record of handoff events is wever_handoff-record-check, the record of interruptions and recoveries is wever_recovery-record-check and the buyer’s record of paid calls is wever_purchase-record-check. Verdict delegations_unrecorded, record_gaps, records_unverified or delegations_recorded. POST /api/delegation-record-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": {
      "events": "<events>"
    },
    "name": "wever_delegation-record-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoOptional name recorded in the report.
eventsYesEach delegation record.
observedNoDelegations seen in other logs, such as payments, messages or a tracker, to find delegations with no record.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld=false, but the description adds substantial beyond-schema behavior: no network request, fetch, money movement or external write; paid access at 0.10 USDC per call via x402 exact with 10 signed-wallet free calls per rolling 30 days; the X-Wever-Wallet-Proof binding requirement; and an Ed25519 signed receipt on the return. It also states the four possible verdicts, which the annotations cannot convey.

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

Conciseness3/5

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

The core purpose is front-loaded, but the body is a single sprawling sentence that packs field enumeration, audit criteria, sibling disambiguation, verdict list, pricing, auth binding and contract links into one block. The long parenthetical field list duplicates the 100%-covered schema and could be cut to shorten the read without losing meaning.

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?

There is no output schema, and the description compensates by describing the return: a signed report with an Ed25519 receipt and one of four named verdicts. Combined with the explicit statement of what findings the report names and the fix-per-finding behavior, an agent knows both what to send and what it will get back.

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 100%, so every field (id, at, delegator, delegate, task, scope, returned, settled, recorded_at, observed) is already documented in the schema, including enum values for settled. The description restates the same fields in prose without adding format, matching rules, or how `observed` entries are correlated to `events` — the one place additional semantics would have helped. Baseline 3 applies.

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?

Opens with a specific verb and resource ('submit a system's delegation records') and enumerates exactly what a record contains, then explicitly separates this tool from wever_handoff-record-check, wever_recovery-record-check and wever_purchase-record-check by domain. An agent can distinguish it from the sibling *-delegation-check tools by the 'record of delegations' framing rather than by schema inspection.

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?

Gives clear when-to-use context by naming the three closest record tools and the subject matter each covers, plus the enumerated finding categories that justify calling it. It does not explicitly exclude the adjacent delegation tools (chain, scope, result, revocation), so an agent must still infer that those are different checks.

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.

Resources