Skip to main content
Glama
Doucs91

Hivelore

by Doucs91
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

mem_feedback

Record whether a saved memory helped or misled your work, marking it applied, rejected, corrected, or verified to drive impact scoring, pruning, and future ranking.

Instructions

Record whether a memory actually HELPED — the closed-loop utility signal.

USE right after a memory changed (or failed to change) what you did:

  • outcome='applied' → the memory steered your work (strong positive signal)

  • outcome='rejected' → it was wrong/outdated/unhelpful (negative signal)

A read only means a memory was surfaced; 'applied' is a reported utility signal, not independently verified proof. This powers hivelore memory impact (impact tiers + prune candidates) and future ranking.

PARAMETERS: id — full memory id the feedback is about outcome — applied | rejected | corrected | verified reference — required for corrected/verified; reported commit or test-report reference catch_id — optional recorded catch identity; linked verified requires a prior correction reason — why it was rejected (optional, stored on the usage record)

RETURNS: { ok, id, outcome, usage:{read_count,applied_count,rejected_count}, impact:{score,tier,signals} }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesFull memory id the feedback is about
reasonNoWhy it was rejected (stored on the memory's usage record). Only used for outcome='rejected'.
outcomeYes'applied' = this memory changed what you did (strong positive utility signal); 'rejected' = it was wrong/outdated/unhelpful (negative signal, blocks auto-promotion).
catch_idNoCatch identity from stats outcomes; verified requires a prior linked correction
referenceNoRequired for corrected/verified: commit, test report or incident reference (reported, not authenticated)
session_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.65.0

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it distinguishes a passive read from a reported utility signal, warns that 'applied' is not independently verified proof, and discloses downstream effects (powers impact tiers and prune candidates, blocks auto-promotion on rejection). It also states conditional requirements for corrected/verified and catch_id linkage.

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?

Front-loaded with the core purpose, then a scannable outcome list, parameter notes, and a return shape. Slightly redundant on the 'not authenticated/not verified' caveat, but no sentence is wasted.

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 6-parameter mutation tool with no output schema, it covers outcome semantics, conditional requirements, and even inlines the return shape (ok, usage counts, impact). The only omission is the undocumented session_id parameter, which is minor.

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 83%, so the baseline is 3, and the description adds real meaning on top: reference is required for corrected/verified and is reported-not-authenticated, catch_id's verified linkage requires a prior correction, and reason is rejected-only. Only session_id goes undocumented in both places.

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?

States a specific verb (record) and resource (memory utility feedback) and frames it as the 'closed-loop utility signal,' which is unambiguous about what is being written. It is distinct from mem_save/mem_get, though it does not explicitly disambiguate against the sibling mem_verify, whose territory partly overlaps with the 'verified' outcome.

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?

Gives explicit timing ('USE right after a memory changed (or failed to change) what you did') and maps outcomes to intent ('applied' = steered work, 'rejected' = wrong/outdated). It does not name alternatives such as mem_verify, leaving an agent to infer the boundary between reporting 'verified' here versus calling mem_verify.

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

Deploy Server

Other Tools