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-marketplaceClaude 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: 12000Hermes がインストールされていない場合は、MCP の get_engineering_context ツールを通じて同じコンテキストセレクターを使用します。
どちらの経路もプロトコル中立の memex コアを共有し、取得が利用できない場合はフェイルオープンします。
チャネル | コマンド |
Claude Code マーケットプレイス |
|
npx（インストール不要） |
|
uv |
|
pip |
|
ソース |
|
共有チーム構成（Neo4j 1台 + memex-server 1台、認証はデフォルトでオン、Neo4j のポートはホストに公開されない）の場合:
bash docker/bootstrap-team-env.sh
docker compose -f docker/docker-compose.team.yml up -d完全なフロー、初期管理者キーの取得、回避すべき down -v の落とし穴については、docker/TEAM-DEPLOY.md を参照してください。
Related MCP server: memtrace
プロパティ | 値 |
出力 | リポジトリから継続的に生成される Neo4j グラフ |
ストレージ | Graphiti 経由の Neo4j。ビテンポラル — すべてのエッジに |
コンテキスト | 境界があり、ランク付けされ、出典を追跡できる |
統合 | Hermes MemoryProvider、MCP リソース/ツール、Claude Code、Cursor、Codex、Gemini CLI |
障害モード | フェイルオープン。エージェントの実行は memex なしで継続 |
粒度 | 階層的な Leiden クラスタにより 50 から 5000+ モジュールまでスケール |
合成 | Gemini Flash がコミットを |
信頼度 | クエリ時に計算。2 つのレジームの減衰（検証済み半減期 ~139日、未検証は30日で失効） |
書き込みガバナンス | ノードタイプごとの ACL、エージェント書き込み時の意図確認、明示的な |
Goal 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 ツール — 読み取り 8、書き込み 4、分析 2。
ツール | 使用時 |
| セッション開始時。リポジトリサイズに関係なく 1500 トークン未満のクラスタレベル概要を返します |
| 関数やクラスを編集する前。呼び出し元、呼び出し先、関連する決定を返します |
| 直近 N 日間のアーキテクチャ決定。オプションでモジュールスコープ |
| アクティブなバグと技術負債を重大度順に返します |
| ハイブリッド検索: セマンティック × キーワード × グラフトラバーサル × RRF マージ |
| 複合信頼度がしきい値を下回ったエッジ |
| コミット SHA を指定すると、差分を関連する Decision/Problem ノードと相互参照し、Gemini Pro に接地された説明を求めます |
| ファイルパスを指定すると、グラフ結合に基づいて影響を受ける可能性が高いモジュールのランク付きリストを返します（LLM 呼び出しなし） |
ツール | 使用時 |
| 技術的な選択を行った後。 |
| バグや技術負債を発見したとき |
| 追跡中の問題が修正されたとき |
| 保存された事実がもはや真でないとき |
信頼度は変更される保存済みの数値ではありません。クエリ時に 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 |
シンボル呼び出し |
|
プロパティ | 値 |
アルゴリズム | 固定シード付き |
命名 | モジュール docstring + シンボル名の TF-IDF 上位3、親ディレクトリフォールバック |
ID 固定 | 再実行間で Jaccard ≥ 0.5（クラスタ名はリネーム後も安定） |
ユーザー上書き |
|
コンテキスト予算 |
|
memex はトークン削減メトリクスと人間によるレビューアクションをローカルの SQLite データベース（~/.config/memex/telemetry.db）に記録します。
CLI を使用していつでも節約額を照会できます:
memex statsまたは生の JSON ペイロードを表示:
memex stats --jsonまたは特定のリポジトリスコープを対象にする:
memex stats --repo /path/to/repoこれにより、次の集計が返されます:
期間サマリー: 呼び出し数、返されたトークン数、ナイーブトークン数（要求されたファイルのサイズ）、節約されたトークン数、および today、last 7 days、last 30 days、lifetime にわたるトークン削減率。
トップツール: 節約されたトークン総数で並べた最も価値のあるツール。
エージェントクライアント: アクティブなエージェント（Claude Code、Gemini CLI、Cursor、Codex）とそのトークン節約分布。
検証ヘルス: 検証済み、未検証、裏付け済みのノードの総数と、最後のレビューからの経過日数。
同じ統計は 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 | 減衰の2つのレジーム | 検証済みの事実はゆっくり減衰し、未検証の事実はアクセスされることでその居場所を獲得する |
4 | 人間がループに参加 |
|
5 | 書き込みガバナンス | ノードタイプごとのACL。 |
6 | トークンは予算化される |
|
7 | 合成はコミット時のみ | ウォッチャーはデバウンスウィンドウでバッチ処理する。Gemini Flashはツール呼び出しのホットパスにはいない |
8 | 合成にはPro、抽出にはFlash |
|
9 | マルチリポジトリ対応 | 1つのウォッチャー+1つのMCPサーバーで数百のリポジトリを管理可能。 |
10 | ローカルファースト | Neo4jはDocker内で実行。Geminiは唯一のアウトバウンド呼び出しであり、コミット時のみ |
使うべきとき | 使わなくてよいとき |
数週間から数ヶ月にわたるプロジェクト | 一回限りのスクリプト、使い捨てプロトタイプ |
複数のエージェント（Claude、Cursor、Codex）をまたいで作業し、共有コンテキストが必要な場合 | 1つのタスクで常に1つのエージェントとしかペアを組まない場合 |
アーキテクチャ上の決定が時間をかけて行われ、記憶しておく必要がある場合 | プロジェクト全体が単一の200kトークンのコンテキストウィンドウに収まる場合 |
どのセッションからでも「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の |
| コンテキストトークンの節約量とテレメトリ統計を表示 |
MIT。LICENSE を参照。
Hill Patel (@STiFLeR7)
Hill Patel (@STiFLeR7) — アーキテクト、メンテナー
Nirvaan Lagishetty (@Nirvaan05) — リードコントリビューター、メンテナー
issueまたはPRを開いてください。uv sync --all-extras で開発ツールチェーンをインストールします。
オフラインスイートには uv run pytest -m "not integration" を実行し、PRを開く前に uv run ruff check . を実行してください。バージョンアップ時は pyproject.toml、
npm/package.json、server.json、チームのDockerイメージタグをまとめて更新する必要があります。
v0.9リリースの記録は CHANGELOG.md にあり、アーキテクチャと評価のエビデンスは docs/architecture/v0.9/ にあります。
ヴァネヴァー・ブッシュ、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
