Wever Labs Agent Products

Delegation scope check

wever_delegation-scope-check

Read-only

Agent Delegation: submit one delegation as supplied: who delegates to whom, where its bounds are written (a delegation record both sides read, a message to the delegate, only code or configuration, or nowhere), when they were written and when work started, the tasks the delegate may do and whether the list ends in open wording, whether it may spend with the ceiling and what it counts over (the whole delegation, each task, each payment, a day, a week or a month), the tools and data it may use, and what ends it (the task being done, a date, a length of time, only a revocation, or nothing). The signed report says bound by bound whether the scope is stated before work starts, which tasks, what spend, which tools and data and for how long, and names bounds written nowhere, bounds written after work started, no named tasks, open task wording, spending with no ceiling and no end, then bounds set only in code, unstated spending, a ceiling with no period, unnamed or open tools and data, an end only on revocation and an end with no date or length, with the fix for each. This audits the written bounds of one delegation from the delegator’s side: whether a delegation or mandate document marks its grantee, caps, expiry, revocation and approvals present is wever_delegation-check, issuing a signed mandate is wever_delegated-authority and what each receiver gets against what its task needs in an agent-to-agent handoff is wever_handoff-scope-check. A one-record restatement is wever_delegation-snapshot on https://weverlabs.com/mcp-free. Verdict blank_check, scope_gaps, scope_unverified or scope_bounded. POST /api/delegation-scope-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": {
      "delegation": "<delegation>"
    },
    "name": "wever_delegation-scope-check"
  }
}

Input Schema

Name	Required	Description
`data`	No
`label`	No	Optional name recorded in the report.
`spend`	No
`tasks`	No
`tools`	No
`duration`	No
`delegation`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.3/5.0

Behavior5/5

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

The description stays consistent with the readOnly/openWorld=false annotations and adds substantial behavior the annotations cannot convey: it reads only the material supplied (no fetch, money movement, message, sharing or external write), it is a paid x402 call at 0.10 USDC with 10 signed-wallet free calls per rolling 30 days, and it requires X-Wever-Wallet-Proof bound to the exact JSON arguments and route. It also states the output shape (Ed25519 signed receipt) and the four verdict values, which is unusually rich for a tool with no output schema.

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?

Nearly every clause carries information (routing, payment, auth binding, verdicts), so this is density rather than padding. But the first two sentences are 100+ word run-ons with no line breaks, forcing the reader to parse a field inventory before reaching the purpose and the sibling routing. Restructuring into short labeled blocks would preserve content and cut parse cost significantly.

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 nested, 7-parameter audit tool with no output schema, the definition covers what an agent needs: inputs, verdict vocabulary, signed receipt, side-effect profile, payment and wallet-proof requirement, and the contract path. What's missing is minor — no explicit note on required versus optional nested blocks and no error or failure behavior. The core calling decision is fully supported.

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 description coverage is only 14%, so the description must carry the load, and it largely does: it walks through who delegates to whom, where bounds are written, when they were written versus when work started, tasks and open wording, spend ceiling and the period it counts over, tools and data, and end conditions. These map onto the nested objects and their enums (written, per, ends). It never mentions the optional 'label' field and doesn't clarify which nested objects are optional, so it isn't quite exhaustive.

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 definition names a specific action (submit one delegation record) and a specific output (a signed, bound-by-bound report on written scope), so the resource and verb are unambiguous. It also explicitly separates itself from wever_delegation-check, wever_delegated-authority and wever_handoff-scope-check. The only drag is ordering: the opening sentence enumerates inputs at length before the sentence that actually states 'this audits the written bounds of one delegation from the delegator's side'.

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 routes the agent explicitly: existence of grantee/caps/expiry/revocation in a mandate document goes to wever_delegation-check, issuing a mandate goes to wever_delegated-authority, and matching receiver scope to task need in a handoff goes to wever_handoff-scope-check. It also names wever_delegation-snapshot for a one-record restatement. Selection among these near-identical siblings is fully determined by reading the description.

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.