Skip to main content
Glama

Feedback report check

wever_feedback-report-check
Read-only

Agent Feedback: submit the feedback summary written for the principal, with the records behind it: its title, its audience, its headline as written and optionally its text; whether it states the negative feedback, the declined items (with how many carry their reasons), the open loops (and whether it presents them as resolved) and the gaming flags found in the set, where each sits (beside the headline, in a later section, in an appendix or in a separate document) and how many it names; whether it presents an average and whether the disagreement underneath sits beside it; and optionally the record of negative items, declined items, open loops, gaming flags and points on which givers disagree. The signed report gives the summary with any praise-only wording, the disclosure of each kind of record and of the average, and the record, and names a summary that whitewashes the feedback: negative feedback left out or stated as none while the record holds some, so it reports only praise; open loops left out or presented as resolved; gaming flags left out; and an average presented without the disagreements underneath it; then declined items left out or without their reasons, counts below the record’s, disclosures in an appendix or a separate document, and wording such as great feedback or overwhelmingly positive while the record holds negative feedback, with the fix for each. An agent’s durable reputation summary is wever_reputation-report-check, and an evaluation summary of scores is wever_evaluation-report-check. Verdict feedback_summary_whitewashed, feedback_summary_gaps, feedback_summary_unverified or feedback_summary_faithful. POST /api/feedback-report-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": {
      "summary": "<summary>"
    },
    "name": "wever_feedback-report-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoOptional name recorded in the report.
recordNo
summaryYes
averagesNo
declinedNo
negativeNo
open_loopsNo
gaming_flagsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds real value with the no-network/no-write scope, the x402 pricing of 0.10 USDC per call, the 10 free signed-wallet calls per 30 days, and the X-Wever-Wallet-Proof binding requirement. It does not say whether the verdict is stable across repeated calls despite idempotentHint=false, nor describe the signed receipt contents.

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 enormous run-on sentences pack the whole payload inventory, the verdict list, the routing rules, the pricing, the auth binding and the security scope into undifferentiated prose. The purpose statement is not front-loaded; the opening clause starts with "Agent Feedback: submit..." rather than stating what the check does. The information is there but the structure makes it hard to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter, deeply nested tool with no output schema and 13% schema coverage, the description should explain how the nested objects are interpreted and what the verdicts mean operationally. It lists the verdict names (feedback_summary_whitewashed, gaps, unverified, faithful) but never says what distinguishes unverified from gaps, so an agent cannot predict the outcome. Pricing and contract links are covered well, but the core semantics are thin.

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 only 13%, so the burden is on the description, and it does help by enumerating the semantic content: title, audience, headline, whether negative feedback is stated, declined items with reason counts, open loops and whether shown as resolved, gaming flags with placement, averages and spread. However it does not clarify the relationship between the nested `record` counts and the `summary`/`declined`/`negative` counts, which is the main source of ambiguity, nor the meaning of the placement enum trade-offs. Useful but not sufficient to fully compensate for the low coverage.

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 verb and resource: it takes a feedback summary written for a principal plus the records behind it and checks it, returning a verdict. It also distinguishes itself from the sibling checks (reputation, evaluation, coordination), so the agent can place it precisely. It loses a point only because the core purpose is buried mid-paragraph after a long list of payload fields.

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 explicitly excludes the evaluation, reputation and coordination checks and gives the concrete negative case ("not scoring or benchmarking", "not a durable standing record"). It never states when the tool should not be called, e.g. what to do with an incomplete record, so it falls short of a 5.

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