Skip to main content
Glama
Sign In

Wever Labs Agentic Rails

by com.weverlabs
OverviewDiscussionsAdmin

Feedback freshness check

wever_feedback-freshness-check
Read-only

Agent Feedback: submit the feedback being relied on now about a specific piece of work: optionally the work with its current version and each version with when it was released and whether it is still in use; each piece of feedback with its id, the point as given, the version it is about, when it was given, its tone, how it is relied on now (as evidence of quality, as the basis for a change, as an open issue or other), the id of later feedback on the same point that supersedes it and a later change that already answers it; the moment it is relied on; and how many days old praise may be and still count as current evidence of quality (180 when left out). The signed report gives the work and its versions, every piece of feedback as current, version_gone, stale_praise, superseded, answered, earlier_version or unconfirmed with its age in days, and the oldest and newest ages, and names feedback that no longer describes the work: acting today on feedback about a version no longer in use, and old praise presented as current evidence of quality; then feedback superseded by later feedback on the same point, feedback a later change already answers, and feedback about an earlier version with no record of whether it still applies, with the fix for each. How an agent’s durable reputation score ages is wever_reputation-decay-check, drift in an evaluation’s results is wever_evaluation-drift-check, and whether an agent’s knowledge entries are current is wever_knowledge-freshness-check. Verdict feedback_stale, feedback_freshness_gaps, feedback_freshness_unverified or feedback_current. POST /api/feedback-freshness-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-freshness-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
workNo
as_ofNoThe moment the feedback is relied on, to read its age against.
labelNoOptional name recorded in the report.
feedbackYesEach piece of feedback being relied on now.
max_age_daysNoHow many days old feedback may be and still count as current evidence of quality; 180 when left out.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds substantial behavior beyond them: no network request, no external write, no feedback sent, no party contacted, no work changed. It also discloses the paid cost (0.10 USDC on Base via x402), the 10 free signed-wallet calls per 30 days, the wallet-proof binding requirement, and that the report carries 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.

Conciseness2/5

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

The second sentence is a single sprawling clause that re-enumerates every feedback subfield already documented in the schema, which duplicates structured data rather than adding value. The verdict list and the exception categories are useful, but the run-on structure with no paragraph breaks makes the definition hard to scan and front-loading is weak.

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, five-parameter tool with no output schema, the description does the heavy lifting by describing the signed report's structure, the seven possible feedback statuses, the age statistics, and the verdict set. The remaining gap is that it does not explain how malformed references (e.g. a superseded_by id not present) are handled, but an agent has enough to call it correctly and interpret the result.

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 description coverage is 80%, so the baseline is 3; the description goes further by explaining what the inputs mean in aggregate, e.g. the work with its current version and each version's release and in-use status, and how feedback is relied on now (evidence of quality, basis for change, open issue). It also restates the max_age_days default of 180 and the as_of moment semantics, adding framing the schema alone only partly conveys.

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 opening clause states a concrete action and resource: 'submit the feedback being relied on now about a specific piece of work', and it names the verdicts returned. It is clearly distinguishable from the reputation, evaluation and knowledge checks, but the core purpose is buried at the head of a very long field-enumeration sentence, so the signal is weaker than it should be.

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 rules out three neighboring tool families ('not scoring or benchmarking (the wever_evaluation checks), not a durable standing record (the wever_reputation checks) and not how agents organize shared work'), which is real when-not-to-use guidance. What it does not do is distinguish itself from the many other feedback-* checks in the catalog (provenance, actionability, closure, gaming), so an agent choosing within that cluster gets no help.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Wever Labs Agentic Rails toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources