Strata Memory MCP Server is a layered memory system for AI agents with SQLite as source of truth, rebuildable vector index, and Markdown projection. You can:
Initialize/configure: set personal or company mode, embedding model/provider, CBT safety, and apply config with hot reload.
Store and promote memories: commit validated facts, preferences, procedures, episodes with metadata; promote session scratchpad to durable storage.
Recall and search: progressive context recall, hybrid vector+FTS5 semantic search with filters, and expand memory details by ID.
Manage and maintain: run health checks, rebuild vector index, view L0-L3 stats/watermarks, export Markdown, and run digest/hygiene for expired, duplicate, or secret data.
Optimize hardware/config: profile system hardware, get embedding recommendations, and apply memory configuration without restart.
Enforce safety and isolation: Quality Kernel blocks passwords, API keys, vague timestamps, and unverified claims; scoped by tenant, user, and session; company mode includes audit logging.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Strata Memory MCP Server memorize key points from today's meeting about Q3 roadmap"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
标志文件（Agensi 用 512 召回点图标、无点 favicon、横版 lockup、wordmark）见 assets/brand/。
大模型只做决策，确定性代码接管一切。
Strata Memory 2.0 是面向 Multi-Agent 的 MCP 记忆中枢：以 SQLite 为唯一真相源（SoT），向量库可一键重建，Markdown 仅为只读投影。写入经过 Quality Kernel / CBT 中间件；召回采用渐进式漏斗，避免上下文爆炸。
层 | 角色 | 可摧毁？ |
SQLite Truth Store | 权威数据（记忆 / 审计 / 轨迹） | 否（备份） |
Chroma + BGE-M3 | 语义索引伴生层 | 是 — |
Markdown projection | 人类可读视图 | 是 — |
L0–L3 分层 + 类型化 TTL（事实/偏好/规程/情节）
三维隔离：tenant_id + user_id + session_id
Scratch → Durable：会话暂存，确认后 promote_session
防御性 MCP 契约：工具描述强制「作用 / 触发 / 禁忌」
Related MCP server: locus
strata-memory-mcp 还没有发布到 PyPI，不要使用 uvx strata-memory-mcp。从本仓库安装（需要 Python 3.11+、uv、git）：
git clone https://github.com/SherryLi-vc/strata-memory.git
cd strata-memory
uv sync
export STRATA_PALACE="${STRATA_PALACE:-$HOME/.strata/palace}"
uv run strata-memory-mcp在你自己的 shell 配置里设置嵌入密钥（STRATA_EMBEDDING_API_KEY 或 STRATA_API_KEY）。不要把 key 贴进对话、写进仓库，或写成带 ... 的脱敏占位符。云端密钥解析顺序：显式参数 → STRATA_EMBEDDING_API_KEY → STRATA_API_KEY → 对应提供方的 SILICONFLOW_API_KEY 或 OPENAI_API_KEY。
嵌入（可配置，默认 SiliconFlow）：
变量 | 作用 | 默认 |
|
|
|
| OpenAI 兼容 | SiliconFlow 为 |
| 模型 id | SiliconFlow 为 |
| 入库向量维度 |
|
SiliconFlow 是默认选项，不是唯一选项。模型 BAAI/bge-m3 返回 1024 维，客户端保留前 STRATA_EMBEDDING_DIMENSION 维。
任意 OpenAI 兼容端点（OpenAI、自建网关、Ollama、llama.cpp、TEI、vLLM）：STRATA_EMBEDDING_PROVIDER=openai_compatible，并设置 STRATA_EMBEDDING_BASE_URL 和 STRATA_EMBEDDING_MODEL。向量长度必须等于 STRATA_EMBEDDING_DIMENSION，否则请改维度后 strata_rebuild_index(confirm=true)。本机回环地址（localhost / 127.0.0.1）不要求 API key。
本机进程内模型： STRATA_EMBEDDING_PROVIDER=local，然后 uv sync --extra local。默认模型 sentence-transformers/all-MiniLM-L6-v2（384 维）。文本不会发到嵌入 API。
网络： 只要提供方不是 local，配置的嵌入端点就会收到记忆正文和召回查询。SQLite 真相源留在本机 STRATA_PALACE（默认 ~/.strata/palace）。换模型或维度后需要重建向量索引。
模板在 skills/strata-memory/references/。只改路径；密钥由用户在本机填写，对话里不要出现 key。
宿主 | 配置位置 | 模板 |
Claude Code | 项目 |
|
Cursor |
|
|
Claude Desktop | Settings → Developer → Edit Config。macOS： |
|
Hermes |
|
|
Hermes 启动器是 examples/strata-wrapper.sh。把脚本拷到 ~/.hermes/scripts/ 并 chmod +x。STRATA_DIR 必须指向你的克隆（环境变量或 ~/.hermes/.env）；脚本不再默认作者本机目录。改完后 /reload-mcp 或重启会话。
examples/cursor-mcp.json 与 examples/hermes-config.yaml 和 skill 模板一致，以 skill 目录里的文件为准。
skills/strata-memory/SKILL.md 是 Claude Code、Cursor、Claude Desktop、Hermes 共用的操作规程。frontmatter name 与目录名都是 strata-memory。
克隆本仓库后：
Claude Code 和 Cursor 从 .claude/skills/strata-memory 加载
Hermes 从 .hermes/skills/strata-memory 加载；在仓库里先执行一次 hermes skills trust
Claude Desktop 不扫描 git 仓库。MCP 用上表接入；需要这段规程时，把 skills/strata-memory 打成 zip（顶层是 strata-memory/SKILL.md）再在应用里上传
给其他项目全局使用时，把该目录复制到 ~/.claude/skills/strata-memory、~/.cursor/skills/strata-memory 或 ~/.hermes/skills/strata-memory。
Agensi 打包同一目录：
cd skills && zip -r ../strata-memory-agensi.zip strata-memory -x '*.DS_Store'Tool | 意图 |
| 初始化 SoT + 配置 |
| 经 Quality Kernel 写入事实 |
| Scratch → Durable |
| 渐进召回（id + 摘要 + 分数） |
| 按 id 二次展开全文 |
| SoT ↔ 索引一致性巡检 |
| 从 SQLite 全量重建向量（ |
| L0–L3 Token 水位线 |
| 导出只读 Markdown 投影 |
| 后台降级 / 归档（TTL + 分数） |
| 过期/重复/secret 卫生扫描与可选修复 |
{
"user_id": "user_001",
"memory_type": "user_preference",
"fact_claim": "User prefers dark mode in VS Code with Monokai Pro theme.",
"confidence_score": 0.92,
"session_id": "sess_2026-08-04"
}{
"user_id": "user_001",
"query": "IDE theme preferences",
"context_depth": "deep",
"limit": 8
}返回仅为卡片列表；需要细节时：
{ "user_id": "user_001", "memory_id": "<id from hits>" }密码 / API Key / Token
纯情绪发泄、无事实
模糊时间（刚才 / 昨天 / today）— 改用 ISO 日期
将「也许 / 可能 / probably」写成 factual_truth
LLM ─commit_memory─► Quality Kernel ─► CBT Middleware ─► SQLite (SoT)
└─► Chroma (rebuildable)
LLM ─recall_context─► Hybrid RRF (vector + FTS5) ─► {id, summary, score}
LLM ─expand_memory_detail(id)─► detail (scope-checked)完整说明：docs/architecture.md · 工具契约：docs/tools.md
0.2.x | 2.0 |
|
|
|
|
|
|
Markdown 直写 | SQLite SoT；Markdown 仅投影 |
批量灌入旧 drawer（不删源文件）：
# 预览
uv run python -m strata_memory.cli migrate --palace ~/.strata/palace
# 写入 SQLite
uv run python -m strata_memory.cli migrate --palace ~/.strata/palace --apply
# 写入 + 重建向量索引（密钥已在环境中，不要写进命令）
uv run strata-memory-migrate --palace ~/.strata/palace --apply --rebuild-vectors完整说明：docs/migration-v02.md · CHANGELOG.md
记忆存在本地 STRATA_PALACE。非 local 提供方会把记忆正文和召回查询发到配置的嵌入端点（默认 SiliconFlow https://api.siliconflow.cn/v1）
密钥只走环境变量（STRATA_EMBEDDING_API_KEY / STRATA_API_KEY），不写入 config.json，也不要贴进对话
写操作无裸 CRUD；破坏性重建必须 confirm=true
跨 user_id / tenant_id 的 expand 硬失败
见 SECURITY.md。
uv sync --extra dev
uv run pytest -v
uv run strata-memory-mcpMIT — 见 LICENSE
[Agent-Driven] Apply chosen memory configuration: persist config, initialize Palace directories, ChromaDB, SQLite. Supports hot reload — no MCP restart needed.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Memory mode. | personal |
| provider | Yes | Embedding provider (e.g. siliconflow, local). | |
| model | Yes | Embedding model name. | |
| api_key | No | API key for cloud providers. | |
| base_url | No | API base URL. | |
| dimension | No | Embedding dimension. | |
| cbt_mode | No | CBT safety mode. | |
| tenant_id | No | Tenant identifier (company mode). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses persistence and initialization of various components, but lacks details on destructiveness (e.g., overwriting existing config), error conditions, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. Key information is front-loaded: agent-driven, apply config, list of actions, hot reload. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 params, no output schema), the description covers the main effect adequately. It lacks details on return values and error handling, but the core purpose is clearly communicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds no extra meaning beyond the schema, merely referencing the overall action of persisting config.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb ('Apply') and specific resource ('memory configuration'), listing concrete actions: persist config, initialize directories, ChromaDB, SQLite. It distinguishes itself from sibling tools like 'strata_init' or 'memorize' by focusing on configuration application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to apply a memory configuration and highlights hot reload support, but it does not explicitly state when to use versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runtime status: initialized, mode, CBT, audit, vector/drawer count, config summary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It specifies the tool returns a summary of runtime status with listed items, which provides moderate transparency. However, it does not mention any side effects, authentication needs, or reliability details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with 'Runtime status', and contains no unnecessary words. Every listed item is meaningful for understanding the output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides a reasonable overview. However, some terms like 'CBT' and 'vector/drawer count' are not explained, which may leave an agent unsure of their meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (coverage 100%), so the description adds value by enumerating the fields included in the output (initialized, mode, CBT, audit, vector/drawer count, config summary). This goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Runtime status' and lists specific components like initialized, mode, CBT, audit, vector/drawer count, config summary. This makes the purpose evident. However, it does not differentiate from the sibling tool 'get_system_profile', which could be a similar status check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when runtime status is needed, but it gives no explicit when-to-use or when-not-to-use guidance. There is no mention of alternatives like 'get_system_profile'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Agent-Driven] Silent hardware profiling. Returns OS, RAM, CPU cores, GPU accelerator. No user input required — call this first during onboarding.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes itself as 'silent' and returns information only. With no annotations, it does not explicitly confirm read-only or non-destructive behavior, but the description is sufficient for a simple query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise; one sentence covers purpose, output, and usage guidance. Every phrase adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description fully informs what the tool returns and its recommended use during onboarding. No further context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds no param info beyond the schema. Baseline 4 applies as schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it performs hardware profiling and lists specific returned fields (OS, RAM, CPU cores, GPU accelerator). Distinguishes from siblings by noting it's for onboarding and requires no user input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use: call this first during onboarding. No ambiguity about its role as an initial profiling step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a conversation/fact into memory with psych-validated metadata (emotional_salience, context_tags, is_negative_schema). Writes Markdown drawer + vector index.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | User/wing identifier. | |
| content | Yes | Raw text content to memorize. | |
| category | No | Memory category (affects decay rate). | event |
| importance | No | Base importance 0.0-1.0. | |
| room | No | Room within wing. | general |
| context_tags | No | Tags for state-dependent retrieval. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool writes to both a Markdown drawer and a vector index, indicating persistence and indexing. However, it does not disclose potential side effects, overwrite behavior, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the primary action and stored metadata. It is dense but not excessively long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain return values or success indicators. Given the tool's complexity (6 parameters), it omits crucial details like error handling and post-conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema, mentioning metadata fields that are not parameters and not explaining existing parameters in more depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a conversation or fact into memory, specifying metadata fields. However, it mentions 'emotional_salience' and 'is_negative_schema' which are not present in the input schema, causing minor confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search or apply_memory_config. Lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Active semantic search across L2 memories with time/category/tag filters and state-dependent boosting.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query. | |
| user_id | Yes | Wing scope. | |
| limit | No | ||
| category | No | Category filter. | |
| from_date | No | ISO start date. | |
| to_date | No | ISO end date. | |
| context_tags | No | State-dependent boost tags. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions filters and boosting but does not detail side effects, performance implications, or the meaning of 'state-dependent boosting'. It is moderately transparent but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with key information. However, it could benefit from structured formatting to improve readability, given the number of concepts packed in.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description adequately covers the purpose but omits details on return format, pagination behavior, and how boosting works. It is minimally complete for a complex search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), so the baseline is 3. The description adds context about 'time/category/tag filters and state-dependent boosting' which aligns with schema parameters, but does not provide additional format or syntax details beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search', the resource 'L2 memories', and specifies features like time/category/tag filters and state-dependent boosting. It is specific and distinguishes from sibling tools like search_embedding_recommendations by focusing on active semantic search across memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 search_embedding_recommendations or memorize. It lacks explicit context about prerequisites, exclusions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Agent-Driven] Return ranked embedding recommendations based on hardware profile. Gets best-fit local/cloud models from MTEB-informed lookup table.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | Optional hardware profile from get_system_profile. If omitted, runs detection automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes internal logic (MTEB-informed table) but does not disclose side effects, auth requirements, or what happens with invalid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with a tag. All content is relevant and concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description omits details about the return format (e.g., structure of ranked recommendations). Adequate for a simple lookup but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter; the description repeats the same info. No additional meaning added beyond schema, meeting baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns ranked embedding recommendations based on hardware profile, using MTEB-informed lookup table. Distinct from sibling tools like get_system_profile (hardware probe) and search (general search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when hardware-specific model recommendations are needed and notes auto-detection if profile omitted, but does not explicitly compare to alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
First-time initialization with dual-mode setup. Choose 'personal' (CBT safety, 48h cooling) or 'company' (multi-tenancy, AuditLog, private embedding).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | API key for embedding provider. | |
| mode | No | Memory mode. personal=CBT safety+emotional tracking. company=multi-tenancy+AuditLog. | personal |
| provider | No | Embedding provider. | siliconflow |
| model | No | Embedding model. | BAAI/bge-m3 |
| base_url | No | API base URL. | https://api.siliconflow.cn/v1 |
| cbt_mode | No | CBT safety mode (personal default=passive, company default=off). | |
| tenant_id | No | Tenant identifier (company mode). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool performs initialization affecting system state, and details behaviors of each mode (CBT safety, 48h cooling, multi-tenancy, AuditLog). However, it does not specify whether the tool is idempotent or if it overrides existing configuration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. First sentence states purpose, second provides mode options and key features. Every word is informative and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description covers the main purpose and mode distinction. Missing details include return value, side effects of repeated calls, and explanation of '48h cooling.' Adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 7 parameters, each well-documented with types, enums, and defaults. The description adds minimal value beyond the schema, only reinforcing the mode choice. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is for first-time initialization with a dual-mode setup. The verb 'initialization' and resource 'dual-mode setup' are specific, and it distinguishes itself from sibling tools like 'apply_memory_config' or 'memorize' by focusing on initial system configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks this as 'First-time initialization,' indicating it should be used at the start. It guides the choice between 'personal' and 'company' modes, but does not specify when not to use it (e.g., after initialization) or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Session wake-up: L0 profile + L1 diary + L2 semantic search with CBT defusion for negative schemas. Returns flat Markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | User/wing identifier. | |
| query | Yes | Current context/question to match against. | |
| context_depth | No | shallow=L0+L1 only, deep=L0+L1+L2. | shallow |
| limit | No | Max L2 results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the return format ('flat Markdown') but does not disclose whether the tool modifies state, requires authentication, has side effects, or triggers any mutations. 'Wake-up' suggests activation but is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus return note) and front-loaded with the action and key components. Every piece of information is essential, though jargon like 'L0 profile' could be clarified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and complex multi-layered functionality (profile, diary, semantic search, CBT defusion), the description is too sparse. It fails to explain how the layers combine, what CBT defusion entails, or the format of the returned Markdown, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter descriptions, so the baseline is 3. The tool description does not add new meaning beyond what the schema already conveys (e.g., the schema already defines 'context_depth' with enum choices). It mentions 'L2 semantic search' but does not elaborate on how parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'wake-up' and lists the resources involved (L0 profile, L1 diary, L2 semantic search) and the return format (flat Markdown). It distinguishes from sibling 'search' by including CBT defusion and multi-layer context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like 'search', 'memorize', or 'search_embedding_recommendations'. The description does not indicate prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0apply_memory_configget_healthget_system_profilememorizesearchsearch_embedding_recommendationsstrata_initwake_upScored across 8 tools
Each tool targets a distinct purpose: initialization, health, profiling, memory writing, searching, recommendations, and session wake-up. No two tools have overlapping functionality that would confuse an agent.
Most tools follow a verb_noun pattern (e.g., apply_memory_config, get_health, search_embedding_recommendations). However, 'strata_init' reverses the order (noun_verb) and 'memorize' is a lone verb without an object, causing slight inconsistency.
With 8 tools, the surface is well-scoped and balanced for a memory management server. Each tool earns its place and covers core workflows without being excessively large or minimal.
The server covers initialization, health, profiling, memorizing, searching, and session wake-up, but lacks update and delete operations for memories. This gap may cause agents to fail when they need to modify or remove stored data.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Persistent memory for AI agents: keyed facts, a wake bundle each session, one memory in every model.
