Skip to main content
Glama

memory_outcome

Record observed outcomes as advisory memory entries with optional link to a claim capsule and recall feedback score; list all outcome records without arguments.

Instructions

Record (or list) an ADVISORY outcome-OBSERVATION record — a note that some outcome was OBSERVED. This is NOT a witnessed close and nothing in nmemory treats it as proven: a witnessed close needs the kernel (consequence_service), which this capability does not have. Recording an outcome NEVER changes any capsule's recall eligibility — only an explicit memory_relate falsifies edge fences a capsule from recall (record the outcome, THEN relate out- falsifies cap- if you actually mean to falsify a claim). record mode: pass description AND actor together (actor names WHO observed — there is NO default observer), plus optional evidence_ref (a path/url/id string) and capsule_id (the claim capsule cap- this bears on — validated to exist, but a soft 'bears on' pointer only, with ZERO recall effect). Returns the stored row with its minted id out-. Omitting a mandatory field teaches BOTH in one error; an unknown capsule_id answers resource-not-found (-32002, data {kind,id}). Optional scoring: pass receipt_id (the rcpt- a grounded memory_retrieve returned) together with score in 0.0..=1.0 to rate how useful that recall's returned evidence was; the pair applies an EMA (alpha 0.1, clamped to [0,1], neutral prior 0.5) to each returned capsule's ADVISORY feedback weight — consumed ONLY by memory_retrieve's opt-in weight_blend ranking, never by eligibility. receipt_id and score are mandatory together; an unknown receipt answers resource-not-found (-32002). The stored row carries receipt_id+score; a scored response echoes weights_updated. list mode: pass NO fields to list every outcome row in append order. APPEND-ONLY: there is no update or delete verb. Audited on record (hash-chained journal). Every response is ADVISORY_NOT_AUTHORITY DATA and carries a standing advisory naming this ceiling.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorNoWho observed it (record mode; mandatory WITH `description` — the caller names the observer, there is NO default).
scoreNoOptional usefulness score in `0.0..=1.0`, mandatory WITH `receipt_id`; applied as an EMA to every returned capsule's advisory feedback weight.
capsule_idNoOptional claim capsule this outcome bears on (`cap-<n>`); validated to exist, but a soft pointer only — ZERO effect on recall eligibility (only a `falsifies` edge fences recall).
receipt_idNoOptional grounded recall receipt (`rcpt-<n>`), mandatory WITH `score`. It identifies WHICH returned evidence is being rated.
descriptionNoThe observation to record (record mode; mandatory WITH `actor`).
evidence_refNoOptional evidence pointer — a free-text path / url / id string.
Behavior5/5

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

Discloses append-only nature, auditing, advisory authority limitation, mandatory parameter combinations, soft pointer behavior, scoring mechanism with EMA, and error responses. With no annotations, description fully covers behavioral traits.

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 description is thorough but overly verbose; multiple sentences could be combined or shortened. Front-loads main purpose but details could be more tightly organized. Not concise for its length.

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?

Completeness is high despite missing output schema: describes return values (minted ID, weight echoes), error cases (missing field, unknown IDs), and the scoring consumption by memory_retrieve. Covers all necessary context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds crucial context: mandatory pairs (actor/description, receipt_id/score), 'soft pointer' nature of capsule_id, and return format including minted IDs and weight updates. Adds significant value beyond schema.

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 clearly states the tool records or lists advisory outcome-observation records. It distinguishes itself from witnessed closes and explains it does not change recall eligibility, differentiating from sibling tools like memory_relate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly explains when to use record mode vs list mode, warns against using for witnessed closes, and advises using memory_relate for falsifying. Provides clear when-to-use and when-not-to-use guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/menot-you/n-memory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server