Skip to main content
Glama

Delegation chain check

wever_delegation-chain-check
Read-only

Agent Delegation: submit a delegation chain as supplied: the principal at the top, the work it serves, whether the whole chain is kept as one record, and each hop in order with who delegates to whom, the tasks, spending ceiling, tools, data and end passed on, and whether the principal can see that hop. The signed report lays the hops end to end, says hop by hop whether the scope narrowed, held or grew against the hop above, whether the scope narrowed overall and whether the chain’s full length is visible to the principal, and names every hop that passes on tasks, tools or data the hop above lacks, a higher ceiling or a later end, and every hop that drops a bound the hop above states, then every hop out of the principal’s sight, every hop that does not link to the one above, a first hop that does not start from the principal and a chain kept in no one record, with the fix for each. This reads authority as it passes down a chain of delegations: who held one task at each step is wever_chain-of-custody-check, approver bands are wever_approval-chain-check and one handoff’s grant against what its task needs is wever_handoff-scope-check. A summary sample is wever_delegation-chain-sample on https://weverlabs.com/mcp-free. Verdict authority_grew, chain_gaps, chain_unverified or authority_narrowed. POST /api/delegation-chain-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": {
      "hops": "<hops>"
    },
    "name": "wever_delegation-chain-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
hopsYesEach hop in order, from the principal down.
taskNoThe work the chain serves, such as vendor payments.
labelNoOptional name recorded in the report.
recordedNoThe whole chain is kept as one record the principal reads, not pieced together from separate logs.
principalNoWho stands at the top of the chain, such as the finance director.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations it discloses cost (0.10 USDC on Base via x402 exact), the free-tier quota (10 signed-wallet calls per rolling 30 days), an auth requirement (bind X-Wever-Wallet-Proof to the exact JSON arguments and route), the output artifact (report with Ed25519 signed receipt), and the verdict space. It also explicitly enumerates what the report will flag, so the agent knows what failures to expect.

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?

Purpose, cost and auth are front-loaded correctly, but the middle is two long run-on sentences that enumerate every individual report check in a comma-spliced list, which is hard to parse and partly redundant with 'whether the scope narrowed, held or grew'. The content is largely non-filler, but the formatting costs readability.

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 single-endpoint read-only checker with no output schema, the description covers the input shape, the verdict enum, the signed-receipt return, pricing, auth binding, a contract path and a sample tool. Nothing an agent needs in order to call it correctly is missing.

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, but the description adds meaning the schema does not: hops must be 'in order' from the principal down, the chain is submitted 'as supplied', and 'recorded' is framed as the chain being one principal-readable record rather than pieced-together logs. That ordinal and interpretive guidance is genuinely useful when constructing the call.

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 and resource ('submit a delegation chain', 'Reads authority as it passes down a chain of delegations') and then explicitly distinguishes itself from three named siblings: chain-of-custody, approval-chain and handoff-scope. An agent can tell exactly which question this tool answers without opening any schema.

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 from adjacent tools with stated domains ('who held one task at each step is wever_chain-of-custody-check, approver bands are wever_approval-chain-check, one handoff's grant ... is wever_handoff-scope-check'), which effectively communicates when not to use it. It does not state an explicit triggering condition such as 'use when the chain has two or more hops', so the when-to-use side is implied rather than spelled out.

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.