Skip to main content
Glama

Feedback closure check

wever_feedback-closure-check
Read-only

Agent Feedback: submit the loop records for feedback on a specific piece of work: each loop with its id, what the feedback was about, the giver, the resolution state the record holds (done, declined, deferred or open), the reason for a decline or deferral, the date a deferred loop comes back, when the record marks it closed, whether the giver was told the outcome and when, whether the feedback reported a defect in the work, and whether someone verified the fix and who; and optionally the moment to read the loops at. The signed report gives every loop as closed, no_state, closed_untold, fix_unverified, open, declined_unexplained, deferred_undated, deferral_lapsed or unconfirmed, counts the loops by state with the givers told, gives the defect reports with their verification, and names a feedback loop left open: loops with no recorded state at all, closure claimed in the record but never communicated to the giver, and defect reports closed as done with nobody verifying the fix; then loops still marked open, declines with no reason, deferrals with no date and deferrals past their date, with the fix for each. This reads the working loop between one giver and one receiver: how a group of agents escalates and resolves a disagreement is wever_coordination-escalation-check, and an operator’s continuity arrangements for keys, successors and standing jobs are wever_continuity-check. Verdict feedback_loop_open, feedback_closure_gaps, feedback_closure_unverified or feedback_loop_closed. POST /api/feedback-closure-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": {
      "loops": "<loops>"
    },
    "name": "wever_feedback-closure-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
as_ofNoThe moment to read the loops at, for deferrals past their date.
labelNoOptional name recorded in the report.
loopsYesEach feedback loop with its recorded state.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, it discloses important behavior: the payment model, free-call allowance, signed-wallet proof binding, Ed25519 receipt, and that the call performs no network request, message, sharing, configuration change or external write. These details materially help an agent understand cost, auth and side-effect boundaries.

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 purpose is front-loaded, but the text is a long run-on paragraph with repetition of the feedback-loop framing and lengthy enumerations of states and verdicts. Much of the detail is useful, yet it could be structured more cleanly and trimmed without losing substance.

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 complex checker with no output schema, the description is complete: it explains the input loop material, the possible report states, the counts and defect verification output, the open-loop findings, and the verdict taxonomy. An agent has enough context to invoke it correctly and interpret the result shape.

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 coverage is 100%, so the structured descriptions already document each field. The description still adds semantic value by explaining how loop fields drive outcomes, such as untold closures, unexplained declines, undated deferrals, lapsed deferrals and unverified defect fixes, though it does not mention the optional label parameter.

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 description states a specific verb and resource: it reads recorded feedback loops and checks closure, then returns a signed report with verdicts such as feedback_loop_open or feedback_loop_closed. It also distinguishes the tool from related siblings by naming escalation, continuity, evaluation, reputation and coordination checks.

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 gives clear context for when to use it: reading one working feedback loop between a giver and receiver, and it explicitly excludes scoring/benchmarking, durable reputation records and shared-work coordination. It stops short of a crisp when-to-use sentence or explicit exclusions against nearby feedback-* siblings, but the routing context is strong.

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