Memory Server

memory_server (doc_processing_std_tools.memory, MCP name memory-tools) gives an agent memory that survives across sessions, stored as files in one directory. It offers two interfaces over the same directory: a key-value interface and a file-based interface modelled on Anthropic's memory tool. It needs no extra.

from doc_processing_std_tools import memory_server

Tools

Key-value

Each key is stored as <key>.json in the memory directory, holding {"key": ..., "value": ...}.

Tool	Key parameters	Returns
write_memory	key, value	Confirmation; overwrites an existing value
read_memory	key	The stored value, or an error if the key does not exist
search_memory	query	JSON list of {key, value} whose key or value contains query (case-insensitive)
list_memory_keys	—	JSON list of keys
delete_memory	key	Confirmation

File-based

Paths are relative to the memory directory. Use / or "" for the directory itself.

Tool	Key parameters	Returns
memory_view	path, view_range=[start, end] (1-based, optional)	A directory listing, or the file with line numbers
memory_create	path, file_text	Confirmation; creates parent folders; fails if the file exists
memory_str_replace	path, old_str, new_str	Confirmation; old_str must occur exactly once
memory_insert	path, insert_line (0-based), insert_text	Confirmation; line 0 inserts at the top, the line count appends
memory_delete	path	Confirmation; deletes a file, or a folder with everything in it
memory_rename	old_path, new_path	Confirmation; fails if the destination exists

Environment variables

Variable	Default	Effect here
DPTTOOLS_MEMORY_DIR	./agent_memory	Where memory is stored. Resolved to an absolute path, against the process's working directory, the first time configuration is read

write_memory creates the directory if it does not exist. Mount it as a persistent volume in a container, or memory is lost when the container stops.

Examples

Tool calls are written as Python calls; the model sends the same arguments as JSON.

write_memory(key="client:acme:preferred_format", value="PDF, one file per invoice")
search_memory(query="acme")
memory_create(path="projects/acme/notes.md", file_text="# Acme\n\n- Invoices arrive monthly.\n")
memory_view(path="projects/acme/notes.md", view_range=[1, 20])

Pitfalls

• Paths cannot leave the memory directory. The file-based tools resolve every path inside DPTTOOLS_MEMORY_DIR and refuse one that resolves outside it, including through a symbolic link. This is real containment, unlike the File System server.
• The store root cannot be deleted. memory_delete refuses an empty path, ., / or any path that resolves to the memory directory itself. Any other folder is deleted with all its contents and without confirmation.
• Keys become flat file names. / and \ in a key are replaced with _, so a/b and a_b are the same key. The original key is kept inside the file and returned by list_memory_keys.
• The two interfaces share one folder. The key-value tools treat every top-level .json file as an entry, so a file created with memory_create(path="notes.json", ...) appears in list_memory_keys under its file name. Keep file-based memory in subfolders, or use another extension, to keep the two apart.
• Values are strings. Store structured data as a JSON string and parse it after reading.
• Locking is per process. Within one server process, every tool that changes the store (write_memory, delete_memory, memory_create, memory_str_replace, memory_insert, memory_delete, memory_rename) holds one lock from its checks to the end of the change, so overlapping calls through the composed launcher behave as if they ran one after the other: no lost edits, no half-written entries, and a deleted file is not written back. Two separate server processes writing the same key or file can still overwrite each other's changes, and write_memory simply replaces a value.
• Long results are not truncated. memory_view and search_memory return everything; use view_range on large files.