Wever Labs Agentic Rails

Reputation source check

wever_reputation-source-check

Read-only

Agent Reputation: submit the sources behind one reputation record or score: each source with its id, kind (self-reported, a platform record, a counterparty attestation, a third-party audit, an on-chain record, a payment receipt or other), its issuer, whether it is independent of the agent and its operator, whether a third party can check it, when it was produced or last confirmed and how the record shows it (as verified, as self-reported or unlabeled); each claim with the source ids it rests on, whether it is presented as current and how it is shown; and optionally the subject agent and headline score, how old a source may be and still carry a current claim (12 months when left out) and the moment to read it at. The signed report says source by source whether it is self-reported, independent, checkable and how old it is, and claim by claim what it rests on, and names self-reported history presented as verified, a single source behind every claim, current claims resting only on sources too old to support them and claims with no source, then sources shown as verified that nobody else can check, claims resting only on parties tied to the agent, undated sources and self-reported history shown with no label, with the fix for each. Quoted endorsements against their source text are wever_testimonial-evidence-check, one claim against supplied evidence is wever_claim-evidence-check and a one-call brief on a counterparty is wever_counterparty-brief. Verdict sourcing_weak, sourcing_gaps, sourcing_unverified or sourcing_sound. POST /api/reputation-source-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": {
      "sources": "<sources>"
    },
    "name": "wever_reputation-source-check"
  }
}

Input Schema

Name	Required	Description
`as_of`	No	The moment to read the sources at.
`label`	No	Optional name recorded in the report.
`claims`	No	Each claim the record or score makes.
`max_age`	No	How old a source may be and still support a current claim, such as 12 months; 12 months when left out.
`sources`	Yes	Each source behind the record or score.
`subject`	No

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?

Far beyond the annotations, the description discloses cost (0.10 USDC per call on Base via x402 exact), a free-call allowance (10 signed-wallet calls per rolling 30 days), the X-Wever-Wallet-Proof binding to exact JSON arguments and route, and the Ed25519 signed receipt. It also states the read-only envelope concretely — 'no network request, fetch, money movement, message, sharing, configuration change or external write' — which reinforces openWorldHint=false with specifics the annotations cannot carry.

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, alternatives, verdicts, payment and safety are sensibly front-loaded in that order, and most sentences earn their place. The middle section is a single long run-on sentence enumerating the report's findings and then its warnings, which is dense but still parseable, and the kind enumeration mildly duplicates the schema.

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 six-parameter, nested-object tool with no output schema, the description carries the return-side burden well: it states what the signed report covers source-by-source and claim-by-claim, lists the four verdict values, and points to the contract and human page. Payment, auth and read-only scope are all covered, leaving nothing essential an agent needs in order to call it correctly.

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 description coverage is 83%, so the schema already documents as_of, label, max_age, claims, sources and subject sub-fields. The description restates the source kinds and the 12-month max_age default that the schema already encodes, adding little new meaning; it does not clarify, for example, what dated strings are accepted or how source ids are matched to claims.

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 opening clause names a specific verb and resource — 'submit the sources behind one reputation record or score' — and immediately scopes the inputs (sources, claims, optional subject/score, max_age, as_of). It also names the verdict set and sibling tools, so an agent can distinguish this from wever_claim-evidence-check and wever_testimonial-evidence-check without opening a 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 three near-neighbours explicitly: quoted endorsements go to wever_testimonial-evidence-check, a single claim against supplied evidence to wever_claim-evidence-check, and a one-call counterparty brief to wever_counterparty-brief. What is missing is differentiation from the other reputation-* siblings (record-check, report-check, claim-check), and there is no explicit 'do not use this when...' exclusion.

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?