Skip to main content
Glama

Reputation report check

wever_reputation-report-check
Read-only

Agent Reputation: submit one reputation summary written for a buyer or principal: its title and audience and the headline score as written, with whether its scale and the number of jobs behind it sit beside it; whether it states the disputes and the failures, where each sits (beside the headline, in a later section, in an appendix or in a separate document) and how many it reports; whether it states the record’s time window, where it sits and its dates; and optionally the underlying record’s job, dispute and failure counts with its first and last job. The signed report says what sits beside the headline score and checks it against the record, and names a summary that leaves out the disputes, the failures or the record’s time window, or reports none against a record that holds some, then counts below the record’s, disclosures in an appendix or a separate document, a window that differs from the record’s and a headline with no scale or job count, with the fix for each. An evaluation summary’s disclosures are wever_evaluation-report-check, a recommendation’s commercial interest is wever_recommendation-disclosure-check and a trust score computed from verified work is wever_agent-trust-scorecard. Verdict headline_only, report_gaps, report_unverified or report_complete. POST /api/reputation-report-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": {
      "summary": "<summary>"
    },
    "name": "wever_reputation-report-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoOptional name recorded in the report.
recordNo
windowNo
summaryYes
disputesNo
failuresNo

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 readOnly/openWorld annotations, it discloses that the tool reads only the submitted material with no network fetch, money movement, messaging or external write; that it is paid at 0.10 USDC per call on Base via x402 with 10 signed-wallet free calls per 30 days; that X-Wever-Wallet-Proof must bind to the exact JSON arguments and route; and that the response carries an Ed25519 signed receipt. It also enumerates the four verdicts, so the agent knows the shape of the outcome.

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 opening sentence is a ~150-word run-on enumerating every field, which hurts scannability even though the individual clauses each carry information. The content is dense and mostly earns its place, but it should have been split into a purpose sentence plus an input checklist.

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 six-parameter nested-object tool with no output schema, the definition covers inputs, the verdict space, payment and authentication, and the safety envelope. Only the return payload beyond 'a report with an Ed25519 signed receipt' is left implicit, which is acceptable given the enumerated verdicts.

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 17%, so the description carries the burden, and it largely does: it explains that the summary block needs title, audience and the headline score as written, whether scale and job count sit beside it; that disputes and failures are recorded with their stated count and placement; that the window needs its stated flag, placement and dates; and that the record's counts and first/last job are optional. It does not clarify the label field or how placement enum values interact with stated, so it is strong but not 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 description names a specific action (submit one reputation summary plus the underlying record) and a specific product (a signed report that checks disclosures against the record), and it distinguishes itself from three siblings by naming them. The purpose is clear, though it is delivered inside a very long run-on sentence rather than stated up front.

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 the agent explicitly for adjacent cases: evaluation summary disclosures go to wever_evaluation-report-check, recommendation commercial interest to wever_recommendation-disclosure-check, and a trust score computed from verified work to wever_agent-trust-scorecard. It gives no explicit 'when not to use' or exclusions for the near-name siblings (e.g., reputation-record-check, reputation-claim-check), but the positive routing is specific.

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.

Resources