Skip to main content
Glama

Feedback incorporation check

wever_feedback-incorporation-check
Read-only

Agent Feedback: submit the receiver’s response and revision record for one round of feedback on a specific piece of work: optionally the reply to the giver with its text and when it was sent, read for acknowledgement-only wording such as thanks, noted; the revised version with when it was made; and each feedback item with its id, the point as given, whether it was acknowledged to the giver, what the receiver did (changed the work, declined, deferred or nothing), the reason for a decline or deferral, the date a deferred item will be taken up, the change the reply claims for it and whether the revised work holds that change. The signed report gives every item as incorporated, declined_with_reason, deferred_with_date, answered_with_reason, noted_only, claimed_absent, unacknowledged, declined_unreasoned, deferred_undated or unconfirmed, counts the acknowledged, changed, declined and deferred items and the changes present in the revision, and names feedback that did not land: items never acknowledged at all, thanks, noted with no change and no reason, and changes the reply claims that the revised work does not hold; then declines with no reason and deferrals with no date, with the fix for each. This reads one round of response to feedback, not a standing record: an agent’s durable record of completed jobs is wever_reputation-record-check, and a collision between agents’ recorded decisions on shared work is wever_coordination-conflict-check. Verdict feedback_not_landed, feedback_incorporation_gaps, feedback_incorporation_unverified or feedback_incorporated. POST /api/feedback-incorporation-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": {
      "items": "<items>"
    },
    "name": "wever_feedback-incorporation-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemsYesEach feedback item with the receiver’s response.
labelNoOptional name recorded in the report.
replyNo
revisionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, it discloses important operational behavior: no network request, no external write, no party contacted, and no work changed. It also adds payment and authentication details (0.10 USDC on Base via x402, X-Wever-Wallet-Proof binding) and states that the report includes an Ed25519 signed receipt.

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?

The description is dense but front-loads the submission details before moving to report outputs, scope, and payment. Some sentences are long and certain no-side-effect language is repetitive, but most content is necessary for a complex paid check.

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 tool with nested objects and no output schema, the description explains the report’s verdicts, item-level statuses, counts, signed receipt, payment model, and unintended side effects. An agent has enough information to invoke it correctly and understand what comes back.

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?

The description adds substantial meaning to the nested item fields, explaining acknowledgement-only wording, response outcomes, decline/deferral reasons, deferred dates, claimed changes, and whether the revision holds each change. It does not explain the optional top-level label parameter, and some format-level details are left to the schema, so it stops short of full compensation for 50% schema coverage.

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 action and scope: 'submit the receiver’s response and revision record for one round of feedback on a specific piece of work.' It also distinguishes this from sibling checks by naming wever_reputation-record-check for durable records and wever_coordination-conflict-check for shared-work collisions.

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 this check applies: one round of response to feedback, not a standing record or evaluation. It names exclusions (reputation, coordination, evaluation) but does not explicitly compare against the closely related wever_feedback-* siblings such as actionability or closure checks.

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