Skip to main content
Glama
Lyellr88

marm-memory

by Lyellr88
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

marm_distill

Extract durable facts from conversation transcripts, automatically checking against stored memories to flag new, duplicate, or near matches for review before committing.

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.

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.

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)

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
context_typeNogeneral
session_nameNo
include_duplicatesNo

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it does so comprehensively. It discloses the three verdict types (new, duplicate, near), the LLM composition behavior and its fallback to selection, the lack of writing, the side effects of threshold and limit, and the reasoning behind the safety contract. It even warns about limitations of the encoder ('cannot tell "refines it" from "contradicts it") and the selection-only constraint (facts spread over turns or implied are not proposed).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Though lengthy, every sentence earns its place. The description front-loads the core purpose and verdict categories, then explains the LLM vs. selection distinction, the writing contract, and finally a neatly formatted parameter list. It is highly structured and dense with information, avoiding fluff or repetition.

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 10 parameters, no annotations, and no output schema, the description goes beyond the minimum. It explains the return format in prose (status plus proposals/pending, each with content, score, reasons, verdict, cosine, neighbouring memory) and covers all edge cases (LLM fallback, threshold behavior, include_duplicates rationale, session/proposal_id usage). Nothing an agent needs to call this tool correctly is missing.

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%, so the description must fully document parameters. It does so in a dedicated 'Parameters' section, explaining all 10 parameters with defaults, required conditions, and behavioral implications far beyond the schema (e.g., 'threshold: shape-score floor... a higher floor discards real memories long before it meaningfully reduces the count' and 'limit: THIS is the volume control'). It also clarifies the interaction between `use_llm` and operator-enabled generation.

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 opens with a precise statement: 'Propose durable memories from raw conversation, resolved against the store.' It names the specific verb (propose), resource (durable memories), and scope (raw conversation, resolved against the store). It also explicitly contrasts with a sibling (marm_compaction) by referencing the same write contract, making sibling differentiation clear.

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 direct, actionable guidance: 'Pass a transcript as `text`' for propose, explains core behavior (returns verdicts), and clarifies when the LLM path is used vs. selection fallback. It also states the critical constraint: 'NOTHING IS WRITTEN BY `propose`' and that only `apply` writes, with the same contract as marm_compaction. This explicitly tells when to use this tool and when not to, and even references an alternative.

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