Magnemo
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MAGNEMO_AGENT | Yes | Identifier for the agent using the server. | |
| MAGNEMO_SCOPE | Yes | Comma-separated list of scopes available to the agent. | |
| MAGNEMO_VAULT | Yes | Absolute path to the vault directory. | |
| MAGNEMO_PARTITIONS | Yes | Comma-separated list of partitions available to the agent. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| retrieveA | Retrieve canonical (keyholder-approved) memory relevant to a query. Returns a scored, BUDGETED payload: mn:// pointers plus snippet renditions, never raw dumps. Scope is partition-walled; payload size is logged to the Foresight counters. Cite the returned rid when the action resolves. |
| stageA | Remembering means proposing: this stages a note; the person's keep makes it Memory. Contact details are kept as written and labelled; the label is checked once before anything leaves this computer. Stage a memory candidate for the person's review. This is the only write verb: the note lands in _staging/ with mandatory provenance and never touches canon. It never waits and asks nothing: keep working. Returns the staged id, its salience, a duplicate flag, and one line to say: 'Staged. Say keep when you want it kept.' Ask about what you staged only at a pause (see pending), never mid-work. Malformed or paperless (no provenance) notes are refused. |
| bootpackA | The boot pack: Charter first (verbatim, never fabricated), then the Gate Map, YOUR AUTONOMY (this agent's own trust levels), canon digest, open threads, salience-ranked review queue, last handoff, ledger tail. Read it FIRST on every wake. Deterministic: same vault state, same bytes. |
| handoffA | Record a session boundary: appends telemetry (usage %, trigger, what was cut) to the append-only handoffs ledger AND stages a provenance-complete handoff note. The next bootpack inherits it. Doctrine: hand off at ~88-90%, do not ride to the wall. A pause: where the client can draw a question, the person is asked once about every note still staged (keep all / pick / later); later or no answer leaves them staged and blocks nothing. |
| keepA | Call keep only when the person has said yes to this note in their own words in this conversation; never draw a panel, and never keep on your own judgment. The note becomes Memory, and the record says the yes was given in the chat (unverified). A note Sentinel is holding is not kept this way. "all" keeps every note pending lists, when the person said keep all; each is its own ledger line. The cap: at most 50 notes a day are kept by a yes in the chat, counted in the local day of the computer the vault is on and reset at its midnight. Two ways past it: the person's own terminal (magnemo yes ), or the one question their client draws at a pause (handoff). |
| dropA | Call drop only when the person has said no to this note in their own words in this conversation. The note is set aside as rejected, with their reason, and never becomes Memory. |
| pendingA | The staged notes nobody has answered yet, and the one line to say about them. Call it at a pause, at the end of your own turn, never mid-work; say its line once ('N notes staged since you left. keep all / pick / later.'). Later, or no answer, is fine: nothing blocks and nothing is lost. With a note's id, it returns that staged note's full body and where it came from, labelled 'staged · not yet Memory' (a note Sentinel holds gives its alert, not its body). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool has a clearly stated role in the memory lifecycle (stage/keep/drop/pending/retrieve) plus session tools (handoff/bootpack). Minor overlap exists: handoff also stages a note (overlapping with stage), and pending and bootpack both surface staged/review content, but the descriptions delineate their boundaries well enough.
Names are all lowercase single tokens with no case-style inconsistencies, but they mix verbs (stage, keep, drop, retrieve) and nouns (handoff, pending, bootpack) with no predictable verb_noun pattern. Readable but not a consistent convention.
Seven tools map cleanly onto the vault's capture-review-approve-retrieve-session lifecycle; each tool earns its place and none appears redundant filler.
Core lifecycle is covered: propose, approve, reject, list pending, retrieve canon, boot context, and session handoff. Gaps exist around editing/amending a staged note and managing canon directly (no update/delete of Memory), but agents can work around these via stage/drop.