Skip to main content
Glama

Delegate vetting check

wever_delegate-vetting-check
Read-only

Agent Delegation: submit a delegator’s selection flow: the delegate chosen, the task and when it was handed over, how the delegate’s identity was checked (verified, taken on its own word, or not checked) and against what (a registry record, a signed credential, an attester, a prior working relationship or other), whether a track record was looked at, where it came from (a public record, an attester, the delegator’s own history or the delegate’s own claims), whether it covers comparable work and was public before the delegate’s first engagement, and whether fit for this task was checked, with what the task needs and what the delegate showed, each with when it was checked. The signed report says whether the delegate was checked before the handoff on identity, track record on comparable work and fit for this task specifically, and names an unchecked or self-declared identity, no track record looked at and every check done after the handoff, then a self-reported or non-comparable record, a record assembled after first use, fit not checked and every need not shown met, with the fix for each. This reads the delegator’s diligence before the handoff: whether a purchase receipt’s buyer identity matches its delegation is wever_delegated-identity-check, one identity record’s own consistency is wever_agent-identity-check and whether a handoff route checks its receiver against the registry is wever_receiver-identity-check. Verdict stranger_handoff, vetting_gaps, vetting_unverified or delegate_vetted. POST /api/delegate-vetting-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": {
      "delegate": "<delegate>"
    },
    "name": "wever_delegate-vetting-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
fitNo
taskNoThe work handed over, such as reconciling the October invoices.
labelNoOptional name recorded in the report.
delegateYesThe delegate chosen, such as the invoice reconciliation agent.
identityNo
delegatorNoWho hands the work over, such as the procurement agent.
handoff_atNoWhen the work was handed over.
track_recordNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations, it discloses that the call reads only supplied material with no network fetch, money movement, message, sharing, or external write — resolving the apparent tension between readOnlyHint=true and a POST endpoint. It adds the payment model (0.10 USDC on Base via x402 exact, 10 signed-wallet free calls per rolling 30 days), the auth binding (X-Wever-Wallet-Proof bound to exact JSON arguments and route), and that the response 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.

Conciseness3/5

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

It is one dense run-on block; the identity/track record/fit fields are effectively enumerated twice — once as inputs and once as report contents — which is defensible given no output schema, but the repetition costs clarity. Nothing is strictly filler, yet the lack of sentence breaks or ordering makes the definition slow to parse for an agent deciding whether to call it.

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 paid, signed, read-only evaluation tool with no output schema, it supplies the verdict vocabulary, receipt signing, payment and auth mechanics, and a contract link, which is nearly everything an agent needs. The notable gap is that the four verdicts are listed without the conditions that trigger each, so an agent cannot predict which verdict its input will produce.

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 63% with eight parameters and nested identity/track_record/fit objects. The description adds real meaning beyond the field labels: identity 'verified' means checked against something the delegate does not control, track record source distinguishes public record, attester, delegator history, and delegate claims, and it flags the substantive distinctions (public before first engagement vs. assembled after, comparable work, needs shown by name). It does not clarify which combinations are optional or how partial submissions are scored.

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 description names a concrete resource (a delegator's vetting of the delegate chosen, the task, handoff time, identity method, track record, fit) and states the output shape as a signed report with four named verdicts, plus the route POST /api/delegate-vetting-check. It also explicitly distinguishes itself from three similarly named siblings (wever_delegated-identity-check, wever_agent-identity-check, wever_receiver-identity-check). The verb is somewhat buried inside a long enumeration ('submit a delegator's selection flow'), so the core action takes work to extract, but the scope is unmistakable.

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 gives a clear selection rule: this tool reads the delegator's diligence before the handoff, whereas delegated-identity-check handles receipt-to-delegation buyer identity matching, agent-identity-check handles one record's internal consistency, and receiver-identity-check handles route receiver lookup. It also implies usage context via the enumerated verdicts. It stops short of explicit exclusions or prerequisites (e.g., what constitutes a well-formed submission for a given verdict), so it is strong but not complete.

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.