一个面向 AI 编码智能体的协议中立工程上下文层。memex 构建你仓库的位时态知识图谱——模块、符号、 决策、问题、证据和代码演化——并通过 Hermes MemoryProvider 或 MCP 暴露有界、 可溯源感知的上下文。
一个守护进程和 MCP 服务器，将提交和文件变更转化为结构化的 工程知识。智能体可以在任务前接收相关的仓库上下文， 同时保留新鲜度和溯源，而不让 memex 成为个人记忆或原始会话状态的来源。
flowchart LR
A[Your repository<br/>files + git] --> B[memex watcher<br/>tree-sitter + Gemini]
B --> C[Neo4j graph<br/>bitemporal facts]
C --> D[memex core<br/>ContextPacket selection]
D --> E[Hermes MemoryProvider<br/>automatic read-only prefetch]
D --> F[MCP fallback<br/>explicit lookup]
E --> G[AI coding agent]
F --> G
style B fill:#cfe8ff,stroke:#0066cc,color:#000
style C fill:#fff4cf,stroke:#cc9900,color:#000
style E fill:#d4f5d4,stroke:#2d8f2d,color:#000/plugin marketplace add STiFLeR7/claude-plugins
/plugin install memex-mcp@stifler-marketplace重启你的 Claude Code 会话。
docker compose -f docker/docker-compose.yml up -d
cat > .env <<EOF
NEO4J_URI=bolt://localhost:7687
NEO4J_USER=neo4j
NEO4J_PASSWORD=memex-local
GEMINI_API_KEY=your-key-here
EOF
npx stifler-memex-mcp init --repo .
npx stifler-memex-mcp watch --repo .
npx stifler-memex-mcp serve --repo .v0.9 的 Hermes 集成是只读的。Hermes 保留个人记忆、原始
会话状态和执行状态。memex 通过有界的 ContextPacket 提供仓库工程
上下文；它不摄取 Hermes 的 state.db、转录、提示或工具结果。
将 memex 提供程序添加到 Hermes 的配置文件配置中：
memory:
provider: memex
plugins:
memex:
repo_path: /absolute/path/to/repository
prefetch_timeout_seconds: 7
max_items: 8
max_chars: 12000如果未安装 Hermes，请通过 MCP 的 get_engineering_context 工具使用相同的上下文选择器。两条路径共享协议中立的 memex 核心，并在检索不可用时故障开放。
渠道 | 命令 |
Claude Code 市场 |
|
npx（无需安装） |
|
uv |
|
pip |
|
源码 |
|
对于共享团队设置（一个 Neo4j + 一个 memex-server，默认启用认证，Neo4j 的端口从不暴露给主机）：
bash docker/bootstrap-team-env.sh
docker compose -f docker/docker-compose.team.yml up -d参见 docker/TEAM-DEPLOY.md 了解完整流程，包括捕获初始管理员密钥，以及需要避免的 down -v 陷阱。
Related MCP server: memtrace
属性 | 值 |
输出 | 持续从你的仓库填充的 Neo4j 图 |
存储 | 通过 Graphiti 使用 Neo4j。位时态——每条边都有 |
上下文 | 有界、排序、可溯源感知的 |
集成 | Hermes MemoryProvider、MCP 资源/工具、Claude Code、Cursor、Codex、Gemini CLI |
故障模式 | 故障开放；智能体执行在无 memex 的情况下继续 |
粒度 | 通过分层 Leiden 聚类，从 50 扩展到 5000+ 个模块 |
综合 | Gemini Flash 将提交提炼为 |
置信度 | 在查询时计算。双机制衰减（已验证半衰期 ~139 天，未验证在 30 天时过期） |
写入治理 | 按节点类型的 ACL、智能体写入时的意图确认、显式的 |
目标 10 证据 | 8/8 有效配对运行，0 次处理失败，0 次处理回归 |
flowchart TD
Init[memex init<br/>extract baseline] --> Watch[memex watch<br/>daemon + git hooks]
Watch -->|commit| Extract[tree-sitter extract<br/>symbols, imports, lockfile]
Extract --> Synth[Gemini Flash<br/>diff → Decision nodes]
Synth --> Write[Graphiti add_episode<br/>+ post-hoc bitemporal SET]
Write --> Decay[Scheduler<br/>nightly confidence decay]
Decay -->|stale edges| Archive[expired_at = now]
Serve[memex serve<br/>MCP stdio/HTTP] -.->|reads| Write
Agent[AI agent] -->|14 MCP tools| Serve
Serve -->|record_decision / record_problem| Write
Cluster[memex cluster<br/>Leiden over hybrid edges] -.->|every N commits| Write
style Init fill:#e8f4ff,color:#000
style Watch fill:#fff4cf,color:#000
style Synth fill:#ffe0cc,color:#000
style Serve fill:#d4f5d4,color:#00014 个工具——八个读取，四个写入，两个分析。
工具 | 时机 |
| 会话开始。无论仓库大小，返回 1500 个 token 以下的集群级简报 |
| 编辑函数或类之前。返回调用者、被调用者、关联的决策 |
| 最近 N 天的架构决策，可选模块范围 |
| 活跃的 bug 和技术债务，按严重程度排序 |
| 混合搜索：语义 × 关键词 × 图遍历 × RRF 合并 |
| 复合置信度低于阈值的边 |
| 给定提交 SHA，将差异与关联的 Decision/Problem 节点交叉引用，并请求 Gemini Pro 提供有根据的解释 |
| 给定文件路径，返回基于图耦合可能受影响的模块排序列表（无 LLM 调用） |
工具 | 时机 |
| 做出技术选择后。支持 |
| 发现 bug 或技术债务时 |
| 跟踪的问题修复时 |
| 存储的事实不再为真时 |
置信度不是一个会变化的存储数字。它在查询时根据 base_confidence、验证状态、自上次强化以来的时间以及访问次数计算。
flowchart LR
Edge[Edge created<br/>base_confidence] --> Q{Validated by<br/>a human?}
Q -->|yes| Slow[Slow regime<br/>half-life ~139d]
Q -->|no| Fast[Fast regime<br/>stale at exactly 30d]
Slow --> Score[Composite score<br/>conf × recency × rehearsal]
Fast --> Score
Score -->|below floor| Stale[get_stale_context surfaces it]
Score -->|access| Bump[last_reinforced_at updated]
Bump --> Score
style Slow fill:#d4f5d4,color:#000
style Fast fill:#ffd4d4,color:#000属性 | 值 |
已验证半衰期 | ~139 天 |
未验证过期阈值 | 30 天（复合 < 0.3） |
新近度 τ | 90 天（指数衰减） |
复合公式 |
|
冲突相似度阈值 | 0.4（低于此值 + 重叠有效性 = 冲突） |
意图确认阈值 | 0.85（MCP 写入相似度检查） |
memex cluster 在混合边图上运行分层 Leiden：
边类型 | 权重 |
目录共置 | 1.0 |
模块导入 | 2.0 |
符号调用 |
|
属性 | 值 |
算法 |
|
命名 | 模块文档字符串 + 符号名称的 TF-IDF 前 3 项，父目录回退 |
ID 固定 | 跨重跑的 Jaccard ≥ 0.5（聚类名称在重命名时保持稳定） |
用户覆盖 |
|
上下文预算 |
|
memex 在本地 SQLite 数据库（~/.config/memex/telemetry.db）中跟踪 token 减少指标和人工审查操作。
你可以随时使用 CLI 查询你的节省：
memex stats或查看原始 JSON 负载：
memex stats --json或针对特定仓库范围：
memex stats --repo /path/to/repo这将返回一个聚合：
周期摘要：调用次数、返回的 token 数、原始 token 数（请求文件的大小）、节省的 token 数以及跨 today、last 7 days、last 30 days 和 lifetime 的 token 减少百分比。
顶级工具：按节省的总 token 数排序的最有价值的工具。
智能体客户端：活跃的智能体（Claude Code、Gemini CLI、Cursor、Codex）及其 token 节省分布。
验证健康：已验证、未验证和已证实的节点总数，以及自上次审查以来的经过天数。
相同的统计信息通过 HTTP MCP 传输暴露：
GET /stats?repo=/path/to/repo
Authorization: Bearer <your-key>上面的市场安装会为你完成此操作。在 .claude/settings.json 中手动配置：
{
"mcpServers": {
"memex": {
"type": "stdio",
"command": "npx",
"args": ["-y", "stifler-memex-mcp", "serve", "--repo", "."]
}
}
}添加到 ~/.cursor/mcp.json：
{
"mcpServers": {
"memex": {
"command": "npx",
"args": ["-y", "stifler-memex-mcp", "serve", "--repo", "."]
}
}
}添加到 ~/.gemini/settings.json：
{
"mcpServers": {
"memex": {
"command": "npx",
"args": ["-y", "stifler-memex-mcp", "serve", "--repo", "."]
}
}
}添加到 ~/.codex/config.toml：
[mcp_servers.memex]
command = "npx"
args = ["-y", "stifler-memex-mcp", "serve", "--repo", "."]memex 可以支持 Claude 的原生记忆工具——智能体从每会话图投影加上可写暂存区读取。
memex memory-tool serve --repo . # in-process
memex memory-tool serve --repo . --transport http # FastAPI on :7464from memex.memory_tool import MemexAsyncMemoryTool
memory_tool = MemexAsyncMemoryTool(repo_root=".")
client.beta.messages.run_tools(..., tools=[memory_tool])# | 原则 | 赌注 |
1 | 双时态，绝不破坏 | 边是过期而非删除。 |
2 | 置信度是计算出来的，而非存储的 | 修改数字会引发静默漂移。每次读取时重新计算 |
3 | 两种衰减机制 | 已验证的事实缓慢衰减；未验证的事实必须通过被访问来赢得自己的位置 |
4 | 人在回路中 |
|
5 | 写入治理 | 按节点类型设置 ACL。 |
6 | Token 有预算 | 通过 Leiden 聚类， |
7 | 仅在提交时进行综合 | watcher 按防抖窗口批量处理。Gemini Flash 不在工具调用的热路径上 |
8 | 综合用 Pro，提取用 Flash |
|
9 | 多仓库感知 | 一个 watcher + 一个 MCP 服务器即可管理数百个仓库。 |
10 | 本地优先 | Neo4j 运行在你的 Docker 中。Gemini 是唯一的外呼调用，且仅在提交时发生 |
使用场景 | 跳过场景 |
数周或数月的中长期项目 | 一次性脚本、一次性原型 |
你在多个代理（Claude、Cursor、Codex）之间协作，需要共享上下文 | 你只在一个任务上与一个代理配对 |
架构决策随时间逐步做出，需要被记住 | 整个项目能装进单个 200k-token 上下文窗口 |
你想在任何会话中查询"我们关于 X 做了什么决定" | 你的仓库已经小到可以直接粘贴进提示词 |
多个开发者在同一代码库上使用 AI 代理 | 单人工作，从不 |
memex/
├── memex/
│ ├── extractor/ tree-sitter + lockfile parsers
│ ├── graph/ Neo4j writes, confidence, archive, cluster engine
│ ├── synthesizer/ Gemini Flash → Decision nodes
│ ├── mcp_server/ 14 MCP tools (read + write + analytic)
│ ├── memory_tool/ Anthropic memory_20250818 adapter
│ ├── watcher/ daemon + git hooks
│ └── cli.py init / watch / serve / review / graph / cluster
├── tests/ unit, integration, and objective evaluation suites
├── docker/ Neo4j compose
├── npm/ npx wrapper (publishes as stifler-memex-mcp)
└── Dockerfile introspection-only image for MCP directory sandboxes命令 | 作用 |
| 提取基线图状态，运行第一轮聚类 |
| 守护进程，监听文件与 git 事件并写入 Neo4j |
| 运行 MCP 服务器（stdio、HTTP 或两者兼有） |
| TUI，遍历置信度最低的决策以供人工验证 |
| 自包含的 D3 力导向布局，带聚类叠加层 |
| 在混合边图上运行 Leiden；按 Jaccard ≥ 0.5 固定聚类 ID |
| 用图投影支撑 Anthropic 的 |
| 显示上下文 token 节省量与遥测统计 |
MIT。参见 LICENSE。
Hill Patel（@STiFLeR7）
Hill Patel（@STiFLeR7）— 架构师、维护者
Nirvaan Lagishetty（@Nirvaan05）— 主要贡献者、维护者
请提交 issue 或 PR。uv sync --all-extras 安装开发工具链。
在提交 PR 前运行 uv run pytest -m "not integration" 进行离线测试套件，并运行 uv run ruff check .。版本号升级必须同时更新 pyproject.toml、
npm/package.json、server.json 以及团队 Docker 镜像标签。
v0.9 发布记录见 CHANGELOG.md，架构与评估证据见
docs/architecture/v0.9/。
Vannevar Bush，1945 年："设想一种供个人使用的未来设备，它是一种机械化的私人文件与图书馆。它需要一个名字，随意造一个，memex 就行。"
Cross-references a git commit's diff with linked Decision/Problem nodes and returns a grounded Markdown explanation synthesised by Gemini Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository. | |
| commit_sha | Yes | The git commit SHA to explain (short or full). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the explanation is synthesized by Gemini Pro, indicating AI generation. It also implies a read-only operation, though not explicitly stated. No contradictions with annotations (none provided).
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, well-constructed sentence that conveys all essential information without wasted words. It is front-loaded with the core action and outcome.
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 simple two-parameter schema (both described) and no output schema, the description adequately covers what the tool does and returns. It does not mention error cases or prerequisites, but for a tool of this complexity, it is largely 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 coverage is 100%, so the schema already describes both parameters. The description adds 'cross-references a git commit's diff' which hints at the commit_sha usage, but it does not significantly augment the schema descriptions. 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 the verb ('cross-references', 'returns'), the resource ('a git commit's diff with linked Decision/Problem nodes'), and the output ('grounded Markdown explanation'). This distinguishes it from sibling tools like get_open_problems or get_recent_decisions.
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 to explain a git commit by linking to decisions/problems, but it does not explicitly state when to use it versus alternatives or when not to use it. The sibling tools provide some differentiation, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a ranked, token-capped briefing of the most important context for this codebase. Use this at the START of a session to efficiently prime your understanding without overloading your context window. The briefing includes cluster summaries, recent high-confidence decisions, and active problems.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Repository path (uses default if omitted) | |
| scope | No | Optional module/directory scope to focus the briefing | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). | |
| max_tokens | No | Maximum token budget for the briefing (default: 2000) |
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 briefing includes 'cluster summaries, recent high-confidence decisions, and active problems', but omits details on ranking logic, token-capping behavior (e.g., truncation), or any side effects. The description provides some behavior but not comprehensive transparency.
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 three sentences, efficiently front-loaded with the main action and purpose. No superfluous words; every sentence provides essential information (what, when, what includes). Excellent conciseness and structure.
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 4 parameters and no output schema, the description covers primary use and content but lacks details on return format, edge cases (e.g., empty context), and token-capping behavior. It is moderately complete but leaves gaps that an agent might need to infer.
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%, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it clarifies the project parameter as an alternative to repo, but does not elaborate on format or usage details for scope or max_tokens. The description adds marginal value, thus score 3.
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 a ranked, token-capped briefing of important context, specifying the verb and resource. It distinguishes from siblings by recommending use at session start and listing included content types (cluster summaries, decisions, problems), differentiating from tools like get_recent_decisions or get_open_problems.
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 says 'Use this at the START of a session to efficiently prime your understanding', providing clear usage context. It does not explicitly state when not to use or mention alternatives, but the sibling tools imply specialization, so the guidance is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a bounded, provenance-aware engineering ContextPacket projection using the shared memex selector.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Repository path to scope results. | |
| query | Yes | The engineering task or question to contextualize. | |
| top_k | No | Maximum number of context items (1-8, default: 8). | |
| project | No | Project ID to scope results. | |
| task_id | No | Optional engineering task identifier for traceability. | |
| session_id | No | Optional execution session identifier for traceability. | |
| allow_historical | No | Include explicitly superseded historical knowledge. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'bounded' and 'provenance-aware,' but does not explain what bounds are applied (e.g., share of results, time window), what provenance means for the caller, or any side effects (though likely read-only). It also fails to mention how historical data is handled despite an allow_historical parameter.
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, which is concise, but it is front-loaded with jargon ('bounded', 'provenance-aware', 'shared memex selector') that obscures rather than clarifies. The sentence is short but not efficiently structured for an agent that needs to understand what the tool does and when to use it.
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 7 parameters, no output schema, and no annotations, the description is severely under-specified. It does not explain what the ContextPacket contains, how to interpret the results, what 'bounded' means in practice, or how parameters like top_k and allow_historical affect outcomes. An agent cannot reliably call this tool correctly based on the provided definition alone.
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 seven parameters have schema descriptions providing baseline documentation, so the description does not need to explain them. However, it adds no extra guidance beyond the schema—for example, it does not clarify how 'query' should be phrased or how scope parameters (repo, project) interact. The description meets the minimum bar but does not enhance parameter understanding.
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 identifies a specific resource ('engineering ContextPacket projection') and a clear action ('Returns'), but it relies on opaque internal jargon like 'shared memex selector' and does not differentiate this tool from siblings such as search_context or get_project_context. An agent can infer it returns engineering context, but not how it differs from those alternatives.
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 is given for when to use this tool versus its many siblings. It does not mention alternatives, exclusions, or any decision criteria such as 'use search_context when...' or 'use this for broader engineering context.' The agent is left to guess which of the 13 related tools to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns currently open technical problems and TODOs sorted by severity as a Markdown string.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository to scope results. | |
| module | No | Optional relative path to filter problems by module. | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses read-only behavior and sorting but does not mention permissions, rate limits, or response format details beyond Markdown string.
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 front-loads purpose and is free of waste. However, it could benefit from slightly more structure for clarity.
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 simple tool with no required parameters and no output schema, the description covers the basic function but leaves open questions about result limits, pagination, and exact output structure.
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%, so the description adds no additional meaning beyond the schema. Baseline of 3 is appropriate as per guidelines.
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 open technical problems and TODOs as a Markdown string, sorted by severity. It uses a specific verb ('returns') and resource, and distinguishes from sibling tools like record_problem or resolve_problem.
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 for retrieving problems but does not explicitly contrast with sibling tools like search_context or get_context_briefing. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a compressed briefing of the project as a Markdown string: active modules, recent decisions, and open problems.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository to scope results. | |
| scope | No | Optional relative path to filter the briefing (e.g. 'src/auth'). | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It implies a read-only operation and describes the output format, but does not explicitly state read-only behavior, permissions, or side effects. Adequate but minimal.
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 conveys the tool's purpose and output. 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 the three optional parameters and lack of output schema, the description adequately covers the returned components (active modules, recent decisions, open problems). It provides sufficient context for an agent to understand the tool's utility.
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%, so the schema already documents all three parameters. The description adds no additional meaning beyond the schema's own descriptions. Baseline score of 3 applies.
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 it returns a compressed briefing of the project as a Markdown string, listing three components. However, it does not differentiate itself from the sibling tool 'get_context_briefing', which may have similar functionality.
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 is provided on when to use this tool versus alternatives. Sibling tools like get_open_problems and get_recent_decisions exist for individual components, but the description does not hint at any 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.
Returns architectural and technical decisions from the past N days as a Markdown string.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days to look back (default: 30). | |
| repo | No | Optional absolute path to the repository to scope results. | |
| module | No | Optional relative path to filter decisions by affected module. | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the return format but omits critical details such as whether the tool requires a initialized repository, how it handles missing data, or performance characteristics. The description implies a read operation but does not explicitly confirm non-destructiveness or auth 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 is front-loaded with the core purpose. It has no unnecessary words and conveys exactly what the tool does.
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 4 optional parameters and no output schema, the description is somewhat minimal. While the parameter schema provides details, the description could elaborate on usage, such as the relationship between repo and project parameters or return formatting. It is adequate but has gaps for an agent to use effectively without schema inspection.
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%, so the schema already explains each parameter (days, repo, module, project). The description adds no additional meaning beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 architectural and technical decisions from the past N days as a Markdown string. It uses a specific verb (returns) and resource (decisions), and its purpose is distinct from siblings like record_decision which is for recording, not retrieving.
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 is provided on when to use this tool versus alternatives. The description does not specify prerequisites, use cases, or when not to use it. There is no mention of siblings or contrasting tools, leaving the agent to infer usage from purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns relationships that have decayed in confidence and may be outdated as a Markdown string.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository to scope results. | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). | |
| threshold | No | Confidence threshold below which edges are considered stale (0.0-1.0, default: 0.5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the return format but does not explain whether the operation is read-only, whether it blocks, what happens with no stale relationships, or any side effects. This is insufficient for a tool that returns dynamic confidence-based data.
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 the core purpose. However, it is arguably too terse - a second sentence about key usage details would improve without harming conciseness.
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 3 optional parameters, no output schema, and no annotations, the description is insufficiently complete. It does not clarify the Markdown output structure, pagination, or what 'stale' means operationally. Compared to siblings like 'get_context_briefing', it lacks necessary detail for correct invocation.
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 already documents all 3 parameters with descriptions (100% coverage). The tool description adds no additional meaning or context for the parameters. Baseline 3 is appropriate since the schema covers the burden, but the description could clarify how 'repo' and 'project' interact or the interpretation of 'threshold'.
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 action ('returns'), the resource ('relationships that have decayed in confidence'), and the output format ('as a Markdown string'). It clearly distinguishes from siblings like 'get_context_briefing' that provide general context. However, 'may be outdated' is ambiguous - it could be more precise about the confidence decay mechanism.
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 is provided on when to use this tool versus alternatives like 'search_context' or 'invalidate_edge'. The description does not mention prerequisites, scenarios, or when not to use it. For a tool with many siblings, this omission leaves the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns detailed information about a specific function or class as a Markdown string including callers/callees.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | Optional relative path to disambiguate symbols with the same name. | |
| repo | No | Optional absolute path to the repository to scope results. | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). | |
| symbol_name | Yes | The name of the function or class to look up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the output format (Markdown with callers/callees). It does not disclose whether it is read-only, required permissions, side effects, or performance considerations.
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 clear sentence with no redundant words. It is front-loaded with the purpose and conveys the key information efficiently.
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 schema fully describes parameters and the tool has no output schema, the description is reasonably complete. It could benefit from mentioning authentication or scope, but it adequately covers the main purpose and output format.
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% coverage with clear descriptions for all four parameters. The description does not add additional meaning beyond the schema, but it connects to the output by mentioning callers/callees. 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 the tool returns detailed information about a specific function or class, explicitly mentioning it includes callers/callees and output as Markdown. It distinguishes from siblings like 'search_context' which is broader in scope.
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 does not provide guidance on when to use this tool versus alternatives like 'search_context' or 'get_project_context'. There is no mention of 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.
Explicitly invalidates a graph edge when it is discovered to be stale or incorrect. Returns a status string.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository. | |
| reason | Yes | The reason for invalidating this relationship. | |
| edge_id | Yes | The unique ID of the edge to invalidate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states it invalidates an edge and returns a status, but it does not explain what 'invalidate' entails (e.g., effects on queries, reversibility, side effects). The description is too brief for full transparency.
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 concise with two sentences, no wasted words. However, it could be slightly more informative about behavior without being verbose.
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 simple mutation tool with 3 parameters and no output schema, the description covers the basic purpose and return type. However, it lacks details on when to use this vs. deletion, prerequisites, or implications, making it minimally adequate.
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 parameters are described in the schema (100% coverage), so the description does not add new meaning. The baseline score of 3 applies, as no extra parameter details are provided beyond the 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's action (invalidates a graph edge), the condition (stale or incorrect), and the return type (status string). It distinguishes well from sibling tools that focus on reading, explaining, or recording.
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 specifies when to use the tool ('when discovered to be stale or incorrect'), providing clear context. While it does not explicitly name alternatives, the condition implies a specific scenario that differs from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a ranked Markdown list of modules likely affected by changes to a file, based on graph coupling (calls + imports + decision links). No LLM call.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository. | |
| file_path | Yes | Relative path of the file whose change-impact you want predicted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the output format, algorithm basis (calls + imports + decision links), and lack of LLM call, but lacks details on prerequisites, edge cases, or performance implications.
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 sentence is clear and front-loaded with key information. Could be slightly more concise but does not waste 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?
No output schema, but description explains output format and algorithm. Missing details on what 'modules' means and ranking criteria, but sufficient for a simple tool. Reasonably complete given context.
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 has 100% description coverage for both parameters. Description adds no extra meaning beyond reinforcing that 'file_path' is the file to analyze and 'repo' is optional. 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 the tool returns a ranked Markdown list of affected modules based on graph coupling. It specifies the verb 'returns', the resource 'modules', and the mechanism, distinguishing it from siblings like 'explain_change' or 'get_symbol_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?
The description mentions 'No LLM call' implying fast deterministic output, but does not explicitly indicate when to use this tool over alternatives like 'explain_change' or 'get_symbol_context'. No usage scenarios or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a Decision node in the graph. Call this when making or discovering architectural choices. Returns a status string. Phase 9: pass corroborates= to reinforce, supersedes= to replace, or force=true to bypass duplicate detection.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository. | |
| text | Yes | The decision text (min 10 chars). Not required when only corroborating. | |
| force | No | Phase 9: skip intent-confirmation similarity check and always write a sibling decision. | |
| module | No | Optional relative path to the affected module. | |
| symbol | No | Optional name of the affected symbol. | |
| rationale | No | Optional reasoning behind the decision. | |
| supersedes | No | Phase 9: id of an existing Decision this one replaces. A new node is created with supersedes=<id> and the old node's outgoing edges are expired. | |
| corroborates | No | Phase 9: id of an existing Decision to reinforce. No new node is created; the existing node's last_reinforced_at is bumped. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses creation behavior, return type (status string), and special Phase 9 behaviors (bumping, expiring edges, bypassing duplicate detection). No annotations provided, so description carries burden adequately.
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?
Three concise, well-structured sentences: purpose, context, and Phase 9 details. 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?
Covers key behaviors and Phase 9 use cases for 8 parameters without output schema. Could mention prerequisites or status values, but adequate for decision recording.
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?
Adds meaning beyond schema by explaining interplay of corroborates, supersedes, and force in Phase 9. However, description contradicts schema by stating text is not required when corroborating, while schema marks text as required.
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 creates a Decision node in the graph and is for architectural choices. Distinguishes from sibling tools like record_problem by focusing on decisions.
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?
Provides explicit when-to-use ('when making or discovering architectural choices') and details Phase 9 options (corroborates, supersedes, force). Lacks explicit alternatives but context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a Problem node in the graph. Call this when discovering bugs or technical debt. Returns a status string.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository. | |
| text | Yes | The problem description (min 10 chars). | |
| module | No | Optional relative path to the affected module. | |
| severity | No | Problem severity: critical, high, medium, low (default: medium). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions creation and return string but lacks detail on side effects, authentication needs, or rate limits. Adequate for a simple creation 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?
Two sentences front-load purpose and usage; no redundant words. Highly efficient.
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?
Covers core purpose and return type, but lacks details about output format, duplicate handling, or validation constraints. Adequate but not comprehensive.
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% with each parameter documented. Description adds minimal extra value beyond schema, but 'Returns a status string' is useful. 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?
Explicitly states the action 'Creates a Problem node in the graph' and when to call it ('discovering bugs or technical debt'). Clearly distinguishes from siblings like resolve_problem.
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?
Provides clear guidance on when to use ('when discovering bugs or technical debt'), but does not explicitly mention when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marks a Problem as closed and records the resolution. Returns a status string.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository. | |
| problem_id | Yes | The unique ID or name of the problem node. | |
| resolution_text | Yes | Explanation of how the problem was resolved (min 10 chars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description only notes it is a state-changing operation returning a status string. Lacks details on side effects, permissions, idempotency, or reversibility.
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 12 words, no redundancy or filler.
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?
Lacks usage context, behavioral details, and specific return value information. For a tool with 3 params and no annotations, more context is needed for effective use.
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 already describes all parameters, but description adds context that problem_id and resolution_text are for closing and recording resolution, offering limited added value over 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?
Description clearly states the action ('marks as closed and records resolution') on a specific resource ('Problem'), distinguishing from siblings like record_problem and get_open_problems.
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 provided on when to use this tool vs alternatives (e.g., record_problem for creating new problems, get_open_problems for listing). Agent must infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic + keyword + graph traversal search across all node types. Use for broad discovery. Returns a Markdown string.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Optional absolute path to the repository to scope results. | |
| query | Yes | The search query. | |
| top_k | No | Maximum number of results (1-20, default: 8). | |
| project | No | Optional project_id to scope results (alternative or complement to 'repo' — see `memex init --project-id`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool performs multiple search methods and returns a Markdown string. It could add details about rate limits, performance characteristics, or side effects, but the provided information is adequate for understanding 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first clearly defines the tool's action and scope, second gives a usage hint and output format. No unnecessary words, perfectly front-loaded with key information.
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 annotations, no output schema, and 4 parameters with full schema coverage, the description adequately covers the tool's purpose, search methods, and return type. It could mention result format structure or limitations, but it is largely complete for a 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds little beyond the schema, only mentioning the output type. Baseline 3 is appropriate as the description does not detract but does not enhance parameter understanding.
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 'semantic + keyword + graph traversal search across all node types', which is a specific verb+resource combo and distinguishes from sibling tools like 'get_symbol_context' or 'get_context_briefing' that focus on narrower scopes.
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?
It says 'Use for broad discovery', providing clear context for when to use this tool over alternatives. However, it does not explicitly state when not to use it or name specific alternatives, which would be helpful for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are largely distinct: each getter targets a specific aspect (decisions, problems, project, symbol, stale context, engineering context), and write/action tools are clearly separate (record, resolve, invalidate, explain, predict). Minor overlap exists between get_project_context and get_context_briefing, both providing project summaries, but they differ in focus and usage timing.
All tool names follow a consistent verb_noun pattern in snake_case (get_recent_decisions, record_decision, resolve_problem, invalidate_edge, explain_change, predict_impact). The verb clearly indicates the action, and nouns describe the target resource, making the naming predictable and uniform.
14 tools is well within the expected range for a knowledge/context management server. Each tool addresses a distinct operation (retrieval, recording, mutations, analysis) without redundancy, and the count feels appropriate for the scope of the domain.
The surface covers key lifecycle operations: decision recording (with supersede/force), problem creation and resolution, edge invalidation, context retrieval via multiple projections, search, and analytical tools. Minor gaps include no explicit update tool for decisions or problems (though supersede covers decision updates), but agents can work around with existing tools.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Your versioned memory across every AI tool — context maps, personal memory, and tasks over MCP.
Graph-native persistent memory for AI agents — 33 MCP tools, zero-LLM writes.
shared AI-context layer for teams — persistent memory your agents search and update over MCP
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/STiFLeR7/memex'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
