Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MAGNEMO_AGENTYesIdentifier for the agent using the server.
MAGNEMO_SCOPEYesComma-separated list of scopes available to the agent.
MAGNEMO_VAULTYesAbsolute path to the vault directory.
MAGNEMO_PARTITIONSYesComma-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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 7 tools

Disambiguation4/5

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.

Naming Consistency3/5

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.

Tool Count5/5

Seven tools map cleanly onto the vault's capture-review-approve-retrieve-session lifecycle; each tool earns its place and none appears redundant filler.

Completeness4/5

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.

Maintenance

ActivityActive
ResponsivenessNo issues