Skip to main content
Glama

Delegation reporting check

wever_delegation-reporting-check
Read-only

Agent Delegation: submit a delegation setup’s reporting duty: whether the delegate owes the delegator reports, how often (such as every 4 hours or daily), in what format (a structured record, a fixed template, free text or none), what each report carries and when failures must be reported (as they happen, in the next scheduled report, at the end of the task, or not at all), how a missed report is noticed (whether it is watched, how soon, and whether the principal or an operator is alerted, the delegation paused, the delegate reminded or nothing happens), plus optionally the reports seen with when each arrived, whether it was scheduled, a failure report or the final one, when a reported failure happened, and the date they are read at. The signed report says whether the delegate owes reports on a stated cadence and format, whether failures must be reported as they happen and whether a delegate that goes quiet is noticed, and names no duty to report, failures held to the end or never reported and silence nobody notices or that changes nothing, then no cadence, no or free-text format, failures held for the next report, a reminder as the only response, slow notice, every gap between reports past the cadence, a delegate quiet now and every failure reported more than an hour late, with the fix for each. This reads the delegate’s standing reporting duty inside a delegation: notice to the principal when a task fails for good is wever_failure-notice-check, where a refused, failed or silent handed-off task goes is wever_handoff-failure-check and task state reporting during recovery is wever_partial-state-check. Verdict silence_passes, reporting_gaps, reporting_unverified or reports_owed. POST /api/delegation-reporting-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": {
      "duty": "<duty>"
    },
    "name": "wever_delegation-reporting-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
dutyYes
as_ofNoThe date the reports are read at, such as today.
labelNoOptional name recorded in the report.
reportsNoReports seen, to find gaps longer than the cadence and failures reported late.
silenceNo
delegateNoWho owes the reports, such as the reconciliation agent.
delegatorNoWho the delegate reports to, such as the finance lead.
delegationNoThe delegation, such as the weekly vendor reconciliation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

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

Annotations already say read-only and closed-world, and the description still adds substantial material: no network request, fetch, message, money movement or external write; a 0.10 USDC x402 charge on Base with 10 free signed-wallet calls per rolling 30 days; the X-Wever-Wallet-Proof binding to the exact JSON arguments and route; and an Ed25519 signed receipt on the return. It also enumerates the four possible verdicts, so the agent knows what a pass/fail looks like before calling.

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 bulk is a single massive run-on sentence that chains every duty field, every silence response and every verdict condition into one breath, with repeated "whether..." clauses that duplicate the schema. The genuinely important facts (verdict set, paid-URL terms, proof binding) are buried late rather than front-loaded, so the reader must parse ~200 words to reach them.

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?

For a payment-gated, nested-object verification tool with no output schema, it covers the practical essentials: what is checked, the four verdicts, the receipt, pricing, auth binding and a contract/page link. The exact shape of the returned report beyond the verdict name is left implicit, which is the main remaining gap.

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 75%, so the schema carries most field-level meaning, but the description adds semantic value by explaining what the inputs jointly prove (owed reporting duty, cadence and format honored, failures surfaced, silence noticed) and by spelling out the gap/late-failure logic that the `reports` array feeds. It repeats a fair amount of what the nested schema already says, which keeps it below 5.

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 opening states a specific verb and resource ("submit a delegation setup's reporting duty") and the mid-section explicitly distinguishes it from wever_failure-notice-check, wever_handoff-failure-check and wever_partial-state-check. The purpose is clear, but the run-on enumeration of duty fields dilutes the opening claim and makes the tool's single-sentence identity harder to extract than it should be.

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 routes the agent away to named siblings for adjacent questions (failure notice, handed-off task failures, partial state during recovery), which is real when-not-to-use guidance. It does not state positive preconditions (e.g., that inputs must be supplied by the caller rather than fetched), leaving some selection inference to the agent.

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.