Skip to main content
Glama

Feedback request check

wever_feedback-request-check
Read-only

Agent Feedback: submit one feedback request on a specific piece of work, as recorded: optionally the request itself with the work it names, its text as sent, when it went out and the time to respond by; the criteria it asks givers to judge the work against; and each party it went to, with whether that party saw or used the work and their relation to it (a user, a reviewer, the principal, a peer, a stakeholder or other). The signed report gives the request with any open-invitation wording it uses and the window to respond in days, every recipient as saw_work, never_saw_work or unstated, and the criteria, and names a request that leaves the loop unfocused: no specific work named, or work named only as everything or my work; no criteria, or an open invitation such as any feedback welcome in their place; and recipients who never saw or used the work; then a request with no time to respond by and a request with no named recipients, with the fix for each. This reads one request for feedback before any feedback arrives, not a formal evaluation: an evaluation’s design is wever_evaluation-design-check and scoring an agent against a rubric is wever_evaluation-scoring-check, and how a group of agents plans and splits shared work is wever_coordination-plan-check. Verdict feedback_request_unfocused, feedback_request_gaps, feedback_request_unverified or feedback_request_focused. POST /api/feedback-request-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

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "wever_feedback-request-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoOptional name recorded in the report.
requestNo
criteriaNoThe criteria the request asks givers to judge the work against, such as totals reconcile with the ledger.
recipientsNoEach party the request went to, with whether they saw or used the work.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that reads are strictly local to the call payload (no fetch, no messaging, no external write, no party contacted, no work changed), which is concrete corroboration of readOnlyHint and openWorldHint=false. It also adds behavior annotations do not carry: x402 pricing at 0.10 USDC on Base, 10 signed-wallet free calls per rolling 30 days, the requirement to bind X-Wever-Wallet-Proof to the exact JSON arguments and route, and an Ed25519 signed receipt on return.

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?

The definition is a single sprawling sentence chain with semicolon-separated clauses, so the essential fact (this checks one feedback request, offline, for gaps) is not front-loaded. Content is duplicated: the exclusions of evaluation scoring, reputation and coordination are stated twice in slightly different words, and the 'what gets reported' material is spread across two long passages.

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-parameter tool with no output schema, the description does cover the return shape (request, criteria, recipients as saw_work/never_saw_work/unstated, verdict labels, signed receipt) and the auth/payment preconditions. It falls short of fully complete because the four verdict names are listed but not individually defined, leaving an agent to infer when each is returned.

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?

With 75% schema coverage the schema already documents most fields, but the description adds interpretive meaning: it explains which request conditions make the loop 'unfocused' (no specific work named, work named only as 'everything' or 'my work'; no criteria or an open invitation substituted; recipients who never saw the work) and what the report renders for each recipient. It does not add format or validation guidance for label, sent_at, or respond_by beyond what the schema states.

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 specific verb and resource: read/check one recorded feedback request before any feedback arrives, with named verdicts (feedback_request_unfocused, feedback_request_gaps, feedback_request_unverified, feedback_request_focused). It explicitly separates itself from wever_evaluation-design-check, wever_evaluation-scoring-check and wever_coordination-plan-check, so an agent can place it among siblings. Clarity is reduced only by the dense run-on first sentence, which buries the verb inside a long clause chain.

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 a clear temporal condition ("before any feedback arrives") and explicitly rules out evaluation design, rubric scoring and coordination planning, pointing to the right alternatives by name. However, the many other feedback-* checks (actionability, closure, freshness, gaming, incorporation, provenance, report) are neither named nor excluded, so an agent must still infer which feedback check applies for those aspects.

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