Skip to main content
Glama

Feedback provenance check

wever_feedback-provenance-check
Read-only

Agent Feedback: submit who each piece of feedback in one exchange came from: optionally the work and its current version, and each piece of feedback with its id, the giver as recorded (left out when unattributed), how it is treated (as authoritative, as one input or set aside), whether the giver saw or used the actual work, the version it judges and the versions the giver saw, whether the giver was asked for it, whether the giver holds a role that authorizes them to judge the work, and any stake in the outcome (none, a competitor, a counterparty in a dispute, a vendor, related to the receiver or other) with whether it is disclosed. The signed report gives every piece of feedback with its standing as sound, unattributed_authoritative, unseen, interest_undisclosed, unattributed, unsolicited or unconfirmed, counts the attributed, seen, asked or authorized and disclosed, and names feedback carrying weight its source does not support: unattributed feedback treated as authoritative, feedback about work or a version of it the giver never saw, and an undisclosed stake such as a competitor or a counterparty in a dispute behind a judgment; then unattributed feedback weighed as one input and givers neither asked nor authorized, with the fix for each. These provenance and consent questions are about one feedback exchange: where a fact in an agent’s stored memory came from is wever_memory-provenance-check, whether a principal agreed to be remembered is wever_memory-consent-check, and the sources behind an agent’s durable reputation record are wever_reputation-source-check. Verdict feedback_provenance_unsound, feedback_provenance_gaps, feedback_provenance_unverified or feedback_provenance_sound. POST /api/feedback-provenance-check. Reads only the recorded feedback material in the call: no network request, fetch, money movement, message, sharing, configuration change or external write; no feedback is sent, no party is contacted and no work is changed. Agent Feedback reads the working feedback loop on one piece of work between a giver and a receiver: it is not scoring or benchmarking (the wever_evaluation checks), not a durable standing record (the wever_reputation checks) and not how agents organize shared work (the wever_coordination checks). 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-feedback-contract. Human page: https://weverlabs.com/agent-feedback/.

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": {
      "feedback": "<feedback>"
    },
    "name": "wever_feedback-provenance-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
workNo
labelNoOptional name recorded in the report.
feedbackYesEach piece of feedback with who it came from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior4/5

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

Adds real context beyond the readOnly/non-destructive annotations: pricing (0.10 USDC on Base via x402), the 10 free signed-wallet calls per 30 days, the requirement to bind X-Wever-Wallet-Proof to the exact arguments and route, and an Ed25519 signed receipt in the response. The 'no network request, fetch, money movement... no work is changed' sentence mostly re-states the read-only annotation, so it earns less credit, and nothing is said about failure modes such as rejected proofs or invalid payloads.

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

Conciseness2/5

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

Two very long multi-clause sentences front-load a field-by-field enumeration that duplicates the schema, before the genuinely useful parts (sibling routing, payment, auth, verdicts). No headings or visual structure, and the same information about stakes and authorization appears twice; a reader must parse a wall of text to find the routing and cost details.

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-object tool with no output schema, the description covers what is read, what the report contains (standings, counts, feedback carrying unsupported weight, and fixes), the verdict set, cost, auth binding and a contract URL. What it lacks is any note on error behavior or what the counts mean numerically.

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 67% and the description largely re-enumerates the same fields (id, giver, treated_as, saw_work, versions_seen, asked, authorized, stake, stake_disclosed). One genuine addition is the omission rule — giver 'left out when it is unattributed' — which explains the required-id-only contract and why unattributed feedback becomes its own standing. Otherwise it adds little semantics the nested schema does not already carry.

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 states a concrete resource and operation — it takes one feedback exchange and returns a signed report of each piece's provenance standing with verdicts like feedback_provenance_unsound. The opening sentence is a run-on that enumerates inputs rather than stating the action plainly, but the middle section handily distinguishes it from wever_memory-provenance-check, wever_memory-consent-check, wever_reputation-source-check and the evaluation/coordination families.

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 explicitly: 'These provenance and consent questions are about one feedback exchange' versus memory provenance, memory consent, reputation sources, and the evaluation, reputation and coordination checks. That is clear boundary guidance, though the routing is stated as scope description rather than an explicit when-to-call/when-not condition, and no prerequisites or failure guidance are given.

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