Skip to main content
Glama
Lyellr88

marm-memory

by Lyellr88
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

marm_distill

Extract durable facts from raw conversation transcripts, checking each against stored memories to flag new, duplicate, or near-match candidates for review before any write.

Instructions

Propose durable memories from raw conversation, resolved against the store.

Pass a transcript as `text` and this returns the sentences in it that read
like durable facts, each already checked against what is stored: `new`
(nothing close), `duplicate` (already recorded), or `near` (close to
something stored -- worth your judgement, because an encoder cannot tell
"refines it" from "contradicts it").

With `use_llm=True`, once the operator has enabled local generation, it
composes a self-contained fact, and every generated proposal cites a
VERBATIM span from the transcript, checked against the source before it is
offered.

By default, and whenever no model is enabled and reachable, it SELECTS
sentences: a fact spread over three turns, or implied but never said
plainly, will not be proposed.

By default NOTHING IS WRITTEN BY `propose`. Proposals are staged for
review, and only `apply` writes one -- the same contract as
marm_compaction, for the same reason: a similarity score is not evidence
enough to change memory unattended. The one exception is
review_mode="guardrails" with auto-apply switched on, where `propose`
also applies each proposal that passes every deterministic check.

Parameters:
- action: propose | review | apply | discard (default propose)
- text: the conversation to distil (required for propose)
- session_name: session the proposals belong to (required for propose;
  optional filter for review)
- proposal_id: which proposal to act on (required for apply/discard)
- project: scope name recorded on the memory that `apply` writes
- context_type: memory context type for the write (default general)
- threshold: shape-score floor, default 0.20. Excludes chatter and little
  else; measured against the live store, a higher floor discards real
  memories long before it meaningfully reduces the count
- limit: most proposals to return (default 20). THIS is the volume control
- include_duplicates: also stage what the store already holds (default off,
  because a queue of known facts does not get read)
- use_llm: write facts with the local model (default off; needs the
  operator to have enabled generation, and falls back to selection)
- review_mode: "manual" (default) stages everything for review;
  "guardrails" also applies a proposal that passes every deterministic
  check, only when the operator has switched auto-apply on

Returns: status plus `proposals` (propose) or `pending` (review), each
carrying content, score, the reasons it scored, verdict, cosine, and the
neighbouring memory when there is one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNo
limitNo
actionNopropose
projectNo
use_llmNo
thresholdNo
proposal_idNo
review_modeNo
context_typeNogeneral
session_nameNo
include_duplicatesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.57.0
    • addedInput schema / properties / review_mode
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Review Mode"
+}
  2. Changed1 schema field changedv2.52.0
    • addedInput schema / properties / use_llm
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Use Llm"
+}
  3. Addedv2.51.0

TDQS

A4.9/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: it discloses the staged-write contract, that only `apply` persists, the auto-apply guardrail condition, the operator-gating and fallback for use_llm, and that generated proposals cite verbatim spans verified against the source. It also explains what selection mode will not catch (facts spread over turns or implied).

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?

It is long but front-loaded: purpose, then resolution semantics, then LLM/selection behavior, then write contract, then a clean parameter list and return summary. There is minor redundancy—two separate paragraphs both open with 'By default' to restate the no-write behavior—which keeps it just short of a 5.

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?

Given 11 parameters, zero schema descriptions, no annotations, and no output schema, the description covers everything an agent needs: mode semantics, defaults, the write contract, LLM prerequisites and fallback, and an explicit summary of the return payload (status plus proposals/pending with content, score, verdict, cosine, and neighbour).

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 description coverage is 0% across 11 parameters, so the description must compensate and it does—every parameter is given purpose, defaults, and operational nuance (e.g. threshold's floor 'discards real memories long before it meaningfully reduces the count', limit as 'THIS is the volume control', include_duplicates default off because a known-facts queue goes unread).

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 opening line states a specific verb+resource scope: 'Propose durable memories from raw conversation, resolved against the store.' It further differentiates itself by explicitly naming the sibling it shares a contract with (marm_compaction), so an agent can place it without opening any schema.

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?

The description gives explicit mode routing (propose | review | apply | discard), states the default behavior ('By default NOTHING IS WRITTEN BY propose'), and names the single exception (review_mode="guardrails" with auto-apply on). It also states when use_llm applies and that it silently falls back to selection, so the agent knows what to expect in each configuration.

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