Wever Labs Agentic Rails

Deliverable check

wever_deliverable-check

Read-only

DiligenceOps: submit a job’s acceptance criteria and the delivered work’s text, metadata or both, with optional supporting evidence. The signed checklist marks each criterion addressed, missing or not met, measuring counts, sizes, durations and file formats where the delivery states them, and lists claims in the deliverable (figures, certainty, superlatives) that the supplied material does not support. POST /api/deliverable-check. Reads only the material in the call: no page fetch, no account access, no merchant contact and no money movement. 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/diligence-checks-contract. Human page: https://weverlabs.com/diligence-checks/.

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": {
      "acceptance_criteria": "<acceptance_criteria>",
      "deliverable": "<deliverable>"
    },
    "name": "wever_deliverable-check"
  }
}

Input Schema

Name	Required	Description
`evidence`	No	Optional supporting material for claims the deliverable makes: test output, analytics, sources. Up to 256 KB.
`deliverable`	Yes	The delivered work: its text, its metadata, or both.
`acceptance_criteria`	Yes	The job’s acceptance criteria as a list, or as text with one criterion per line or sentence.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the read-only and non-destructive annotations, it discloses the exact data boundary, pricing, rolling free-call allowance, wallet-proof binding, and signed receipt. It also explains important result behavior: measurements are made where stated by the delivery, and unsupported figures, certainty claims, and superlatives are flagged.

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

Conciseness4/5

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

Purpose and output are front-loaded, followed logically by scope, pricing, authorization, and receipt details. It is nevertheless a dense single paragraph with several appended endpoints and reference links, which reduces scanability despite minimal redundancy.

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?

With no output schema, the description usefully supplies the report’s checklist statuses, measurements, unsupported-claim findings, and Ed25519 signed receipt. Combined with the complete input schema and annotations, its operational, cost, and authorization details leave no major selection or invocation behavior undocumented.

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 coverage is 100% and already documents all three parameters, including the nested deliverable and evidence forms. The description mostly restates those roles; its evaluation details clarify behavior but add little new per-parameter syntax or invocation guidance.

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?

It identifies the exact operation and resources: compare a job’s acceptance criteria with delivered text, metadata, or both, optionally using supporting evidence. The addressed/missing/not-met checklist and unsupported-claim reporting distinguish it functionally from the sibling claim-, data-, and terms-evidence checks.

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?

The job-and-deliverable framing makes the intended post-delivery verification scenario clear, while the no-fetch and no-account-access boundary explains when the supplied material is insufficient. It does not explicitly route agents to related tools for other kinds of checks, so alternative selection remains inferential.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Wever Labs Agentic Rails 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.

Resources

Need Help?