Una capa de contexto de ingeniería neutral al protocolo para agentes de codificación de IA. memex construye un grafo de conocimiento bitemporal de tu repositorio — módulos, símbolos, decisiones, problemas, evidencia y evolución del código — y expone contexto acotado y consciente de la procedencia a través de Hermes MemoryProvider o MCP.
Un demonio y servidor MCP que convierte commits y cambios de archivos en conocimiento de ingeniería estructurado. Los agentes pueden recibir contexto relevante del repositorio antes de una tarea, con frescura y procedencia preservadas, sin convertir a memex en una fuente de memoria personal o estado de sesión en bruto.
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-marketplaceReinicia tu sesión de 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 .La integración de Hermes v0.9 es de solo lectura. Hermes conserva la memoria personal, el estado de sesión en bruto y el estado de ejecución. memex proporciona contexto de ingeniería del repositorio a través de un ContextPacket acotado; no ingiere state.db de Hermes, transcripciones, prompts ni resultados de herramientas.
Añade el proveedor de memex a la configuración de perfil de Hermes:
memory:
provider: memex
plugins:
memex:
repo_path: /absolute/path/to/repository
prefetch_timeout_seconds: 7
max_items: 8
max_chars: 12000Si Hermes no está instalado, usa el mismo selector de contexto a través de la herramienta MCP get_engineering_context. Ambas rutas comparten el núcleo memex neutral al protocolo y fallan abiertamente cuando la recuperación no está disponible.
Canal | Comando |
Marketplace de Claude Code |
|
npx (sin instalación) |
|
uv |
|
pip |
|
fuente |
|
Para una configuración de equipo compartida (un Neo4j + un memex-server, autenticación activada por defecto, los puertos de Neo4j nunca expuestos al host):
bash docker/bootstrap-team-env.sh
docker compose -f docker/docker-compose.team.yml up -dConsulta docker/TEAM-DEPLOY.md para el flujo completo, capturando la clave de administrador inicial y la trampa down -v que debes evitar.
Related MCP server: memtrace
Propiedad | Valor |
Salida | Un grafo Neo4j poblado continuamente desde tu repositorio |
Almacenamiento | Neo4j mediante Graphiti. Bitemporal: cada arista tiene |
Contexto |
|
Integraciones | Hermes MemoryProvider, recursos/herramientas MCP, Claude Code, Cursor, Codex, Gemini CLI |
Modo de fallo | Fallar abierto; la ejecución del agente continúa sin memex |
Granularidad | Escala de 50 a más de 5000 módulos mediante clústeres Leiden jerárquicos |
Síntesis | Gemini Flash destila commits en nodos |
Confianza | Calculada en tiempo de consulta. Decaimiento de dos regímenes (vida media validada ~139d, no validado obsoleto a los 30d) |
Gobernanza de escritura | ACL por tipo de nodo, confirmación de intención en escrituras de agente, semántica explícita de |
Evidencia del objetivo 10 | 8/8 ejecuciones emparejadas válidas, 0 fallos de tratamiento, 0 regresiones de tratamiento |
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 herramientas: ocho de lectura, cuatro de escritura, dos analíticas.
Herramienta | Cuándo |
| Inicio de sesión. Devuelve un informe a nivel de clúster de menos de 1500 tokens independientemente del tamaño del repositorio |
| Antes de editar una función o clase. Devuelve llamadores, llamados y decisiones vinculadas |
| Últimos N días de decisiones arquitectónicas, opcionalmente con alcance de módulo |
| Bugs activos y deuda técnica, ordenados por severidad |
| Búsqueda híbrida: semántica × palabra clave × recorrido de grafo × fusión RRF |
| Aristas cuya confianza compuesta cayó por debajo del umbral |
| Dado un SHA de commit, cruza referencias del diff con nodos Decision/Problem vinculados y pide a Gemini Pro una explicación fundamentada |
| Dada una ruta de archivo, devuelve una lista clasificada de módulos probablemente afectados según el acoplamiento del grafo (sin llamada LLM) |
Herramienta | Cuándo |
| Después de tomar una decisión técnica. Admite |
| Al descubrir un bug o un fragmento de deuda técnica |
| Cuando se corrige un problema rastreado |
| Cuando un hecho almacenado ya no es verdadero |
La confianza no es un número almacenado que muta. Se calcula en tiempo de consulta a partir de base_confidence, estado de validación, tiempo desde el último refuerzo y recuento de accesos.
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:#000Propiedad | Valor |
Vida media validada | ~139 días |
Umbral de obsolescencia no validado | 30 días (compuesto < 0.3) |
Recencia τ | 90 días (decaimiento exponencial) |
Fórmula compuesta |
|
Umbral de similitud de conflicto | 0.4 (por debajo de esto + validez superpuesta = conflicto) |
Umbral de confirmación de intención | 0.85 (verificación de similitud de escritura MCP) |
memex cluster ejecuta Leiden jerárquico sobre un grafo de aristas híbrido:
Tipo de arista | Peso |
Co-ubicación de directorio | 1.0 |
Importaciones de módulos | 2.0 |
Llamadas de símbolos |
|
Propiedad | Valor |
Algoritmo |
|
Nombrado | TF-IDF top-3 sobre docstrings de módulos + nombres de símbolos, respaldo de directorio padre |
Fijación de ID | Jaccard ≥ 0.5 entre ejecuciones (los nombres de clúster se mantienen estables a través de renombrados) |
Anulaciones de usuario |
|
Presupuesto de contexto |
|
memex rastrea métricas de reducción de tokens y acciones de revisión humana localmente en una base de datos SQLite (~/.config/memex/telemetry.db).
Puedes consultar tus ahorros en cualquier momento usando la CLI:
memex statsO ver el payload JSON en bruto:
memex stats --jsonO apuntar a un alcance de repositorio específico:
memex stats --repo /path/to/repoEsto devuelve una agregación de:
Resúmenes de período: Llamadas, tokens devueltos, tokens ingenuos (tamaño de los archivos solicitados), tokens ahorrados y porcentaje de reducción de tokens en today, last 7 days, last 30 days y lifetime.
Herramientas principales: Las herramientas más valiosas ordenadas por total de tokens ahorrados.
Clientes de agente: Agentes activos (Claude Code, Gemini CLI, Cursor, Codex) y su distribución de ahorro de tokens.
Salud de validación: Total de nodos validados, no validados y corroborados, junto con los días transcurridos desde la última revisión.
Las mismas estadísticas se exponen a través del transporte HTTP MCP:
GET /stats?repo=/path/to/repo
Authorization: Bearer <your-key>La instalación del marketplace anterior lo hace por ti. Conexión manual en .claude/settings.json:
{
"mcpServers": {
"memex": {
"type": "stdio",
"command": "npx",
"args": ["-y", "stifler-memex-mcp", "serve", "--repo", "."]
}
}
}Añade a ~/.cursor/mcp.json:
{
"mcpServers": {
"memex": {
"command": "npx",
"args": ["-y", "stifler-memex-mcp", "serve", "--repo", "."]
}
}
}Añade a ~/.gemini/settings.json:
{
"mcpServers": {
"memex": {
"command": "npx",
"args": ["-y", "stifler-memex-mcp", "serve", "--repo", "."]
}
}
}Añade a ~/.codex/config.toml:
[mcp_servers.memex]
command = "npx"
args = ["-y", "stifler-memex-mcp", "serve", "--repo", "."]memex puede respaldar la herramienta de memoria nativa de Claude: los agentes leen desde una proyección de grafo por sesión más una zona de borrador escribible.
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])# | Principio | La apuesta |
1 | Bitemporal, nunca destructivo | Las aristas se expiran, no se eliminan. |
2 | La confianza se calcula, no se almacena | Mutar un número invita a una deriva silenciosa. Recalcula en cada lectura |
3 | Dos regímenes para la decadencia | Los hechos validados decaen lentamente; los hechos no validados deben ganarse su lugar siendo accedidos |
4 | El humano en el bucle |
|
5 | Gobernanza de escritura | ACL por tipo de nodo. |
6 | Los tokens están presupuestados |
|
7 | Síntesis solo en commits | El watcher agrupa por ventana de debounce. Gemini Flash no está en la ruta crítica de una llamada de herramienta |
8 | Pro para síntesis, Flash para extracción |
|
9 | Consciente de múltiples repos | Un watcher + un servidor MCP pueden gestionar cientos de repos. |
10 | Local-first | Neo4j se ejecuta en tu Docker. Gemini es la única llamada saliente, y solo en commits |
Úsalo cuando | Sáltatelo cuando |
Proyecto de varias semanas o varios meses | Script de un solo uso, prototipo desechable |
Trabajas con múltiples agentes (Claude, Cursor, Codex) y quieres contexto compartido | Solo trabajas con un agente en una tarea |
Las decisiones arquitectónicas se toman con el tiempo y deben recordarse | Todo el proyecto cabe en una única ventana de contexto de 200k tokens |
Quieres consultar "qué decidimos sobre X" desde cualquier sesión | Tu repo ya es lo bastante pequeño como para pegarlo en el prompt |
Varios desarrolladores usan agentes de IA en el mismo código base | Trabajo en solitario donde nunca haces |
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 sandboxesComando | Qué hace |
| Extrae el estado base del grafo, ejecuta la primera pasada de clústeres |
| Daemon que escucha eventos de archivo + git y escribe en Neo4j |
| Ejecuta el servidor MCP (stdio, HTTP, o ambos) |
| TUI que recorre las decisiones de menor confianza para validación humana |
| Diseño de fuerza D3 autocontenido con superposiciones de clústeres |
| Ejecuta Leiden sobre el grafo de aristas híbrido; fija IDs de clúster por Jaccard ≥ 0.5 |
| Respaldar la herramienta |
| Muestra el ahorro de tokens de contexto y estadísticas de telemetría |
MIT. Ver LICENSE.
Hill Patel (@STiFLeR7)
Hill Patel (@STiFLeR7) — arquitecto, mantenedor
Nirvaan Lagishetty (@Nirvaan05) — colaborador principal, mantenedor
Abre un issue o un PR. uv sync --all-extras instala la cadena de herramientas de desarrollo.
Ejecuta uv run pytest -m "not integration" para la suite sin conexión y uv run ruff check . antes de abrir un PR. Los cambios de versión deben actualizar pyproject.toml,
npm/package.json, server.json y la etiqueta de la imagen Docker del equipo juntos.
El registro de la versión v0.9 está en CHANGELOG.md, con la
arquitectura y la evidencia de evaluación en docs/architecture/v0.9/.
Vannevar Bush, 1945: "Considera un dispositivo futuro para uso individual, que es una especie de archivo y biblioteca privada mecanizada. Necesita un nombre, y para acuñar uno al azar, memex servirá."
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
