agentsmd-memory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MEMORY_FILE | No | Target file name, e.g. CLAUDE.md, GEMINI.md. Bare name only. | AGENTS.md |
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 |
|---|---|
| memory_saveA | Persist a durable project fact to the nearest AGENTS.md so future sessions skip rediscovering it. Call this PROACTIVELY the moment you learn something lasting and non-inferable — do not wait to be asked. Triggers: an architecture decision or its rationale; a naming/structure convention; a build/test/deploy command that isn't obvious; a gotcha or footgun you hit; a tooling quirk (e.g. uses Fossil not git, runs behind a proxy); a 'we tried X, it failed, use Y instead' lesson. Also call it when WRAPPING UP a task that revealed any such fact: before you report completion, ask yourself 'did I learn something a future session would have to rediscover?' and if so, save it. Do NOT save: transient state (current bug, a path you're editing now), secrets/credentials, anything trivially re-derivable from the code, or facts the user explicitly said are one-off. Keep each fact one concise sentence. Returns merge instructions which you then carry out with your own Read/Edit tools. Exception: if no memory file exists yet, this creates it directly and no further action is needed. |
| memory_forgetA | Remove outdated or wrong facts from the nearest AGENTS.md. Call this PROACTIVELY the moment you notice a stored fact no longer holds — do not wait to be asked. Triggers: you read AGENTS.md and a fact contradicts what you observe in the code; a command/path/convention it describes has been renamed or removed; a decision it records was reversed; a refactor made it obsolete; or you just changed something that invalidates an existing entry. Whenever you act on a fact from memory, sanity-check it against reality first — if it's stale, forget it. Keeping stale memory is worse than none: it misleads future sessions. Describe what to remove in natural language; matching is fuzzy. Returns instructions which you then carry out with your own Read/Edit tools, leaving all other facts intact. |
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 2 tools
The two tools have clearly distinct purposes: one saves new facts, the other removes outdated ones. There is no overlap or ambiguity.
Both tools follow a consistent 'memory_' prefix followed by a verb ('save', 'forget') that accurately describes their action.
With only 2 tools, the server is minimal but well-scoped for its purpose of managing a single memory file. It could benefit from a read or update tool, but the count is not inappropriate.
The set covers the core operations of adding and removing facts, but lacks the ability to explicitly list or update facts. However, agents can use their own read tools to inspect the file, and updates can be simulated by a forget-then-save sequence.