agent-memory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {
"listChanged": true
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| memory.fetch_contextA | Return a budgeted, ranked Markdown context pack assembled from the project's .agent-memory/ files. Call this before reading source files manually; the pack contains current task state, conventions, and any sections relevant to the query. An empty query returns the bootstrap pack (local current state + conventions + index summary). |
| memory.propose_updateA | Propose one or more structured edits to the project's .agent-memory/ files. Each operation is validated against the schema, scanned for secrets, and checked for required provenance. Depending on the intent and category, the proposal is either applied immediately or staged under .agent-memory/staging// for human review via the apply/reject CLI commands. A rejected proposal is reported in the response body, not as a transport error. |
| memory.statusA | Report memory health and metadata for the project's .agent-memory/ store: file counts per kind, index + current-state sizes, pending staged proposals (with age, TTL remaining, and drift status per proposal), orphaned branch-local files, secret-scan / git / lock posture. Read-only; never modifies any file. Call this to decide whether memory needs maintenance (stale staging, drifted proposals) before proposing further updates. |
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 3 tools
Each tool has a clearly distinct role: fetching context, proposing updates, and reporting status. There is no overlap or ambiguity in their purposes.
All tools share the consistent memory. namespace and use an action-oriented style. fetch_context and propose_update follow verb_noun, while status is a noun-only deviation, but the pattern remains predictable.
Three tools is well-scoped for a focused memory-management server. Each tool covers a necessary capability without bloat or redundancy.
The set covers the core memory lifecycle: read, write, and health/status inspection. A minor gap is that staged proposals cannot be approved or rejected directly through MCP tools, relying on external CLI commands instead.