What can you do with this server?

The TeleMem server provides a long-term, semantic memory management system for AI agents, enabling persistent storage and intelligent retrieval of memories scoped by user, agent, or run/session. It operates as an MCP server, integrating with MCP-compatible AI clients. * add_memory: Store facts, preferences, or conversation turns into memory, with optional LLM-based fact extraction (infer=True) or verbatim storage (infer=False). * search_memories: Perform natural-language semantic search over stored memories, with configurable result limits and similarity thresholds. * get_memories: List all memories for a given scope (user, agent, or run), including shared event memories. * get_memory: Fetch a single memory by its unique ID. * update_memory: Overwrite the text and/or metadata of an existing memory. * delete_memory: Remove a single memory by ID. * delete_all_memories: Bulk delete all memories within an explicitly provided scope (requires explicit scope to prevent accidental deletion). * memory_history: View the full change history (ADD/UPDATE/DELETE events) for a specific memory, enabling auditability and debugging.

Which integrations are available for this server?

Provides memory management layer that can be integrated with LangChain for long-term and multimodal memory in agentic AI applications. Supports local LLM configurations via Ollama for memory summarization and retrieval.

telemem

by TeleAI-UAGI

Overview Schema Related Servers Score Discussions

Python

Local

If you find this project helpful, please give us a ⭐️ on GitHub for the latest update.

🤝 Contributions welcome! Feel free to open an issue or submit a pull request.

TeleMem is an agent memory management layer that can be used as a high-performance drop-in replacement for Mem0 with one line of code (import telemem as mem0), deeply optimized for complex scenarios involving multi-turn dialogues, character modeling, long-term information storage, and semantic retrieval.

Through its unique context-aware enhancement mechanism, TeleMem provides conversational AI with core infrastructure offering higher accuracy, faster performance, and stronger character memory capabilities.

Building upon this foundation, TeleMem implements video understanding, multimodal reasoning, and visual question answering capabilities. Through a complete pipeline of video frame extraction, caption generation, and vector database construction, AI Agents can effortlessly store, retrieve, and reason over video content just like handling text memories.

The ultimate goal of the TeleMem project is to use an agent's hindsight to improve its foresight.

TeleMem, where memory lives on and intelligence grows strong.

Why TeleMem?

🎭 Character memory done right — the only open-source memory layer that automatically builds isolated, per-character memory profiles, built for role-play, companion AI, NPCs, and multi-persona assistants.
🎬 Memory for video, not just text — a full video → frames → captions → vector DB pipeline with ReAct-style multi-step video QA.
🏠 Fully local by default — runs end-to-end on your hardware (Qwen + FAISS); no cloud service, no paid tier, no data leaving your machine.
🔌 mem0-compatible API — add() / search() accept the same arguments and return the same {"results": [...]} shapes, so existing Mem0 code keeps working.

📢 Latest Updates

[2026-08-15] 🎉 TeleMem v1.10.0 adds first-class DeepSeek Harness support: an opt-in Cordis/MCP patch starts TeleMem with uvx, registers all 8 memory tools under mcp__telemem__*, and securely forwards provider configuration. See the MCP server docs.
[2026-08-06] 🎉 TeleMem v1.9.0 is on the latest MCP standard: migrated to the official MCP Python SDK v2 (spec 2026-07-28) — all 8 tools now declare titles, behavior annotations, and structured output, while staying compatible with older MCP clients. See the MCP server docs.
[2026-07-11] 🎉 TeleMem v1.8.0 — the "claims = contracts" release: character-memory extraction fix, infer=False/prompt/memory_type now fully honored, offline contract test suite, telemetry disabled by default, and a multi-NPC demo!
[2026-06-12] 🎉 TeleMem v1.7.1 is live on the official MCP registry — run the memory server with zero install: uvx telemem! Also new: evaluation principles and a LongMemEval harness with built-in baselines.
[2026-06-12] 🎉 TeleMem is now on PyPI: pip install telemem! v1.6.0 adds Ollama/DeepSeek/Kimi configs, LangChain & LlamaIndex examples, and a documentation site.
[2026-06-12] 🎉 TeleMem v1.5.0 has been released: true mem0 drop-in API, lightweight core install, and CI!
[2026-06-11] 🎉 TeleMem v1.4.0 has been released with MCP support!
[2026-01-28] 🎉 TeleMem v1.3.0 has been released!
[2026-01-22] 🎉 TeleMem Tech Report has been updated to its 4th version!
[2026-01-13] 🎉 TeleMem Tech Report has been released on arXiv!
[2026-01-09] 🎉 TeleMem v1.2.0 has been released!
[2025-12-31] 🎉 TeleMem v1.1.0 has been released!
[2025-12-05] 🎉 TeleMem v1.0.0 has been released!

Related MCP server: Rememb

🔥 Research Highlights

Significantly improved memory accuracy: Achieved 86.33% accuracy on the ZH-4O Chinese multi-character long-dialogue benchmark, 19% higher than Mem0.
Doubled speed performance: Millisecond-level semantic retrieval enabled by efficient buffering and batch writing.
Greatly reduced token cost: Optimized token usage delivers the same performance with significantly lower LLM overhead.
Precise character memory preservation: Automatically builds independent memory profiles for each character, eliminating confusion.
Automated Video Processing Pipeline: From raw video → frame extraction → caption generation → vector database, fully automated
ReAct-Style Video QA: Multi-step reasoning + tool calling for precise video content understanding

📌 Table of Contents

Project Introduction

TeleMem enables conversational AI to maintain stable, natural, and continuous worldviews and character settings during long-term interactions through a deeply optimized pipeline of character-aware summarization → semantic clustering deduplication → efficient storage → precise retrieval.

flowchart LR
    A["Dialogue<br/>messages"] --> B["Character-aware<br/>summarization<br/>(global + per-character)"]
    B --> C["Embedding +<br/>similar-memory<br/>retrieval"]
    C --> D["Write buffer<br/>(batch flush)"]
    D --> E["LLM semantic<br/>clustering & fusion"]
    E --> F[("FAISS index +<br/>JSON metadata")]
    Q["Query"] --> S["Vector search<br/>+ rerank"]
    F --> S
    S --> R["results"]

Features

Automatic memory extraction: Extracts and structures key facts from dialogues.
Semantic clustering & deduplication: Uses LLMs to semantically merge similar memories, reducing conflicts and improving consistency.
Character-profiled memory management: Builds independent memory archives for each character in a dialogue, ensuring precise isolation and personalized management.
Efficient asynchronous writing: Employs a buffer + batch-flush mechanism for high-performance, stable persistence.
Precise semantic retrieval: Combines FAISS + JSON dual storage for fast recall and human-readable auditability.

Applicable Scenarios

Multi-character virtual agent systems
Long-memory AI assistants (e.g., customer service, companionship, creative co-pilots)
Complex narrative/world-building in virtual environments
Dialogue scenarios with strong contextual dependencies
Video content QA and reasoning
Multimodal agent memory management
Long video understanding and information retrieval

TeleMem vs Mem0: Core Advantages

TeleMem deeply refactors Mem0 to address characterization, long-term memory, and high performance. Key differences:

Capability Dimension	Mem0	TeleMem
Multi-character separation	❌ Not supported	✅ Automatically creates independent memory profiles per character
Summary quality	Basic summarization	✅ Context-aware + character-focused prompts covering key entities, actions, and timestamps
Deduplication mechanism	Vector similarity filtering	✅ LLM-based semantic clustering: merges similar memories via LLM
Write performance	Streaming, single writes	✅ Batch flush + concurrency: 2–3× faster writes
Storage format	SQLite / vector DB	✅ FAISS + JSON metadata dual-write: fast retrieval + human-readable
Multimodal Capability	Single image to text only	✅ Video Multimodal Memory: Full video processing pipeline + ReAct multi-step reasoning QA

Experimental Results

Dataset

We evaluate the ZH-4O Chinese long-character dialogue dataset constructed in the paper MOOM: Maintenance, Organization and Optimization of Memory in Ultra-Long Role-Playing Dialogues:

Average dialogue length: 600 turns per conversation
Scenarios: daily interactions, plot progression, evolving character relationships

Memory capability was assessed via QA benchmarks, e.g.:

{
"question": "What is Zhao Qi's nickname for Bai Yulan? A Xiaobai B Xiaoyu C Lanlan D Yuyu",
"answer": "A"
},
{
"question": "What is the relationship between Zhao Qi and Bai Yulan? A Classmates B Teacher and student C Enemies D Neighbors",
"answer": "B"
}

Experimental Configuration

LLM: Qwen3-8B (thinking mode disabled)
Embedding model: Qwen3-Embedding-8B
Metric: QA accuracy
Method
Overall(%)
RAG
62.45
Mem0
70.20
MOOM
72.60
A-mem
73.78
Memobase
76.78
TeleMem
86.33

Quick Start

Installation

pip install telemem            # core (text memory)
pip install "telemem[mcp]"     # + MCP server
pip install "telemem[video]"   # + video/multimodal pipeline
pip install "telemem[all]"     # everything

Development Environment

Using uv (recommended — creates .venv from the committed uv.lock for a reproducible environment):

uv sync --all-extras   # install TeleMem (editable) + all extras, incl. MCP
uv run python examples/quickstart.py

Or with conda + pip:

# Create and activate virtual environment
conda create -n telemem python=3.10
conda activate telemem
# Install from source (editable), with the extras you need
pip install -e ".[all]"

Example

Set your OpenAI API key:

export OPENAI_API_KEY="your-openai-api-key"

# python examples/quickstart.py
import telemem as mem0

memory = mem0.Memory()

messages = [
    {"role": "user", "content": "Jordan, did you take the subway to work again today?"},
    {"role": "assistant", "content": "Yes, James. The subway is much faster than driving. I leave at 7 o'clock and it's just not crowded."},
    {"role": "user", "content": "Jordan, I want to try taking the subway too. Can you tell me which station is closest?"},
    {"role": "assistant", "content": "Of course, James. You take Line 2 to Civic Center Station, exit from Exit A, and walk 5 minutes to the company."}
]

memory.add(messages=messages, user_id="Jordan")
results = memory.search("What transportation did Jordan use to go to work today?", user_id="Jordan")
for hit in results["results"]:   # same result shape as mem0
    print(hit["memory"])

Memory() uses the default provider settings inherited from mem0ai. To use the repository's local Qwen + FAISS configuration, load config/config.yaml explicitly:

from telemem.utils import load_config
import telemem as mem0

config = load_config("config/config.yaml")
memory = mem0.Memory(config=config)

The runnable examples also honor the same configuration through TELEMEM_CONFIG:

TELEMEM_CONFIG=config/config.yaml python examples/quickstart.py

Using MiniMax as the LLM Provider

TeleMem supports MiniMax as an LLM backend via its OpenAI-compatible API. A ready-to-use example config is provided at config/config.minimax.yaml.

export MINIMAX_API_KEY="your-minimax-api-key"
export OPENAI_API_KEY="your-openai-api-key"  # still needed for embeddings

from telemem.utils import load_config
import telemem as mem0

config = load_config("config/config.minimax.yaml")
memory = mem0.Memory(config=config)

Key points for MiniMax usage:

LLM: MiniMax M3 (1M context, default) via https://api.minimax.io/v1; MiniMax M2.7 (204,800 context) is also available. MiniMax-M3 accepts text, image and video input and supports adaptive thinking; MiniMax-M2.7 is text-only with always-on thinking
Regional endpoints: use https://api.minimax.io/v1 (global) or https://api.minimaxi.com/v1 (China) as openai_base_url
Temperature: must be in (0.0, 1.0] — set explicitly (e.g. 0.7) to avoid out-of-range errors
Embeddings: MiniMax does not provide a public embedding API; configure a separate embedder (e.g. text-embedding-3-small) in the embedder section

More LLM Providers

TeleMem works with any OpenAI-compatible endpoint. Ready-to-use config examples ship in config/:

Provider	Config file	LLM	Embeddings	Notes
Ollama (fully local)	`config.ollama.yaml`	any local model (e.g. `qwen3:8b`)	`nomic-embed-text`, local	No API key, no cloud — everything runs on your machine
DeepSeek	`config.deepseek.yaml`	`deepseek-chat` / `deepseek-reasoner`	external (e.g. OpenAI)	`DEEPSEEK_API_KEY` + `OPENAI_API_KEY`
Moonshot (Kimi)	`config.moonshot.yaml`	`kimi-k2-0905-preview`	external (e.g. OpenAI)	`.cn` and `.ai` endpoints supported
MiniMax	`config.minimax.yaml`	`MiniMax-M3`	external (e.g. OpenAI)	see section above

TELEMEM_CONFIG=config/config.ollama.yaml python examples/quickstart.py   # 100% local memory

Project Structure

telemem/
├── assets/                 # Documentation assets and figures
├── baselines/              # Baseline implementations for comparative evaluation
│ ├── RAG                   # Retrieval-Augmented Generation baseline
│ ├── MemoBase              # MemoBase memory management system
│ ├── MOOM                  # MOOM dual-branch narrative memory framework
│ ├── A-mem                 # A-mem agent memory baseline
│ └── Mem0                  # Mem0 baseline implementation
├── config/               
│ ├── config.yaml           # TeleMem default configuration
│ └── config.minimax.yaml   # MiniMax provider example configuration
├── data/                   # Small sample datasets for evaluation or demonstration
├── examples/               # Code examples and tutorial demos
│ ├── quickstart.py         # Quick start
│ ├── quickstart_mm.py      # Quick start (multimodal)
│ ├── mcp_client.py         # Quick start over MCP (stdio client)
│ ├── mcp_config.json       # MCP config snippet for Claude Desktop / Cursor
│ └── deepseek-harness.cordis.yml # DeepSeek Harness memory patch
├── docs/
│ ├── MCP.md                # MCP server reference
│ └── TeleMem_Tech_Report.pdf
├── telemem/                # Telemem code
│ └── mcp/                  # Model Context Protocol server
├── tests/                  # Telemem test
├── README.md               # English README
├── README-ZH.md            # Chinese README
└── pyproject.toml          # Python environment

Core Functions

Add Memory (add)

The add() method injects one or more dialogue turns into the memory system.

def add(
 self,
 messages,
 *,
 user_id: Optional[str] = None,
 agent_id: Optional[str] = None,
 run_id: Optional[str] = None,
 metadata: Optional[Dict[str, Any]] = None,
 infer: bool = True,
 memory_type: Optional[str] = None,
 prompt: Optional[str] = None,
 batch: bool = False,
)

🔎 Parameter Description

Parameter	Type	Required	Description
`messages`	`str` or `List[Dict[str, str]]`	✅ Yes	A single statement, or a list of dialogue messages with `role` (`user`/`assistant`) and `content`
`user_id`	`Optional[str]`	❌ No	Character/user to attribute the memory to; TeleMem keeps an independent memory profile per `user_id`. Omit it to store shared conversation-event memories
`agent_id` / `run_id`	`Optional[str]`	❌ No	Additional mem0-compatible scopes (e.g. one `run_id` per session)
`metadata`	`Optional[Dict[str, Any]]`	❌ No	Arbitrary metadata stored with each memory
`infer`	`bool`	❌ No	Extract salient facts with the LLM (default: `True`); `False` stores message contents verbatim with no LLM call
`memory_type`	`Optional[str]`	❌ No	Pass `"procedural_memory"` to create procedural memories via mem0's pipeline; omit for conversational memories
`prompt`	`Optional[str]`	❌ No	Custom extraction prompt (replaces the optimized default as the system prompt)
`batch`	`bool`	❌ No	Route through the high-throughput batched pipeline (`add_batch`)

Returns the mem0-compatible shape: {"results": [{"id": "...", "memory": "...", "event": "ADD"}, ...]}

🔁 Internal Workflow of `add()`

Message preprocessing: Merge consecutive messages from the same speaker; normalize turn structure.
Multi-perspective summarization:
- Global event summary
- Character 1’s perspective (actions, preferences, relationships)
- Character 2’s perspective
Vectorization & similarity search: Generate embeddings and retrieve existing similar memories.
Batch processing: When buffer threshold is reached, invoke LLM to semantically merge similar memories.
Persistence: Dual-write to FAISS (for retrieval) and JSON (for metadata).

🎭 Multi-character demo: examples/multi_npc.py runs five tavern NPCs through one scene — a single add_batch(scene, user_id=[...]) call gives each NPC a private memory profile plus a shared "events" world-state, and each NPC then recalls the scene from their own perspective.

Search Memory (search)

Performs semantic vector-based retrieval of relevant memories with context-aware recall.

def search(
 self,
 query: str,
 *,
 user_id: Optional[str] = None,
 agent_id: Optional[str] = None,
 run_id: Optional[str] = None,
 limit: int = 100,
 filters: Optional[Dict[str, Any]] = None,
 threshold: Optional[float] = None,
 rerank: bool = True,
)

🔎 Parameter Description

Parameter	Type	Required	Description
`query`	`str`	✅ Yes	Natural language query
`user_id`	`Optional[str]`	❌ No	Character/user profile to search. The shared event memories (pseudo-user `"events"`) are always searched as well
`agent_id` / `run_id`	`Optional[str]`	❌ No	Additional mem0-compatible scope filters
`limit`	`int`	❌ No	Max number of results (default: 100)
`threshold`	`Optional[float]`	❌ No	Similarity threshold (0–1; auto-tuned if omitted)
`filters`	`Dict[str, Any]`	❌ No	Custom filters (e.g., by character, time range)
`rerank`	`bool`	❌ No	Whether to rerank results (default: `True`)

Returns the mem0-compatible shape: {"results": [{"id": "...", "memory": "...", "score": ..., ...}, ...]}

🔍 Search is based on FAISS vector retrieval, supporting millisecond-level responses.

Multimodal Extensions

Beyond text memory, TeleMem further extends multimodal capabilities. Drawing inspiration from Deep Video Discovery's Agentic Search and Tool Use approach, we implemented two core methods in the TeleMemory class to support intelligent storage and semantic retrieval of video content.

Method	Description
`add_mm()`	Process video into retrievable memory (frame extraction → caption generation → vector database)
`search_mm()`	Query video content using natural language, supporting ReAct-style multi-step reasoning

Add Multimodal Memory (add_mm)

def add_mm(
    self,
    video_path: str,
    output_dir: str,
    clip_secs: int | None = None,
    emb_dim: int | None = None,
    subtitle_path: str | None = None,
)

🔎 Parameter Description

Parameter	Type	Required	Description
video_path	str	✅ Yes	Source video file path, e.g., `"video/3EQLFHRHpag.mp4"`
output_dir	str	✅ Yes	Root output directory. Artifacts are written under `frames/`, `captions/`, and `vdb/` subdirectories
clip_secs	int	❌ No	Reserved parameter; clip length is currently read from `config.vlm["CLIP_SECS"]`
emb_dim	int	❌ No	Embedding dimension, reads from config by default
subtitle_path	str	❌ No	Subtitle file path (.srt), optional

🔁 add_mm() Internal Flow

Frame Extraction: decode_video_to_frames - Decodes video to JPEG frames at configured FPS
Caption Generation: process_video - Uses VLM (e.g., Qwen3-Omni) to generate detailed descriptions for each clip
Vector Database Construction: init_single_video_db - Generates embeddings for semantic retrieval

💡 Smart Caching: If the target file for a stage already exists, that stage is automatically skipped to save computational resources.

Return Value Example

{
    "output_dir": "/abs/path/to/output_dir"
}

Search Multimodal Memory (search_mm)

def search_mm(
    self,
    question: str,
    output_dir: str,
    max_iterations: int = 15,
)

🔎 Parameter Description

Parameter	Type	Required	Description
question	str	✅ Yes	Question string (supports A/B/C/D multiple choice format)
output_dir	str	✅ Yes	The same root output directory used by `add_mm`; it must contain exactly one `captions//captions.json` and one `vdb//*_vdb.json`
max_iterations	int	❌ No	Maximum MMCoreAgent reasoning iterations (default 15)

🛠️ ReAct-Style Reasoning Tools

search_mm internally uses MMCoreAgent, employing a THINK → ACTION → OBSERVATION loop with three specialized tools:

Tool Name	Function
`global_browse_tool`	Get global overview of video events and themes
`clip_search_tool`	Search for specific content using semantic queries
`frame_inspect_tool`	Inspect frame details within a specific time range

Multimodal Example

Run the multimodal demo:

python examples/quickstart_mm.py

On the first run, frames, captions and VDB JSON will be generated under the chosen output_dir. The repository ships a small sample video; generating captions and the video database still requires configured VLM and embedding services unless you already have these artifacts locally.

Complete code example:

import telemem as mem0
from pathlib import Path
from telemem.mm_utils.core import extract_choice_from_msg

# Initialize
memory = mem0.Memory()

# Define paths
repo_root = Path(__file__).resolve().parents[1]
video_path = repo_root / "data" / "samples" / "video" / "3EQLFHRHpag.mp4"
video_name = video_path.stem
output_dir = video_path.parent


# Step 1: Add video to memory (auto-processing)
vdb_json_path = output_dir / "vdb" / video_name / f"{video_name}_vdb.json"
if not vdb_json_path.exists():
    result = memory.add_mm(
        video_path=str(video_path),
        output_dir=str(output_dir),
    )
    print(f"Video processing complete: {result}")
else:
    print(f"VDB already exists: {vdb_json_path}")

# Step 2: Query video content
question = """The problems people encounter in the video are caused by what?
(A) Catastrophic weather.
(B) Global warming.
(C) Financial crisis.
(D) Oil crisis.
"""

messages = memory.search_mm(
    question=question,
    output_dir=str(output_dir),
    max_iterations=15,
)

# Extract final answer
answer = extract_choice_from_msg(messages)
print(f"Answer: ({answer})")

MCP Server

TeleMem ships a Model Context Protocol (MCP) server, so any MCP-compatible client — Claude Desktop, Claude Code, Cursor, custom agents — can use TeleMem as its long-term memory.

pip install telemem

telemem-mcp                                      # stdio (default)
telemem-mcp --transport streamable-http          # Streamable HTTP on :8421
TELEMEM_CONFIG=config/config.yaml telemem-mcp    # custom TeleMem config
uvx telemem                                      # zero-install run (stdio)

Built on the official MCP Python SDK v2, the server implements the current MCP specification (2026-07-28) while remaining compatible with older clients; every tool declares titles, behavior annotations (read-only/destructive hints), and structured output.

The server exposes eight tools: add_memory, search_memories, get_memories, get_memory, update_memory, delete_memory, delete_all_memories, and memory_history. Calls without an explicit scope default to TELEMEM_DEFAULT_USER_ID (telemem-mcp); destructive bulk deletion always requires an explicit scope.

Claude Desktop / Cursor configuration (examples/mcp_config.json):

{
  "mcpServers": {
    "telemem": {
      "command": "telemem-mcp",
      "env": {
        "TELEMEM_CONFIG": "/absolute/path/to/config/config.yaml",
        "OPENAI_API_KEY": "sk-..."
      }
    }
  }
}

Or drive it programmatically over stdio — the quickstart flow as MCP tool calls:

python examples/mcp_client.py

See docs/MCP.md for the full tool reference, transports, and client setup.

Framework Integrations

TeleMem drops into any agent framework with the same two calls — search() before answering, add() after each exchange:

Framework	Example	Install
LangChain	examples/langchain_memory.py	`pip install langchain-core langchain-openai`
LlamaIndex	examples/llamaindex_memory.py	`pip install llama-index-llms-openai`
Claude Desktop / Cursor / any MCP client	MCP Server	`pip install "telemem[mcp]"`

Because TeleMem is mem0 API-compatible, any framework adapter written for Mem0's OSS client also works — point it at telemem.Memory instead.

Data Storage

Text Memory Storage

TeleMem automatically creates a structured storage layout under ./faiss_db/, organized by session and character:

faiss_db/
├── session_001_events.index
├── session_001_events_meta.json 
├── session_001_person_1.index 
├── session_001_person_1_meta.json 
├── session_001_person_2.index 
└── session_001_person_2_meta.json

📄 Metadata Example (_meta.json)

{
 "summary": "Characters discussed the upcoming action plan.",
 "sample_id": "session_001",
 "round_index": 3,
 "timestamp": "2024-01-01T00:00:00Z",
 "user": "Jordan" // Only present in person_*.json
}

All memories include summary, round number, timestamp, and character, facilitating auditing and debugging.

Multimodal Memory Storage

TeleMem generates video-related storage files in the .data/samples/video/ directory:

video/
├── frames/
│   └── <video_name>/
│       └── frames/
│           ├── frame_000001_n0.00.jpg
│           ├── frame_000002_n0.50.jpg
│           └── ...
├── captions/
│   └── <video_name>/
│       ├── captions.json          # Clip descriptions + subject registry
│       └── ckpt/                  # Checkpoint for resume
│           ├── 0_10.json
│           └── 10_20.json
└── vdb/
    └── <video_name>/
        └── <video_name>_vdb.json  # Semantic retrieval vector database

📄 captions.json Structure

{
    "0_10": {
        "caption": "The narrator discusses climate data, showing melting glaciers..."
    },
    "10_20": {
        "caption": "Scene shifts to coastal communities affected by rising sea levels..."
    },
    "subject_registry": {
        "narrator": {
            "name": "narrator",
            "appearance": ["professional attire"],
            "identity": ["climate scientist"],
            "first_seen": "00:00:00"
        }
    }
}

Telemetry & Privacy

TeleMem itself collects no telemetry. The underlying mem0ai library ships anonymized PostHog usage telemetry, which TeleMem disables by default (import telemem sets MEM0_TELEMETRY=False unless you have already set it). To opt back in:

export MEM0_TELEMETRY=true

Development and Contribution

Issues and pull requests are welcome — see the Contributing Guide to get started.
Changes between releases are tracked in the Changelog.
CI runs the offline test suite (uv run pytest tests/ -q) on Python 3.10–3.12 for every PR.
Chinese documentation: README-ZH.md

License

Apache 2.0 License

Acknowledgements

TeleMem’s development has been deeply inspired by open-source communities and cutting-edge research. We extend our sincere gratitude to the following projects and teams:

📑 Citation

If you find TeleMem useful to your research or development, please cite our arXiv paper:

Chunliang Chen, Ming Guan, Xiao Lin, Jiaxu Li, Luxi Lin, Qiyi Wang, Xiangyu Chen, Jixiang Luo, Changzhi Sun, Dell Zhang, Xuelong Li. TeleMem: Building Long-Term and Multimodal Memory for Agentic AI. arXiv:2601.06037, 2026. https://arxiv.org/abs/2601.06037

@article{chen2026telemem,
  title   = {TeleMem: Building Long-Term and Multimodal Memory for Agentic AI},
  author  = {Chen, Chunliang and Guan, Ming and Lin, Xiao and Li, Jiaxu and Lin, Luxi and Wang, Qiyi and Chen, Xiangyu and Luo, Jixiang and Sun, Changzhi and Zhang, Dell and Li, Xuelong},
  journal = {arXiv preprint arXiv:2601.06037},
  year    = {2026},
  url     = {https://arxiv.org/abs/2601.06037}
}

Citation metadata is also available in CITATION.cff (GitHub's "Cite this repository" button).

If you find this project helpful, please give it a ⭐️ — starring also keeps updates in your GitHub feed.

Made with ❤️ by Bloo-Mind AI Ltd and the Ubiquitous AGI team at TeleAI.

mcp-name: io.github.TeleAI-UAGI/telemem

Available Tools

8 tools

add_memoryAdd memoryA

Store a fact, preference, or conversation in TeleMem long-term memory. Provide text for a single statement or messages for conversation turns. Scoped by user_id/agent_id/run_id; defaults to the server's default user.

ParametersJSON Schema

Name	Required	Description
`text`	No	A single statement to remember. Use this or `messages`.
`infer`	No	Extract salient facts with the LLM before storing (TeleMem's default pipeline). Set false to store the raw text as-is.
`run_id`	No	Optional run/session scope.
`user_id`	No	User the memory belongs to.
`agent_id`	No	Optional agent scope.
`messages`	No	Conversation turns as [{"role": "user"\|"assistant", "content": "..."}]. Takes precedence over `text`.
`metadata`	No	Arbitrary metadata to attach to the stored memories.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnly=false and destructive=false, so the agent knows it's a write operation. The description adds context about long-term memory and default user scope. However, it misses a key behavioral trait: the `infer` parameter defaults to true, meaning the LLM may extract or transform the input before storing. This is not disclosed in the description and is important for anticipating that stored content may differ from raw input.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences total for tool description, front-loaded with the core action and then usage details. No filler or redundant information. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core purpose, input format (text vs messages), and scoping defaults. Given the tool has 7 parameters and an output schema, the description is reasonably complete. The main gap is not mentioning the default `infer=true` behavior, but that is documented in the schema, so the description is not severely lacking. Overall it provides sufficient context for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with detailed descriptions for all 7 parameters, so the schema already handles parameter semantics. The description adds minimal new information beyond reinforcing the text/messages choice and scoping, which is already present in the schema. Baseline 3 is appropriate given high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Store a fact, preference, or conversation in TeleMem long-term memory.' The verb 'store' and resource 'TeleMem long-term memory' are specific, and the tool's name matches its function. It distinguishes from sibling tools like get_memory, search_memories, update_memory, and delete_memory by signaling an add operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage guidance: 'Provide `text` for a single statement or `messages` for conversation turns' and notes scoping by user_id/agent_id/run_id with a default. It does not explicitly state when not to use the tool or name alternatives, but for a write operation the context is straightforward. This falls short of 'explicit when/when-not/alternatives' but gives clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_all_memoriesDelete all memories in scopeA

DestructiveIdempotent

Delete every memory in the given scope. Destructive: requires an explicit user_id, agent_id, or run_id — the default user is never assumed.

ParametersJSON Schema

Name	Required	Description
`run_id`	No	Run scope to wipe.
`user_id`	No	User scope to wipe.
`agent_id`	No	Agent scope to wipe.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=true, and the description reinforces this by labeling the operation 'Destructive'. It adds the behavioral nuance that a scope identifier is mandatory and the default user is never assumed, which is valuable safety context beyond the structured hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with all key information front-loaded. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the annotations cover destructive/idempotent behavior and an output schema exists, the description sufficiently covers the bulk deletion action and the main usage caveat. It doesn't specify precedence when multiple scope IDs are passed, but this is a minor omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% description coverage for the three parameters, but the description adds a critical constraint: at least one of user_id, agent_id, or run_id must be explicitly provided despite all being optional in the schema. This clarifies a potential ambiguity in the input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'delete' with resource 'every memory' and clarifies scope. This clearly distinguishes it from the sibling delete_memory, which targets a single memory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear usage condition: an explicit user_id, agent_id, or run_id must be provided, and no default user is assumed. This helps agents avoid accidentally wiping the wrong scope, though it doesn't explicitly name alternative tools for single-record deletion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_memoryDelete memoryA

DestructiveIdempotent

Delete a single memory by memory_id.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes	Exact memory_id to delete.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=true, covering the safety profile. The description adds the specific behavior of deleting a single memory via memory_id, but does not disclose additional side effects (e.g., permanence, reversibility). Since annotations carry much of the burden, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that is front-loaded with the action. Every word earns its place, and it is appropriately sized for a simple delete tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a simple parameter, comprehensive annotations, and an output schema. The description, combined with the schema and annotations, provides complete context for an agent to invoke it correctly. No additional details are necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with the memory_id parameter described as 'Exact memory_id to delete.' The description also references memory_id but adds no extra semantics beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Delete', the resource 'memory', and the scope 'single memory by memory_id'. It differentiates from sibling tools like delete_all_memories and get_memory, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use this tool—when a single memory needs to be deleted by its ID. It does not explicitly mention exclusions or alternatives, but the sibling tools and the phrase 'single memory' imply the distinction from bulk deletion, so the guidance is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_memoriesList memoriesA

Read-only

List stored memories for a user/agent/run with their memory_ids. Use user_id "events" to list shared conversation-event memories.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum memories to return.
`run_id`	No	Optional run/session scope.
`user_id`	No	User scope; defaults to the server's default user.
`agent_id`	No	Optional agent scope.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as read-only, so the safety profile is clear. The description adds valuable behavioral context by specifying the user_id "events" special case, which is not obvious from the schema alone and enhances understanding of the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and resource, with zero fluff. The special-case instruction is concise and useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a read-only list operation with an output schema and clear annotations. The description covers the key nuance (events special value) and is adequately complete for a list tool, though it could mention sorting or pagination behavior that may be relevant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are well documented. The description supplements this by adding meaning to the user_id parameter (the "events" special value) and indicating that output includes memory_ids, which adds semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists stored memories for a user/agent/run, with a specific verb (list) and resource (memories). It distinguishes itself from sibling tools like add_memory, update_memory, and delete_memory, and the special user_id "events" case adds further specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use this tool (listing memories, including the special "events" user_id for shared conversation-event memories), but it does not explicitly mention alternatives or when not to use it (e.g., use search_memories for filtered queries). This is adequate but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_memoryGet memoryA

Read-only

Fetch a single memory by its memory_id.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes	Exact memory_id to fetch.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description is consistent with a read operation but adds no behavioral detail beyond what the schema provides (e.g., no mention of not-found behavior or response format). With annotations covering safety, a neutral 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with the action, zero redundancy. Ideal for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, output schema, and annotations, the description covers what the tool does and what it needs. No missing critical information. Could mention not-found handling, but that's typically covered by the output schema, which exists. Complete for a single-fetch tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description for memory_id. The tool description adds no extra semantics beyond referencing the ID, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Fetch' and identifies the resource 'a single memory' scoped by memory_id, clearly distinguishing it from plural 'get_memories' and 'search_memories'. Meets the criteria for a specific verb+resource+scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies use when you have the exact memory_id and need one memory, but does not explicitly contrast with siblings like search_memories or get_memories. Since this is implied rather than stated, score 3.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_historyMemory historyA

Read-only

Show the change history (ADD/UPDATE/DELETE events) of a memory.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes	Exact memory_id to inspect.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the specific event types (ADD/UPDATE/DELETE), which is helpful context, but it doesn't disclose ordering, pagination, or retention behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single clear sentence, front-loaded with the action and purpose. There is no unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and only one parameter, the description is sufficient for basic usage. It could explicitly mention that it returns a list of events, but the phrasing 'change history' implies a sequence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter memory_id is fully described in the schema, and the tool description doesn't add further syntax or format details. Since schema coverage is 100%, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Show') and resource ('change history of a memory'). It distinguishes itself from siblings like get_memory by focusing on event history rather than current state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as get_memory or search_memories. There is no mention of prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_memoriesSearch memoriesA

Read-only

Semantic search over TeleMem memories. Returns the matching memories as one consolidated text passage (TeleMem fuses related memories). Shared event memories (pseudo-user "events") are searched automatically.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum memories to consider.
`query`	Yes	Natural-language description of what to find.
`run_id`	No	Optional run/session scope.
`user_id`	No	User scope; defaults to the server's default user.
`agent_id`	No	Optional agent scope.
`threshold`	No	Minimum similarity score in [0, 1] for a memory to match.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds meaningful behavior beyond the readOnlyHint annotation by explaining that results are returned as one consolidated passage and that shared event memories are included automatically. No contradiction with annotations; the read-only nature is consistent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences, front-loaded with the main purpose, and each sentence adds a distinct piece of information: purpose, output behavior, and automatic event inclusion. No waste or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and annotations declare read-only, the description covers the core functionality, fusion behavior, and event handling. It does not detail scoping interactions (run_id, user_id, agent_id) but those are in the schema. This is sufficient for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter having a description. The tool description adds little beyond implying 'query' is natural-language via 'Semantic search', which the schema already states. Baseline 3 is appropriate given the schema carries the param documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Semantic search over TeleMem memories' with a specific verb ('search') and resource ('memories'). It also distinguishes from sibling tools like get_memories and memory_history by highlighting semantic search and the fused-passage output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for semantic retrieval, contrasting with other memory tools, though it does not explicitly state when not to use it or name alternatives. The note about shared event memories being searched automatically adds a usage-relevant detail. No exclusions are provided, so it earns a 4.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_memoryUpdate memoryA

DestructiveIdempotent

Overwrite the text of an existing memory by memory_id.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Replacement text for the memory.
`metadata`	No	Optional replacement metadata.
`memory_id`	Yes	Exact memory_id to update.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, covering the safety profile. The description adds 'existing memory' implying preconditions but does not elaborate on side effects or error behavior, so it provides only marginal additional context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that conveys the essential action without redundancy. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is sufficient for a simple update operation, given the rich schema and annotations. It clearly states the core behavior (overwrite text) and the required identifier. It does not mention metadata handling, but the schema covers it, and the output schema is present, so this is complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter (memory_id, text, metadata) is already documented in the schema. The description adds no further nuance beyond what is in the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'overwrite' and clearly identifies the resource ('an existing memory') and the key identifier ('by memory_id'). This distinguishes it from siblings like add_memory (create) and delete_memory (delete).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies the tool is for updating an existing memory's text, contrasting with add/delete/get siblings. However, it does not explicitly state when NOT to use it or name alternatives, though context makes this clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv1.9.0Aug 7, 2026
- Changedadd_memory2 fields changed
  - addedOutput schema / properties / result / additionalProperties
```
Added value: +true
```
  - changedOutput schema / properties / result / type
```
Previous value: -"string"New value: +"object"
```
- Changeddelete_all_memories2 fields changed
  - addedOutput schema / properties / result / additionalProperties
```
Added value: +true
```
  - changedOutput schema / properties / result / type
```
Previous value: -"string"New value: +"object"
```
- Changeddelete_memory2 fields changed
  - addedOutput schema / properties / result / additionalProperties
```
Added value: +true
```
  - changedOutput schema / properties / result / type
```
Previous value: -"string"New value: +"object"
```
- Changedget_memories2 fields changed
  - addedOutput schema / properties / result / additionalProperties
```
Added value: +true
```
  - changedOutput schema / properties / result / type
```
Previous value: -"string"New value: +"object"
```
- Changedget_memory2 fields changed
  - addedOutput schema / properties / result / additionalProperties
```
Added value: +true
```
  - changedOutput schema / properties / result / type
```
Previous value: -"string"New value: +"object"
```
- Changedmemory_history2 fields changed
  - addedOutput schema / properties / result / additionalProperties
```
Added value: +true
```
  - changedOutput schema / properties / result / type
```
Previous value: -"string"New value: +"object"
```
- Changedsearch_memories2 fields changed
  - addedOutput schema / properties / result / additionalProperties
```
Added value: +true
```
  - changedOutput schema / properties / result / type
```
Previous value: -"string"New value: +"object"
```
- Changedupdate_memory2 fields changed
  - addedOutput schema / properties / result / additionalProperties
```
Added value: +true
```
  - changedOutput schema / properties / result / type
```
Previous value: -"string"New value: +"object"
```
8 tool updatesv0.1.0Jun 26, 2026
- First observedadd_memory
- First observeddelete_all_memories
- First observeddelete_memory
- First observedget_memories
- First observedget_memory
- First observedmemory_history
- First observedsearch_memories
- First observedupdate_memory

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a distinct role: add, get, search, list, update, delete, delete-all, and history. No overlaps or ambiguity; the descriptions clarify the differences between get_memory and get_memories.

Naming Consistency4/5

Most tools follow a consistent verb_noun snake_case pattern (add_memory, get_memory, search_memories, update_memory, delete_memory). The exception is memory_history, which is noun_noun, breaking the pattern slightly.

Tool Count5/5

The 8 tools cover the full memory lifecycle without bloat. The count is appropriate for a specialized memory server, neither sparse nor excessive.

Completeness5/5

The surface covers the complete CRUD spectrum (add, get, update, delete), plus listing, semantic search, delete-all for scope cleanup, and history tracking. No obvious gaps for the stated purpose of long-term memory management.

Maintenance

ActivityActive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

AI Context FlowOAuth
network.plurality
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Knowledge & Memory Search
22
goldhold
io.github.jerrysrodz
Persistent memory for AI agents. Search, store, and recall across sessions.
Knowledge & Memory Autonomous Agents RAG Systems
2
Ace Memory BOAuth
io.github.rudedoggg
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Knowledge & Memory RAG Systems Autonomous Agents
4
DeepMem A
io.github.deepmemteam
Mem0-compatible persistent memory for AI agents: write facts once, recall them semantically.
Knowledge & Memory Autonomous Agents
21113

Related MCP Servers

engram-mcp
Knowledge & Memory RAG Systems Autonomous Agents
Cartisien
A
license
A
quality
C
maintenance
Persistent semantic memory for AI agents. SQLite-backed, local-first, zero config. Semantic search via Ollama embeddings with keyword fallback. Tools: remember, recall, history, forget, stats.
Updated 5 months ago (2026-04-20 02:08 UTC)
17
37
1
MIT
Rememb
Knowledge & Memory Developer Tools Autonomous Agents
LuizEduPP
A
license
A
quality
A
maintenance
Persistent memory for AI agents with sectioned entries (project/user/context/etc), semantic search, CLI, and per-project scope. Local JSON, zero config, no server required.
Updated a month ago (2026-08-02 02:58 UTC)
12
4
MIT
CozoDB Memory MCP Server
Knowledge & Memory RAG Systems Search
tobs-code
A
license
Not graded
quality
D
maintenance
Local-first memory for Claude & AI agents with hybrid search, Graph-RAG, and time-travel, runs entirely on your machine.
Updated 3 months ago (2026-06-08 21:52 UTC)
86
1
Apache 2.0
lean-memory
Knowledge & Memory Vector Databases RAG Systems
Wuesteon
A
license
A
quality
A
maintenance
Embedded, local-first agent memory: facts extracted into a per-namespace SQLite file (vec0 + FTS5) with hybrid retrieval and point-in-time (time-travel) queries. ADD-only history over stdio — no server process, no cloud dependency.
Updated a month ago (2026-08-07 01:03 UTC)
7
47
Apache 2.0

Appeared in Searches

Search for 'chmore'

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TeleAI-UAGI/telemem'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Method	Overall(%)
RAG	62.45
Mem0	70.20
MOOM	72.60
A-mem	73.78
Memobase	76.78
TeleMem	86.33

Why TeleMem?

📢 Latest Updates

🔥 Research Highlights

📌 Table of Contents

Project Introduction

Features

Applicable Scenarios

TeleMem vs Mem0: Core Advantages

Experimental Results

Dataset

Experimental Configuration

Quick Start

Installation

Development Environment

Example

Using MiniMax as the LLM Provider

More LLM Providers

Project Structure

Core Functions

Add Memory (add)

🔎 Parameter Description

🔁 Internal Workflow of add()

Search Memory (search)

🔎 Parameter Description

Multimodal Extensions

Add Multimodal Memory (add_mm)

🔎 Parameter Description

🔁 add_mm() Internal Flow

Return Value Example

Search Multimodal Memory (search_mm)

🔎 Parameter Description

🛠️ ReAct-Style Reasoning Tools

Multimodal Example

MCP Server

Framework Integrations

Data Storage

Text Memory Storage

📄 Metadata Example (_meta.json)

Multimodal Memory Storage

📄 captions.json Structure

Telemetry & Privacy

Development and Contribution

License

Acknowledgements

📑 Citation

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

🔁 Internal Workflow of `add()`