Wever Labs Agentic Rails

Reputation record check

wever_reputation-record-check

Read-only

Agent Reputation: submit one agent’s reputation record: each entry with its id, the job record it rests on, when the job was completed, the counterparty, the outcome (completed, partial, failed, cancelled or refunded), the rating, the amount and whether a dispute was raised; the job records themselves with their counterparty, date and amount; the totals the record states (jobs, completed, failed, disputed, average rating and total value); the rating scale; and optionally the moment to read it at. The signed report reads the record underneath a score entry by entry, says for each whether it rests on a job record and recomputes every total from the entries listed, and names no entries, entries with no date, entries with no counterparty, outcomes with no underlying job record and totals that do not match the entries listed, then entries with no outcome, entries that differ from their job record, job records left out of the record, entries dated after the read moment and ratings above the scale, with the fix for each. Computing a trust score from verified completed work is wever_agent-trust-scorecard, one job’s payments against its receipts is wever_job-receipt-pack and headline payment numbers with no commerce behind them are wever_volume-quality-check. A worked sample is wever_reputation-profile-sample and the packet checklist is wever_reputation-snapshot, both on https://weverlabs.com/mcp-free. Verdict record_unreliable, record_gaps, record_unverified or record_holds. POST /api/reputation-record-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-reputation-contract. Human page: https://weverlabs.com/agent-reputation/.

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": {
      "entries": "<entries>"
    },
    "name": "wever_reputation-record-check"
  }
}

Input Schema

Name	Required	Description
`jobs`	No	The job records the entries rest on.
`agent`	No
`as_of`	No	The moment to read the record at.
`label`	No	Optional name recorded in the report.
`totals`	No
`entries`	Yes	Each entry in the reputation record.
`rating_scale`	No	The top of the rating scale, such as 5.

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?

Goes well beyond the annotations: it discloses that the call reads only supplied material with no network request, fetch, money movement or external write; states the price (0.10 USDC on Base via x402 exact), the 10 free signed-wallet calls per 30 days, and the X-Wever-Wallet-Proof binding to exact JSON arguments and route; and notes the Ed25519 signed receipt and the four possible verdicts. None of that is derivable from readOnlyHint/openWorldHint alone, and nothing contradicts them.

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?

The core is compressed into one enormous semicolon-chained sentence that is hard to parse and buries the verdicts and payment terms at the tail. Most sentences carry substantive information, but the density and lack of front-loading hurt readability, and the dual URL/prose pointers (sample tools, contract, human page) add some redundancy.

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 seven-parameter tool with no output schema, the description covers the input shape, the exact checks the report performs, the verdict set, the payment and authentication mechanics, and the signing of the result. It does not spell out the report's response structure, but it describes the findings and fixes closely enough that an agent knows what comes back.

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?

With 71% schema coverage the baseline is 3, but the description adds real meaning by enumerating the entry fields (id, backing job record, completion date, counterparty, outcome, rating, amount, dispute), the job-record fields, the five stated totals, the rating scale and the optional read moment. It also explains how each field is used in validation (totals recomputed from entries, entries dated after as_of flagged), which the schema does not convey. Minor gap: the agent object's id/name/platform and the label parameter are not discussed.

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?

States a specific verb and resource: submit one agent's reputation record (entries, backing job records, stated totals, rating scale, optional as_of) and receive a signed entry-by-entry check. It explicitly separates itself from wever_agent-trust-scorecard, wever_job-receipt-pack and wever_volume-quality-check, so an agent can choose without opening the 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?

The closing paragraph names three concrete alternatives and the condition each covers (computing a trust score, one job's payments against receipts, headline volume with no commerce behind it), which effectively routes the agent. It also points to the sample and checklist tools. What is missing is an explicit 'do not use this when' clause for adjacent *-record-check siblings, but the differentiation is clear.

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?