Continuidad de sesión sin re-explicación para Claude Code — Captura automática de contexto + búsqueda semántica + pipeline automático de error→solución
Cada nueva sesión de Claude Code:
"This is a Next.js 15 project with App Router..."
"We decided to use Server Actions because..."
"Last time we were working on the auth system..."
"The build command is pnpm build..."5 minutos configurando el contexto. Cada. Vez.
Related MCP server: Melchizedek
Totalmente automática. Los Claude Hooks se encargan de todo sin llamadas manuales:
# Session start → Auto-loads relevant context + recent session history
# When asking → Auto-injects relevant memories/solutions
# During conversation → Tracks active files + auto-injects error solutions
# On compact → Structured handover context for continuity
# On exit → Extracts commits, decisions, error-fix pairs from transcript← Auto-output on session start:
# my-app - Session Resumed
📍 **State**: Implementing signup form
## Recent Sessions
### 2026-02-28
**Work**: Completed OAuth integration with Google provider
**Commits**: feat: add OAuth callback handler; fix: redirect URI config
**Decisions**: Use Server Actions instead of API routes
### 2026-02-27
**Work**: Set up authentication foundation
**Next**: Implement signup form validation
## Directives
- 🔴 Always use Zod for form validation
- 📎 Prefer Server Components by default
## Key Memories
- 🎯 Decided on App Router, using Server Actions
- ⚠️ OAuth redirect_uri mismatch → check env fileCero trabajo manual. El contexto te sigue.
npm install claude-session-continuity-mcp¡Eso es todo! El script postinstall automáticamente:
Registra el servidor MCP en ~/.claude.json
Instala los Claude Hooks en ~/.claude/settings.json
Servidor MCP (en ~/.claude.json):
{
"mcpServers": {
"project-manager": {
"command": "npx",
"args": ["claude-session-continuity-mcp"]
}
}
}Claude Hooks (en ~/.claude/settings.json):
{
"hooks": {
"SessionStart": [{ "hooks": [{ "type": "command", "command": "npm exec -- claude-hook-session-start" }] }],
"UserPromptSubmit": [{ "hooks": [{ "type": "command", "command": "npm exec -- claude-hook-user-prompt" }] }],
"PostToolUse": [{ "matcher": "Edit", "hooks": [{ "type": "command", "command": "npm exec -- claude-hook-post-tool" }] }, { "matcher": "Write", "hooks": [{ "type": "command", "command": "npm exec -- claude-hook-post-tool" }] }],
"PreCompact": [{ "hooks": [{ "type": "command", "command": "npm exec -- claude-hook-pre-compact" }] }],
"Stop": [{ "hooks": [{ "type": "command", "command": "npm exec -- claude-hook-session-end" }] }]
}
}Nota (v1.5.0+): Cobertura completa del ciclo de vida con 5 hooks. Utiliza npm exec -- que busca primero en node_modules/.bin local.
Hook | Comando | Función |
|
| Carga automáticamente el contexto del proyecto al iniciar la sesión |
|
| Inyecta automáticamente memorias relevantes + búsqueda de referencias pasadas |
|
| Rastrea archivos activos (Edit, Write) + inyecta automáticamente soluciones a errores (Bash) |
|
| Contexto de entrega estructurado antes de la compresión |
|
| Extrae commits, decisiones y pares error-solución de la transcripción |
# Check hook status
npx claude-session-hooks status
# Reinstall hooks
npx claude-session-hooks install
# Remove hooks
npx claude-session-hooks uninstallDespués de la instalación, reinicia Claude Code para activar los hooks.
Característica | Descripción |
🤖 Cero trabajo manual | Los Claude Hooks automatizan toda la captura/carga de contexto |
🎯 Solo memoria de calidad | (v1.10.0) Solo decisiones, aprendizajes, errores — sin ruido de cambios de archivo |
🧠 Búsqueda semántica | Embeddings multilingual-e5-small (94+ idiomas, 384d) |
🌍 Multilingüe | Coreano/Inglés/Japonés + búsqueda entre idiomas (EN→KR, KR→EN) |
🔗 Integración con Git | Mensajes de commit extraídos automáticamente de las transcripciones |
🕸️ Grafo de conocimiento | Relaciones de memoria (resuelve, causa, extiende...) |
📊 Clasificación de memoria | 5 tipos: observación, decisión, aprendizaje, error, patrón |
✅ Verificación integrada | Ejecución de build/test/lint con un clic |
📋 Gestión de tareas | Gestión de tareas basada en prioridades |
🔧 Auto Error→Solución | (v1.12.0) Detección automática de errores Bash → inyecta soluciones pasadas; el fin de sesión registra automáticamente pares error-solución |
💰 Eficiencia de tokens | (v1.11.0) Se eliminó loadContext de UserPromptSubmit (ahorra 24-60K tokens/sesión) |
📑 Divulgación progresiva | (v1.11.0) memory_search devuelve primero el índice, memory_get para el contenido completo |
⏳ Decaimiento temporal | (v1.11.0) Puntuación de memoria con vidas medias específicas por tipo para relevancia |
📝 Entrega estructurada | (v1.10.0) PreCompact guarda resumen de trabajo, archivos activos, acciones pendientes |
🚪 Fin de sesión inteligente | (v1.10.0) Extrae commits, decisiones, pares error-solución de la transcripción |
🗑️ Limpieza automática de ruido | (v1.10.0) Elimina automáticamente memorias de observación obsoletas (3d+) |
🔍 Detección de referencias pasadas | (v1.8.0) "¿Cómo hicimos X la última vez?" busca automáticamente en la BD |
📝 Extracción de directivas de usuario | (v1.8.0) Extrae automáticamente reglas "siempre/nunca" de los prompts |
Hook SessionStart (npx claude-hook-session-start):
Detecta automáticamente el proyecto: monorepo (apps/project-name/) o proyecto único (nombre de la carpeta raíz package.json)
Carga el contexto desde .claude/sessions.db
Inyecta: Estado actual, 3 sesiones recientes con commits/decisiones, directivas, tareas pendientes, memorias clave filtradas
Limpia automáticamente memorias de ruido obsoletas (3d+ rastreo automático, 14d+ compactación automática)
Hook UserPromptSubmit (npx claude-hook-user-prompt):
Se ejecuta en cada envío de prompt
(v1.11.0) Ya no llama a loadContext() — ahorra 24-60K tokens/sesión
Inyecta contexto relevante (filtrado: solo decisiones, aprendizajes, errores)
Hook PostToolUse (npx claude-hook-post-tool):
Rastrea rutas de archivos activos y actualiza active_context.recent_files
(v1.12.0) Detecta automáticamente errores Bash → busca en la BD de soluciones → inyecta soluciones pasadas en el contexto
Ya no crea memorias de observación (v1.10.0 — elimina el ruido de [File Change])
Hook PreCompact (npx claude-hook-pre-compact):
Construye un contexto de entrega estructurado: resumen de trabajo, archivo activo, acción pendiente, hechos clave, errores recientes
Ya no almacena memorias de auto-compactación (v1.10.0)
Hook Stop (npx claude-hook-session-end):
Extrae mensajes de commit de la transcripción JSONL (patrones git commit -m)
Extrae pares error-solución (error → resolución en 3 mensajes)
(v1.12.0) Registra automáticamente pares error→solución en la tabla de soluciones para reutilización futura
Extrae decisiones (patrones "porque", "en lugar de", "elegí")
(v1.11.0) Análisis de transcripción de una sola pasada (4 lecturas JSONL → 1)
Almacena metadatos estructurados en la columna sessions.issues como JSON
# my-app - Session Resumed
📍 **State**: Implementing signup form
🚧 **Blocker**: OAuth callback URL issue
## Recent Sessions
### 2026-02-28
**Work**: Completed OAuth integration
**Commits**: feat: add OAuth handler; fix: redirect config
**Decisions**: Use Server Actions over API routes
**Next**: Implement form validation
## Directives
- 🔴 Always use Zod for validation
## Pending Tasks
- 🔄 [P8] Implement form validation
- ⏳ [P5] Add error handling
## Key Memories
- 🎯 Decided on App Router, using Server Actions
- ⚠️ OAuth redirect_uri mismatch → check env file# Check status
npx claude-session-hooks status
# Reinstall
npx claude-session-hooks install
# Remove
npx claude-session-hooks uninstall
# Temporarily disable
export MCP_HOOKS_DISABLED=trueCuando preguntas sobre trabajo pasado, el hook UserPromptSubmit busca automáticamente en la base de datos:
You: "저번에 인앱결제 어떻게 했어?"
→ Hook detects "저번에" + extracts keyword "인앱결제"
→ Searches sessions, memories (FTS5), and solutions
→ Injects matching results into context automaticallyPatrones soportados (Coreano e Inglés):
Patrón | Ejemplo |
저번에/전에/이전에 ... 어떻게 | "¿Cómo solucionamos el error de CORS la última vez?" |
~했던/만들었던/해결했던 | "Lógica de inicio de sesión que modificamos" |
지난 세션/작업에서 | "Implementación de pagos en la sesión pasada" |
last time/before/previously | "¿Cómo manejamos la autenticación la última vez?" |
did we/did I ... before | "¿Arreglamos la migración de la base de datos antes?" |
remember when/recall when | "¿Recuerdas cuando configuramos CI?" |
Ejemplo de salida:
## Related Past Work (auto-detected from your question)
### Sessions
- [2/14] 카카오 로그인 앱키 수정, 인앱결제 IAP 플로우 수정
### Memories
- 🎯 [decision] 테스트: 인앱결제 상품 등록 완료
### Solutions
- **IAP_BILLING_ERROR**: StoreKit 2 migration으로 해결Las versiones anteriores usaban rutas absolutas o npx:
// v1.3.x - absolute paths (broke on multi-project)
"command": "node \"/path/to/project-a/node_modules/.../session-start.js\""
// v1.4.0-1.4.2 - npx (required global install or hit npm registry)
"command": "npx claude-hook-session-start"Ahora usamos npm exec --:
"command": "npm exec -- claude-hook-session-start"npm exec -- busca primero en node_modules/.bin local, y luego recurre al global. Funciona tanto con instalación local como global sin acceder al registro de npm.
// Start of session - auto-loads context
session_start({ project: "my-app", compact: true })
// End of session - auto-saves context
session_end({
project: "my-app",
summary: "Completed auth flow",
modifiedFiles: ["src/auth.ts", "src/login/page.tsx"]
})
// View session history
session_history({ project: "my-app", limit: 5 })
// Semantic search past sessions
search_sessions({ query: "auth work", project: "my-app" })// Get project status with task stats
project_status({ project: "my-app" })
// Initialize new project
project_init({ project: "my-app" })
// Analyze project tech stack
project_analyze({ project: "my-app" })
// List all projects
list_projects()// Add a task
task_add({ project: "my-app", title: "Implement signup", priority: 8 })
// Update task status
task_update({ taskId: 1, status: "done" })
// List tasks
task_list({ project: "my-app", status: "pending" })
// Suggest tasks from TODO comments
task_suggest({ project: "my-app" })// Record an error solution
solution_record({
errorSignature: "TypeError: Cannot read property 'id'",
solution: "Use optional chaining: user?.id"
})
// Find similar solutions (keyword or semantic)
solution_find({ query: "TypeError property", semantic: true })
// AI-powered solution suggestion
solution_suggest({ errorMessage: "Cannot read property 'email'" })// Run build
verify_build({ project: "my-app" })
// Run tests
verify_test({ project: "my-app" })
// Run all (build + test + lint)
verify_all({ project: "my-app" })// Store a classified memory
memory_store({
content: "State management with Riverpod makes testing easier",
type: "learning", // observation, decision, learning, error, pattern
project: "my-app",
tags: ["flutter", "state-management"],
importance: 8,
relatedTo: 23 // Connect to existing memory
})
// Search memories — returns index (id, type, tags, score) for token efficiency
memory_search({
query: "state management test",
type: "learning",
semantic: true, // Use embedding similarity
limit: 10
})
// Get full memory content by ID (v1.11.0)
memory_get({ memoryId: 23 })
// Find related memories (graph + semantic)
memory_related({
memoryId: 23,
includeGraph: true,
includeSemantic: true
})
// Get memory statistics
memory_stats({ project: "my-app" })// Connect two memories with a typed relation
graph_connect({
sourceId: 23,
targetId: 25,
relation: "solves", // related_to, causes, solves, depends_on, contradicts, extends, example_of
strength: 0.9
})
// Explore knowledge graph
graph_explore({
memoryId: 23,
depth: 2,
relation: "all", // or specific relation type
direction: "both" // outgoing, incoming, both
})Tipo | Descripción | Caso de uso |
| Patrones, estructuras encontradas en el código | "Todas las pantallas están separadas en la carpeta features/" |
| Arquitectura, elecciones de librerías | "Decidimos usar SharedPreferences para caché" |
| Nuevo conocimiento, mejores prácticas | "Riverpod es mejor para pruebas" |
| Errores ocurridos y soluciones | "Provider.read() no reconstruye → usar watch()" |
| Patrones de código recurrentes, convenciones | "Evitar el abuso de la palabra clave late" |
Relación | Descripción | Ejemplo |
| Relación general | A y B están relacionados |
| A causa B | Decisión de caché → cambio en estructura de carpetas |
| A resuelve B | Aprendizaje de Riverpod → corrección de error de Provider |
| A depende de B | Estructura de carpetas → decisión de caché |
| A contradice B | Dos decisiones de diseño entran en conflicto |
| A extiende B | Patrón late → extendido al aprendizaje de Riverpod |
| A es ejemplo de B | Código específico es ejemplo de patrón |
Base de datos SQLite en ~/.claude/sessions.db:
Tabla | Propósito |
| Memorias clasificadas (observación, decisión, aprendizaje, error, patrón) |
| Índice de búsqueda de texto completo (FTS5) |
| Relaciones del grafo de conocimiento |
| Vectores de búsqueda semántica (multilingual-e5-small, 384d) |
| Información fija del proyecto (stack tecnológico, decisiones) |
| Estado actual del trabajo |
| Backlog de tareas |
| Archivo de soluciones de errores |
| Historial de sesiones |
Variable | Predeterminado | Descripción |
| - | Ruta raíz del espacio de trabajo (requerido) |
|
| Deshabilitar Claude Hooks |
|
| Nivel de registro (debug/info/warn/error) |
| - | Ruta de registro en archivo opcional |
# Clone
git clone https://github.com/leesgit/claude-session-continuity-mcp.git
cd claude-session-continuity-mcp
# Install
npm install
# Build
npm run build
# Test
npm test
# Test with coverage
npm run test:coverageMétrica | Valor |
Carga de contexto (caché) | <5ms |
Búsqueda de memoria (FTS) | ~10ms |
Búsqueda semántica | ~50ms |
Verificación de build | Dependiente del proyecto |
[x] API v2 (15 herramientas enfocadas)
[x] API v4 (24 herramientas - memoria + grafo)
[x] Claude Hooks v5 (captura automática)
[x] Grafo de conocimiento con relaciones tipadas
[x] Clasificación de memoria (6 tipos)
[x] Búsqueda semántica (embeddings)
[x] Detección de patrones multilingües (KO/EN/JA)
[x] Integración de commits de Git
[x] 111 pruebas (6 suites de prueba)
[x] CI/CD de GitHub Actions
[x] Búsqueda semántica multilingüe (v1.6.0 - multilingual-e5-small)
[x] Búsqueda entre idiomas EN↔KR (v1.6.0)
[x] Búsqueda semántica de soluciones (v1.6.0)
[x] Corregir ruta del archivo de configuración de hooks (v1.6.1 - settings.json, no settings.local.json)
[x] Migración automática de hooks heredados (v1.6.1)
[x] Corregir formato de matcher de PostToolUse a string (v1.6.3)
[x] Corregir documentación del README para el nuevo formato de hook (v1.6.4)
[x] Mejoras en el salto de sesión vacía y guardado de techStack (v1.7.1)
[x] Detección automática de referencias pasadas en el hook UserPromptSubmit (v1.8.0)
[x] Extracción de directivas de usuario (reglas "siempre/nunca") (v1.8.0)
[x] Revisión de calidad de memoria — no más ruido de [File Change] (v1.10.0)
[x] Contexto de entrega estructurado en PreCompact (v1.10.0)
[x] Fin de sesión inteligente: extracción de commit/decisión/error-solución de la transcripción (v1.10.0)
[x] Limpieza automática de ruido (observaciones 3d+, auto-compactación 14d+) (v1.10.0)
[x] Visualización de 3 sesiones recientes con metadatos estructurados (v1.10.0)
[x] Eficiencia de tokens — eliminar loadContext de UserPromptSubmit, ahorra
Create a directed edge between two memories in the knowledge graph. Supports 7 relation types for structured knowledge organization. Side effects: inserts or replaces a row in memory_relations (upsert on sourceId+targetId+relation). Use memory_related to discover existing connections; use graph_explore to traverse the graph from a starting node.
| Name | Required | Description | Default |
|---|---|---|---|
| sourceId | Yes | Source memory ID (the "from" node) | |
| targetId | Yes | Target memory ID (the "to" node) | |
| relation | Yes | Edge type: related_to (general association), causes (A causes B), solves (A fixes B), depends_on (A requires B), contradicts (A conflicts with B), extends (A builds on B), example_of (A demonstrates B) | |
| strength | No | Connection strength 0.0-1.0 (default: 1.0). Lower values indicate weaker associations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the upsert behavior (inserts or replaces) which is important for understanding side effects. With no annotations, this is valuable. Lacks details on return value or error conditions, but overall adequate.
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?
Four concise sentences without waste. Each sentence adds value: purpose, relation types, side effects, usage guidance. Front-loaded with the core action.
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 purpose, side effects, and usage alternatives. Lacks return value details and error handling, but for a simple create tool, it is mostly complete given no output schema.
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 detailed parameter descriptions. The description only mentions there are 7 relation types without adding new semantics beyond the schema, so it does not significantly 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 the tool creates a directed edge between two memories in the knowledge graph, with 7 relation types. It distinguishes from siblings by referencing memory_related for discovery and graph_explore for traversal.
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 advises when to use alternative tools: memory_related to discover connections and graph_explore to traverse. Also notes the side effect (upsert), guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Traverse the knowledge graph from a starting memory using depth-first search. Returns all connected memories up to the specified depth, with their relation types, strengths, and directions. Read-only. Supports filtering by relation type and traversal direction. Use memory_related instead for a combined graph+semantic approach; use graph_connect to add new edges.
| Name | Required | Description | Default |
|---|---|---|---|
| memoryId | Yes | Starting memory ID for graph traversal | |
| depth | No | Maximum traversal depth 1-4 (default: 2). Higher values return more results but may be slower. | |
| relation | No | Filter by relation type (default: "all") | |
| direction | No | Traversal direction — outgoing (A→B), incoming (B→A), or both (default: "both") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description declares read-only access, depth limit (1-4), and performance trade-off for higher depths. No annotations exist, so description carries the burden; it does well but could add more about time complexity or result size.
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 sentences with no wasted words. All key information is front-loaded: purpose, behavior, alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return value (connected memories with relation types, strengths, directions). It also covers filtering capabilities and read-only nature. Sufficient for most use cases, though could mention pagination if results are large.
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?
Input schema has 100% description coverage, so baseline is 3. The description adds a performance note for depth, but overall the schema already explains each parameter adequately.
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 traverses the knowledge graph via depth-first search, returning connected memories with relation details. It distinguishes from siblings by naming 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?
Explicitly tells when to use this tool (graph exploration) and when to use alternatives (memory_related for combined approach, graph_connect for adding edges). Also notes it is read-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects under the apps/ directory with their platform type (Web/Android/Flutter), initialization status, and whether session context exists. Read-only. Returns an array of project summary objects. No parameters required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description declares it is read-only and returns an array of project summary objects. It does not detail the exact output fields or potential errors, but for a simple list tool it is fairly transparent.
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 extremely concise—three sentences covering purpose, return type, and parameters. No redundant or unnecessary text.
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 no parameters and no output schema, the description is reasonably complete. It specifies what is listed, that it's read-only, and that it returns an array of summary objects. Missing detail on exact output fields, but overall 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?
There are no parameters, and schema coverage is 100% (empty). According to the rubric, 0 params gives a baseline of 4. The description adds no additional parameter info 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 it lists all projects under apps/ with specific fields (platform type, initialization status, session context). It is a specific verb+resource and distinguishes from siblings like project_init or project_analyze.
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 says 'List all projects' but provides no guidance on when to use this tool vs alternatives like project_status or other listing tools. No comparisons or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve full content for one or more memories by ID. Designed as a follow-up to memory_search: first search to find relevant IDs, then use memory_get to load full details. Read-only. Accepts up to 20 IDs per call. Returns an array of complete memory objects including content, type, tags, importance, timestamps, and access count.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Array of memory IDs to retrieve (max 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description fully discloses behavior: read-only operation, response structure (array of memory objects with fields), and lack of side effects.
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 front-loading purpose and usage. 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?
Without output schema, description fully covers return format (fields included) and constraints (max 20 IDs). Complete for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context by explaining the retrieval workflow but does not add new parameter-level details beyond what the schema already provides.
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 explicitly states verb+resource: 'Retrieve full content for one or more memories by ID.' It distinguishes from sibling tool memory_search by framing as a follow-up step.
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?
Clear usage flow: 'first search to find relevant IDs, then use memory_get to load full details.' Also specifies read-only and batch limit of 20 IDs per call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search stored memories using FTS5 full-text search or semantic/embedding similarity. Default mode returns compact index entries (id, type, truncated content) to save tokens — set detail=true for full content. Supports filtering by type, project, tags, and minimum importance. Read-only. Use memory_get to fetch full content for specific IDs found in search results. Use memory_related to explore graph connections from a known memory.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language search query | |
| type | No | Filter by memory type (default: "all") | |
| project | No | Filter by project (optional) | |
| tags | No | Filter by tags — matches if any tag is present (optional) | |
| semantic | No | Use embedding-based semantic search instead of keyword FTS5 (default: false) | |
| minImportance | No | Minimum importance threshold 1-10 (default: 1) | |
| limit | No | Max results to return (default: 10) | |
| detail | No | Return full content per memory (default: false — returns compact index only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is read-only, explains the default compact output vs. detailed mode, and describes the truncation of content. It does not mention response format fields but covers essential behaviors.
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. It front-loads the main purpose, then details default behavior and filtering, ending with sibling guidance. It is efficient and clear, though the second sentence could be slightly more structured.
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 8 parameters (all documented in schema) and no output schema, the description adequately covers the purpose and usage. However, it does not specify the full output structure beyond 'id, type, truncated content', leaving some return fields unmentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds minimal new semantics beyond the schema, mostly listing filter options already present. It echoes schema descriptions for 'semantic' and 'detail' but does not introduce new meaning.
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 specifies the verb 'search' and the resource 'stored memories', distinguishing it from siblings like memory_get and memory_related. It mentions both FTS5 keyword search and semantic embedding similarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use alternative tools: 'Use memory_get to fetch full content for specific IDs found in search results. Use memory_related to explore graph connections from a known memory.' It also clarifies the read-only nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate statistics about the memory system: total count, breakdown by type (observation/decision/learning/error/pattern), breakdown by project, top 5 most accessed memories, and 5 most recent entries. Read-only. Useful for understanding memory distribution and system health. Optionally scope to a single project.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Scope statistics to a single project (optional — omit for global stats) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly notes 'Read-only,' which is a key behavioral trait. However, with no annotations provided, the description carries the full burden. It does not disclose other potential traits like idempotency, authentication needs, or performance characteristics, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only three sentences, each adding essential information. The key action and outputs are front-loaded, and there is no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description enumerates the return values (count, breakdowns, top accessed, recent entries), providing sufficient context for an agent to understand what to expect. However, it omits error scenarios or data size limits, which would be beneficial for robust 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?
There is only one parameter, 'project', with a schema description explaining its role. The tool description adds a brief note ('Optionally scope to a single project') but does not significantly enhance understanding beyond the schema. With 100% schema coverage, a baseline of 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 'Get aggregate statistics about the memory system' and lists specific breakdowns (count, type, project, top accessed, recent entries). This distinguishes it from sibling tools like memory_get, memory_search, and memory_store, which focus on individual memories or queries.
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 includes 'Useful for understanding memory distribution and system health' and 'Optionally scope to a single project,' which imply appropriate contexts. It does not explicitly state when not to use or mention alternatives, but the purpose is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a piece of knowledge in the memory system. Memories are typed (observation, decision, learning, error, pattern), tagged, and automatically embedded for semantic retrieval. Side effects: inserts into the memories table and asynchronously generates a vector embedding. If relatedTo is provided, also creates a knowledge graph edge. Returns the new memory ID. Use memory_search to verify no duplicate exists before storing.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The knowledge content to store | |
| type | Yes | Memory type: observation (discovery/finding), decision (architecture/tech choice), learning (new knowledge), error (error encountered), pattern (code convention) | |
| project | No | Associated project name (optional — omit for cross-project knowledge) | |
| tags | No | Tags for filtering (e.g. ["auth", "performance"]) | |
| importance | No | Importance score 1-10 where 10 is critical (default: 5) | |
| relatedTo | No | ID of an existing memory to link via knowledge graph (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses side effects: inserts into table, async embedding, optional graph edge, and return value. Could mention timing of async operation, but current detail is strong.
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-loaded with purpose, followed by side effects and usage guidance. Every sentence is valuable and succinct.
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 6 parameters and no output schema, the description covers all essential aspects: side effects, return value, duplicate checking advice. Complete for an AI agent to use correctly.
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 descriptions, so baseline is 3. Description adds context by explaining that memories are typed/tagged and that relatedTo creates a knowledge graph edge, going beyond 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 it stores knowledge in the memory system, lists memory types, and differentiates from sibling memory_search by advising to verify duplicates. It specifies verb and resource with distinct purpose.
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 advises using memory_search to verify no duplicate before storing, providing when-not-to-use guidance and an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect a project's tech stack, framework, platform (Web/Android/Flutter/Server), directory structure, and dependency count by scanning its files. Read-only — does not persist results. Returns a structured analysis object. Use project_init to persist the detected configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (must match a directory under apps/) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Read-only — does not persist results', clearly disclosing non-mutating behavior. Mentions returned analysis object, but lacks detail on permissions or cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with key purpose. Every sentence adds value.
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 lists output components (tech stack, etc.). Lacks details on async behavior, time cost, or whether scanning is heavy. Adequate but not fully complete given complexity.
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?
Single parameter 'project' with schema description (project name under apps/). Schema coverage 100%, so description adds no extra meaning beyond schema. Baseline 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?
Description clearly states it auto-detects tech stack, framework, platform, directory structure, and dependency count. Verb 'detect' and resource 'project' are specific. Distinguishes from sibling project_init by noting persistence difference.
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 tells user to use project_init for persistence, implying this tool is for inspection. Could be more explicit about when to use vs other siblings, but clear alternative provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize a new project in the continuity system. Creates records in the project_context and active_context tables. Auto-detects tech stack from package.json/pubspec.yaml/build.gradle if present. Side effects: writes to SQLite. Idempotent — safe to call on an already-initialized project (updates existing record). Call this once when adding a new project, then use session_start for subsequent sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (must match a directory under apps/) | |
| techStack | No | Tech stack override {framework, language, database, ...}. Omit for auto-detection. | |
| description | No | Human-readable project description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects (writes to SQLite), idempotency, and auto-detection behavior. Lacks details on error conditions or permissions, but adequate given no annotations.
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?
Concise, front-loaded with main action, then key details. No redundant sentences.
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 purpose, usage, side effects, and idempotency. Lacks output schema but no output expected; sufficient for 3-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds context: project must match a directory under apps/ and techStack is an override. Adds value beyond 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 initializes a new project, creates records in specific tables, and auto-detects tech stack. It distinguishes from siblings like session_start and project_status.
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 to call once for new project, then use session_start for subsequent sessions. Also notes idempotency, guiding safe reuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a project's current status including completion percentage, task breakdown (pending/in-progress/done/blocked), recent session activity, and active blockers. Read-only. Returns a structured JSON object. Use session_start instead when bootstrapping a new conversation; use this for mid-session status checks.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (must match a directory under apps/) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It declares 'Read-only' and notes the return format, but omits other behavioral details like authentication, error cases, or rate limits. Decent but could add more context.
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 concise with three short sentences covering purpose, read-only nature, return format, and usage guidance. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value by listing included fields. It covers essential context for a simple status-check tool, though it could mention behavior for invalid projects or error handling.
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 for the single parameter 'project' is 100%, so baseline is 3. The description does not add meaning beyond what the schema already provides (the schema already states 'must match a directory under apps/'). No extra value added.
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 gets a project's current status and lists specific data returned (completion percentage, task breakdown, session activity, blockers). It explicitly distinguishes from session_start, making its purpose distinct among siblings.
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 gives explicit guidance on when to use (mid-session status checks) and when not (use session_start for bootstrapping). This directly helps the agent select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search across session history using multilingual embeddings (94+ languages). Finds past sessions by meaning, not just keywords — e.g. "when I worked on authentication" matches sessions about login, OAuth, JWT. Falls back to FTS5 keyword search when embeddings are unavailable. Read-only. Use session_history instead when you just need the N most recent sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language search query | |
| project | No | Filter by project (optional) | |
| limit | No | Max results to return (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares the tool is 'Read-only' and explains the fallback behavior, adding value beyond the schema. No annotations are provided, so the description carries the full burden. It could be improved by mentioning any rate limits or authentication needs, but for a search tool this is adequate.
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 concise with three sentences: defining the tool, giving an example, and providing fallback and alternative. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description is complete for a search tool: it explains the semantic approach, multilingual support, fallback, and sibling tool. It covers what an agent needs to decide when to invoke this tool vs. alternatives.
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 documents all parameters. The description reinforces the meaning of 'query' as natural language, 'project' as optional filter, and 'limit' defaulting to 5. It does not add new meaning beyond what the schema provides, hence a baseline score of 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 it performs 'Semantic search across session history' using multilingual embeddings, provides a concrete example, and distinguishes itself from the sibling tool 'session_history' by noting the latter is for recent sessions. The verb 'search' and resource 'sessions' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool vs. the alternative: 'Use session_history instead when you just need the N most recent sessions.' It also notes the fallback to FTS5 when embeddings are unavailable, giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the current session state before ending a conversation. Persists a summary, completed work, next steps, modified files, and blockers to SQLite. The saved state is automatically restored by session_start in the next session. Side effects: writes to the sessions table and updates the active_context record for the project. Idempotent — calling multiple times overwrites the previous session record.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (must match a directory under apps/) | |
| summary | Yes | One-line summary of this session | |
| workDone | No | Description of completed work | |
| nextSteps | No | Ordered list of next tasks to pick up | |
| modifiedFiles | No | Files modified during this session | |
| blockers | No | Current blockers or issues (null if none) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses side effects (writes to sessions table and updates active_context) and states idempotency. This provides meaningful behavioral transparency about persistence and overwrite 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?
The description is three sentences with no wasted words. It front-loads the core purpose, then explains restoration, and finally lists side effects and idempotency. Every sentence serves a purpose.
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?
The description covers what the tool does, its relationship to session_start, side effects, and idempotency. It does not explain return values (likely none) or error conditions, but these are not essential given the tool's simplicity and no output schema.
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 6 parameters have descriptions in the input schema (100% coverage). The description adds context by listing the fields as being persisted, but does not add meaning beyond what the schema already provides, so 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 it saves session state and lists specific fields (summary, work done, etc.). It distinguishes the tool's purpose from session_start by noting restoration, but does not explicitly differentiate from sibling session tools like session_history or search_sessions.
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 using it 'before ending a conversation' and notes automatic restoration by session_start, providing clear usage context. However, it lacks explicit guidance on when not to use it or alternatives (e.g., session_history for viewing past sessions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve past session records for a project. Returns an array of session objects ordered by most recent first, each containing summary, work done, modified files, and verification results. Read-only. Use search_sessions instead when you need semantic/keyword matching rather than a chronological list.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (must match a directory under apps/) | |
| limit | No | Max records to return (default: 5) | |
| days | No | Only return sessions from the last N days (default: 7) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description declares the tool as 'Read-only' and describes the return structure. It does not cover error behavior or permissions, but for a simple retrieval tool this is adequate.
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 two sentences long, front-loaded with the core purpose, and contains no redundant 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?
For a straightforward list tool with three well-documented parameters, the description covers purpose, behavior, return content, and usage guidance. No output schema exists, but the description suffices.
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 explains the parameters. The description does not add further meaning beyond the schema, making a typical baseline score of 3 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 retrieves past session records for a project, ordered chronologically, and lists the included fields (summary, work done, etc.). It explicitly distinguishes itself from the sibling tool 'search_sessions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (chronological listing) versus the alternative 'search_sessions' (semantic/keyword matching). No other usage exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load project context at the beginning of a session. Typically auto-invoked by the SessionStart hook, but can be called manually. Returns the project's tech stack, recent activity, pending tasks, and active blockers as a compressed context payload (~650 tokens). Read-only — does not modify any state. Use this instead of project_status when you need the full session bootstrap context.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (must match a directory under apps/) | |
| compact | No | Return compressed format (default: true). Set false for verbose output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: read-only, returns compressed payload (~650 tokens) with specific fields (tech stack, recent activity, pending tasks, active blockers).
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 sentences, efficient, but last sentence partially redundant with earlier 'use instead' advice. Still well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and few annotations, description provides sufficient context: purpose, usage, behavior, output summary, and sibling distinction.
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% and descriptions are clear. Description adds no extra parameter meaning 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?
Description clearly states the tool loads project context at session start. It distinguishes from sibling project_status by specifying when to use each.
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 mentions typical auto-invocation but allows manual calls. Provides alternative tool (project_status) and advises when to use this instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the solution archive for previously resolved errors. Matches against error signatures, messages, and keywords using FTS5. Set semantic=true to enable embedding-based similarity search for better recall across different error phrasings. Read-only. Returns matched solutions with their fix descriptions and related files. Use solution_suggest instead if you want AI-powered fix recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Error message, signature, or natural language description of the problem | |
| project | No | Filter by project (optional — also includes cross-project solutions) | |
| limit | No | Max results to return (default: 3) | |
| semantic | No | Enable semantic/embedding search for fuzzy matching (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares read-only nature and return content (fix descriptions, related files). Lacks details like pagination or auth, but sufficient for a search 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?
Three sentences, each earning its place: purpose, optional feature, alternative. Front-loaded and 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 functionality, read-only flag, and alternative tool. Lacks pagination details but adequate for a 4-param tool with no output schema.
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 context beyond schema by explaining semantic parameter and default limit. All parameters described in 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 it searches for resolved errors using FTS5 and semantic search, distinguishing from sibling solution_suggest.
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 when to use (searching resolved errors) and when not (use solution_suggest for AI-powered recommendations), providing clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an error-solution pair in the solution archive. Associates an error signature (the searchable key), optional full error message, the fix, and related files. Automatically extracts keywords for FTS5 indexing. Side effects: inserts into the solutions table. Use solution_find to check for existing solutions before recording a duplicate.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name (optional — omit for cross-project solutions) | |
| errorSignature | Yes | Error pattern/signature used as the search key (e.g. "ENOENT: no such file", "WorkManager not initialized") | |
| errorMessage | No | Full error message or stack trace (optional) | |
| solution | Yes | Step-by-step fix description | |
| relatedFiles | No | Files that were modified to fix the error |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Discloses side effects (inserts into solutions table) and automatic keyword extraction for FTS5 indexing. Missing details on idempotency, error handling, or limits.
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?
Concise multi-sentence description with no fluff. Each sentence adds value: purpose, components, side effects, and usage guidance.
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 purpose, components, side effects, and duplicate prevention. Lacks return value info, but no output schema exists. Adequate for the tool's complexity.
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% coverage, baseline 3. Description adds value by explaining errorSignature as 'search key', noting optional fields, and mentioning automatic keyword extraction.
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 'Record an error-solution pair' and lists components. It distinguishes from sibling solution_find by mentioning duplicate checking.
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 advises to use solution_find before recording to avoid duplicates, providing clear context. Lacks explicit when-not-to-use but sufficient given siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AI-powered fix suggestions for a current error based on the solution archive. Retrieves the most relevant past solutions and generates a contextual recommendation. Read-only. Use solution_find for direct archive lookup without AI synthesis; use solution_record after fixing an error to grow the archive.
| Name | Required | Description | Default |
|---|---|---|---|
| errorMessage | Yes | The current error message or stack trace | |
| project | No | Project name for context (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description explicitly states it is read-only, which is a key behavioral trait. It does not detail other aspects like auth or rate limits, but the read-only flag adds value beyond the structured fields.
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, each serving a distinct purpose: main action, read-only note, and sibling alternatives. No wasted words, front-loaded with the core functionality.
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?
The description covers the tool's purpose, usage context, and behavioral trait (read-only). It does not explicitly state the return format, but the output is implied as a recommendation. Given the tool's simplicity and sibling guidance, 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?
The input schema has 100% description coverage, and the description restates the same parameter meanings without adding significant new context. Baseline 3 is appropriate as the description does not deepen understanding 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 provides AI-powered fix suggestions for errors using the solution archive. It specifies the action (get suggestions) and the resource (current error, solution archive), and distinguishes from siblings.
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 states when to use this tool versus alternatives: use solution_find for direct archive lookup and solution_record after fixing an error. This provides clear context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new task to a project's backlog. Tasks are persisted in SQLite with priority ranking and optional file associations. Side effects: inserts into the tasks table. Returns the created task ID. Use task_list to view existing tasks before adding duplicates. Use task_suggest to auto-generate tasks from code comments (TODO/FIXME).
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (must match a directory under apps/) | |
| title | Yes | Task title (concise, actionable) | |
| description | No | Detailed description (optional) | |
| priority | No | Priority 1-10 where 10 is highest (default: 5) | |
| relatedFiles | No | Associated file paths (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full responsibility. It mentions side effects (inserts into tasks table) and return value (task ID), but does not disclose error conditions, required permissions, or default behavior beyond basic schema.
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 long, front-loaded with purpose, followed by behavioral notes and usage alternatives. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description covers purpose, side effects, return value, and alternative tools. It is mostly complete, though missing specifics on failure modes or default priority handling.
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 context about persistence in SQLite and optional file associations, but does not significantly enhance parameter understanding beyond what the schema already provides.
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 'Add a new task to a project's backlog', specifying the verb (add) and resource (task to backlog). It distinguishes from siblings like task_list (view) and task_suggest (auto-generate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using task_list to check for duplicates and task_suggest for auto-generating from code comments, providing clear guidance on when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks for a project, filtered by status. Returns an array of task objects with id, title, description, status, priority, related files, and timestamps, plus a summary count by status. Read-only. Default filter is "pending" — pass status="all" to see everything.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (must match a directory under apps/) | |
| status | No | Status filter (default: "pending") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the read-only behavior and return structure (array of task objects with fields, plus summary count), providing thorough 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?
Two concise sentences, no wasted words, front-loaded with key purpose and return info.
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 read tool with complete schema and clear return description, the description sufficiently covers all necessary context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds useful default value for status and return context but does not significantly enhance parameter meaning beyond 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 verb 'List', resource 'tasks', and scope 'for a project, filtered by status', distinguishing it from sibling tools like task_add or task_update.
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 read-only nature and default filter, guiding when to use, but lacks explicit 'when not to use' or direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan project source files for TODO, FIXME, HACK, and XXX comments and return them as suggested tasks. Read-only — does not create tasks automatically. Review the suggestions and use task_add to persist the ones you want. Optionally scope the scan to a specific subdirectory.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (must match a directory under apps/) | |
| path | No | Subdirectory path to limit the scan (optional, e.g. "src/components") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly declares the tool as read-only ('Read-only — does not create tasks automatically'), which provides important behavioral context. With no annotations, this disclosure is critical and well-stated.
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 sentences, no wasted words. The purpose is front-loaded, followed by behavior and usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers purpose, behavior, usage guidance, and optional parameter meaning. It could potentially mention the return format, but it is sufficiently complete for the tool's simplicity.
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 both parameters already described. The description adds value by reinforcing the optional nature of the 'path' parameter ('Optionally scope the scan to a specific subdirectory'), going 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 scans project source files for specific comment types (TODO, FIXME, HACK, XXX) and returns them as suggested tasks. This specific verb+resource combination distinguishes it from sibling tools like task_add, task_list, and task_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Review the suggestions and use task_add to persist the ones you want.' It also mentions optional scoping. While it does not explicitly state when not to use this tool, it does give a clear alternative for persistence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a task's status. Valid transitions: pending → in_progress → done, or any state → blocked. Setting status to "done" automatically records a completion timestamp. Side effects: updates the tasks table. Idempotent. Returns success/failure and whether the row was actually modified.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID (from task_add or task_list) | |
| status | Yes | New status | |
| note | No | Optional note (e.g. completion summary or block reason) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details side effects (updates tasks table), idempotence, return information, and automatic timestamp for 'done' status, fully covering behavioral traits without annotations.
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 concise with three sentences, front-loads purpose, and every sentence adds value.
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 low complexity, no output schema, but the description explains return; sibling tools are listed, making it complete for an update 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?
Although schema coverage is 100%, the description adds meaningful context for parameters: valid transitions for status and example usage for note.
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 updates a task's status and lists valid transitions, distinguishing it from siblings like task_add and task_list.
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 explains valid status transitions but does not explicitly guide when to use this tool versus alternatives like task_add or task_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run build, test, and lint sequentially for a project. Auto-detects platform-specific commands. Side effects: executes up to 3 shell commands with 5-minute timeouts each. Returns per-gate results and an overall pass/fail status. Use this as a quality gate before committing or ending a session. Use verify_build or verify_test individually when you only need one check.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (must match a directory under apps/) | |
| stopOnFail | No | Abort remaining gates on first failure (default: false — runs all gates) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility. It discloses side effects (executes shell commands with timeouts), auto-detection of platform commands, and return format (per-gate results and overall status). It does not explicitly state no file modification, but the context is sufficient.
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, front-loaded with the main action, each sentence adds unique value, and there is no unnecessary text.
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's simplicity (2 params, none nested, no output schema), the description covers what it does, side effects, return values, and usage guidance, leaving no gaps for an agent.
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, and the description does not add new information beyond what the schema provides for each parameter. Therefore the baseline 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 that the tool runs build, test, and lint sequentially, and explicitly distinguishes itself from sibling tools verify_build and verify_test by advising when to use them individually.
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 tells when to use this tool ('as a quality gate before committing or ending a session') and explicitly provides alternatives ('Use verify_build or verify_test individually when you only need one check').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the project's build command (auto-detected per platform: "pnpm build" for Web, "flutter build" for Flutter, "./gradlew assembleDebug" for Android). Side effects: executes a shell command in the project directory with a 5-minute timeout. Returns {success, output} with the last 1000 chars of stdout/stderr. Use verify_all to run build + test + lint together.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (must match a directory under apps/) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects (executes shell command), constraints (5-minute timeout), and return format (success, output with last 1000 chars). No annotations provided; description carries full burden.
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 sentences, each serving a clear purpose: purpose, behavior, and alternative. Slightly verbose but 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?
Cover all necessary aspects: auto-detection, side effects, timeout, return format, and related tool. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add new meaning beyond the schema's description of the 'project' parameter.
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 it runs the build command, auto-detected per platform, and distinguishes from sibling tool verify_all.
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?
Gives clear alternative (verify_all for combined build+test+lint) and implies when to use this tool for build-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the project's test suite (auto-detected per platform: "pnpm test:run" for Web, "flutter test" for Flutter, "./gradlew test" for Android). Optionally scope to a specific test file or directory. Side effects: executes a shell command with a 5-minute timeout. Returns {success, output}. Use verify_all to run build + test + lint together.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (must match a directory under apps/) | |
| testPath | No | Specific test file or directory to run (optional — runs all tests if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects (shell command execution, 5-minute timeout) and return shape, though could note permission or file system 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?
Three concise sentences with no redundancy, front-loaded with the main action and key details.
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 multi-platform, timeout, return format, and alternative tool, making it self-contained for an agent.
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 that testPath is optional and defaults to all tests, and that project must match a directory under apps/.
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 runs the project's test suite with platform-specific commands, and distinguishes itself from siblings like verify_all and verify_build.
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 advises when to use verify_all instead for combined build+test+lint, and implies scoping via testPath parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.13.1graph_connect4 fields changedInput schema / properties / relation / descriptionPrevious value: -"관계 유형: related_to(관련), causes(원인), solves(해결), depends_on(의존), contradicts(상충), extends(확장), example_of(예시)"New value: +"Edge type: related_to (general association), causes (A causes B), solves (A fixes B), depends_on (A requires B), contradicts (A conflicts with B), extends (A builds on B), example_of (A demonstrates B)"Input schema / properties / sourceId / descriptionPrevious value: -"출발 메모리 ID"New value: +"Source memory ID (the \"from\" node)"Input schema / properties / strength / descriptionPrevious value: -"관계 강도 0-1 (기본: 1.0)"New value: +"Connection strength 0.0-1.0 (default: 1.0). Lower values indicate weaker associations."Input schema / properties / targetId / descriptionPrevious value: -"도착 메모리 ID"New value: +"Target memory ID (the \"to\" node)"graph_explore4 fields changedInput schema / properties / depth / descriptionPrevious value: -"탐색 깊이 (기본: 2, 최대: 4)"New value: +"Maximum traversal depth 1-4 (default: 2). Higher values return more results but may be slower."Input schema / properties / direction / descriptionPrevious value: -"탐색 방향 (기본: both)"New value: +"Traversal direction — outgoing (A→B), incoming (B→A), or both (default: \"both\")"Input schema / properties / memoryId / descriptionPrevious value: -"시작 메모리 ID"New value: +"Starting memory ID for graph traversal"Input schema / properties / relation / descriptionPrevious value: -"관계 유형 필터 (기본: all)"New value: +"Filter by relation type (default: \"all\")"memory_get1 field changedInput schema / properties / ids / descriptionPrevious value: -"조회할 메모리 ID 배열 (최대 20개)"New value: +"Array of memory IDs to retrieve (max 20)"memory_related4 fields changedInput schema / properties / includeGraph / descriptionPrevious value: -"지식 그래프 관계 포함 (기본: true)"New value: +"Include knowledge graph connections (default: true)"Input schema / properties / includeSemantic / descriptionPrevious value: -"시맨틱 유사 메모리 포함 (기본: true)"New value: +"Include semantically similar memories via embeddings (default: true)"Input schema / properties / limit / descriptionPrevious value: -"결과 개수 (기본: 10)"New value: +"Max results to return (default: 10)"Input schema / properties / memoryId / descriptionPrevious value: -"기준 메모리 ID"New value: +"The anchor memory ID to find relations for"memory_search8 fields changedInput schema / properties / detail / descriptionPrevious value: -"true면 전체 content, false면 요약 인덱스만 (기본: false)"New value: +"Return full content per memory (default: false — returns compact index only)"Input schema / properties / limit / descriptionPrevious value: -"결과 개수 (기본: 10)"New value: +"Max results to return (default: 10)"Input schema / properties / minImportance / descriptionPrevious value: -"최소 중요도 (기본: 1)"New value: +"Minimum importance threshold 1-10 (default: 1)"Input schema / properties / project / descriptionPrevious value: -"프로젝트 필터 (선택)"New value: +"Filter by project (optional)"Input schema / properties / query / descriptionPrevious value: -"검색어 (자연어)"New value: +"Natural language search query"Input schema / properties / semantic / descriptionPrevious value: -"시맨틱 검색 사용 (기본: false, 임베딩 기반)"New value: +"Use embedding-based semantic search instead of keyword FTS5 (default: false)"Input schema / properties / tags / descriptionPrevious value: -"태그 필터 (선택)"New value: +"Filter by tags — matches if any tag is present (optional)"Input schema / properties / type / descriptionPrevious value: -"메모리 타입 필터 (기본: all)"New value: +"Filter by memory type (default: \"all\")"memory_stats1 field changedInput schema / properties / project / descriptionPrevious value: -"특정 프로젝트만 (선택)"New value: +"Scope statistics to a single project (optional — omit for global stats)"memory_store6 fields changedInput schema / properties / content / descriptionPrevious value: -"저장할 내용"New value: +"The knowledge content to store"Input schema / properties / importance / descriptionPrevious value: -"중요도 1-10 (기본: 5)"New value: +"Importance score 1-10 where 10 is critical (default: 5)"Input schema / properties / project / descriptionPrevious value: -"관련 프로젝트 (선택)"New value: +"Associated project name (optional — omit for cross-project knowledge)"Input schema / properties / relatedTo / descriptionPrevious value: -"연결할 기존 메모리 ID (선택)"New value: +"ID of an existing memory to link via knowledge graph (optional)"Input schema / properties / tags / descriptionPrevious value: -"태그 (검색용)"New value: +"Tags for filtering (e.g. [\"auth\", \"performance\"])"Input schema / properties / type / descriptionPrevious value: -"메모리 타입: observation(발견), decision(결정), learning(학습), error(에러), pattern(패턴)"New value: +"Memory type: observation (discovery/finding), decision (architecture/tech choice), learning (new knowledge), error (error encountered), pattern (code convention)"project_analyze1 field changedInput schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (must match a directory under apps/)"project_init3 fields changedInput schema / properties / description / descriptionPrevious value: -"프로젝트 설명"New value: +"Human-readable project description"Input schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (must match a directory under apps/)"Input schema / properties / techStack / descriptionPrevious value: -"기술 스택 (자동 감지 가능)"New value: +"Tech stack override {framework, language, database, ...}. Omit for auto-detection."project_status1 field changedInput schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (must match a directory under apps/)"search_sessions3 fields changedInput schema / properties / limit / descriptionPrevious value: -"결과 개수 (기본: 5)"New value: +"Max results to return (default: 5)"Input schema / properties / project / descriptionPrevious value: -"프로젝트 (선택)"New value: +"Filter by project (optional)"Input schema / properties / query / descriptionPrevious value: -"검색어"New value: +"Natural language search query"session_end6 fields changedInput schema / properties / blockers / descriptionPrevious value: -"막힌 것/이슈"New value: +"Current blockers or issues (null if none)"Input schema / properties / modifiedFiles / descriptionPrevious value: -"수정한 파일"New value: +"Files modified during this session"Input schema / properties / nextSteps / descriptionPrevious value: -"다음 할 일"New value: +"Ordered list of next tasks to pick up"Input schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (must match a directory under apps/)"Input schema / properties / summary / descriptionPrevious value: -"이번 세션 요약 (1-2줄)"New value: +"One-line summary of this session"Input schema / properties / workDone / descriptionPrevious value: -"완료한 작업"New value: +"Description of completed work"session_history3 fields changedInput schema / properties / days / descriptionPrevious value: -"최근 N일 (기본: 7)"New value: +"Only return sessions from the last N days (default: 7)"Input schema / properties / limit / descriptionPrevious value: -"조회 개수 (기본: 5)"New value: +"Max records to return (default: 5)"Input schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (must match a directory under apps/)"session_start2 fields changedInput schema / properties / compact / descriptionPrevious value: -"간결한 포맷 (기본: true)"New value: +"Return compressed format (default: true). Set false for verbose output."Input schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (must match a directory under apps/)"solution_find4 fields changedInput schema / properties / limit / descriptionPrevious value: -"결과 개수 (기본: 3)"New value: +"Max results to return (default: 3)"Input schema / properties / project / descriptionPrevious value: -"프로젝트 (선택)"New value: +"Filter by project (optional — also includes cross-project solutions)"Input schema / properties / query / descriptionPrevious value: -"에러 메시지 또는 키워드"New value: +"Error message, signature, or natural language description of the problem"Input schema / properties / semantic / descriptionPrevious value: -"시맨틱 검색 사용 (기본: false, 임베딩 기반)"New value: +"Enable semantic/embedding search for fuzzy matching (default: false)"solution_record5 fields changedInput schema / properties / errorMessage / descriptionPrevious value: -"전체 에러 메시지"New value: +"Full error message or stack trace (optional)"Input schema / properties / errorSignature / descriptionPrevious value: -"에러 패턴/시그니처 (검색 키)"New value: +"Error pattern/signature used as the search key (e.g. \"ENOENT: no such file\", \"WorkManager not initialized\")"Input schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (optional — omit for cross-project solutions)"Input schema / properties / relatedFiles / descriptionPrevious value: -"관련 파일"New value: +"Files that were modified to fix the error"Input schema / properties / solution / descriptionPrevious value: -"해결 방법"New value: +"Step-by-step fix description"solution_suggest2 fields changedInput schema / properties / errorMessage / descriptionPrevious value: -"현재 에러 메시지"New value: +"The current error message or stack trace"Input schema / properties / project / descriptionPrevious value: -"프로젝트"New value: +"Project name for context (optional)"task_add5 fields changedInput schema / properties / description / descriptionPrevious value: -"상세 설명"New value: +"Detailed description (optional)"Input schema / properties / priority / descriptionPrevious value: -"우선순위 1-10 (기본: 5)"New value: +"Priority 1-10 where 10 is highest (default: 5)"Input schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (must match a directory under apps/)"Input schema / properties / relatedFiles / descriptionPrevious value: -"관련 파일"New value: +"Associated file paths (optional)"Input schema / properties / title / descriptionPrevious value: -"태스크 제목"New value: +"Task title (concise, actionable)"task_list2 fields changedInput schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (must match a directory under apps/)"Input schema / properties / status / descriptionPrevious value: -"필터 (기본: pending)"New value: +"Status filter (default: \"pending\")"task_suggest2 fields changedInput schema / properties / path / descriptionPrevious value: -"특정 경로만 분석 (선택)"New value: +"Subdirectory path to limit the scan (optional, e.g. \"src/components\")"Input schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (must match a directory under apps/)"task_update3 fields changedInput schema / properties / note / descriptionPrevious value: -"메모 (완료 시 결과 등)"New value: +"Optional note (e.g. completion summary or block reason)"Input schema / properties / status / descriptionPrevious value: -"새 상태"New value: +"New status"Input schema / properties / taskId / descriptionPrevious value: -"태스크 ID"New value: +"Task ID (from task_add or task_list)"verify_all2 fields changedInput schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (must match a directory under apps/)"Input schema / properties / stopOnFail / descriptionPrevious value: -"실패 시 중단 (기본: false)"New value: +"Abort remaining gates on first failure (default: false — runs all gates)"verify_build1 field changedInput schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (must match a directory under apps/)"verify_test2 fields changedInput schema / properties / project / descriptionPrevious value: -"프로젝트 이름"New value: +"Project name (must match a directory under apps/)"Input schema / properties / testPath / descriptionPrevious value: -"특정 테스트 파일/폴더 (선택)"New value: +"Specific test file or directory to run (optional — runs all tests if omitted)"v1.13.0graph_connectgraph_explorelist_projectsmemory_getmemory_relatedmemory_searchmemory_statsmemory_storeproject_analyzeproject_initproject_statussearch_sessionssession_endsession_historysession_startsolution_findsolution_recordsolution_suggesttask_addtask_listtask_suggesttask_updateverify_allverify_buildverify_testMost tools have distinct purposes, but there is some overlap that could cause confusion. For example, memory_related and graph_explore both traverse the knowledge graph, though their descriptions clarify differences in approach. Similarly, search_sessions and session_history both retrieve past sessions, with one focusing on semantic search and the other on chronological listing, which might lead to misselection if not carefully read.
Tool names follow a highly consistent verb_noun pattern throughout, such as memory_search, project_init, and verify_all. All names use snake_case uniformly, with clear and descriptive verbs that align with their functions, making the set predictable and easy to navigate.
With 25 tools, the count feels heavy for the server's purpose of session continuity and project management. While the tools cover various aspects like memory handling, project tasks, and verification, the number may overwhelm agents, leading to inefficiency or confusion in tool selection, despite the broad scope.
The tool set provides comprehensive coverage for the domain, including CRUD operations for memories, projects, tasks, and solutions, along with session management and verification workflows. There are no obvious gaps; each tool supports a complete lifecycle, ensuring agents can handle end-to-end processes without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Shared memory for coding agents. Stop re-explaining your codebase every session.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/leesgit/passbaton'
If you have feedback or need assistance with the MCP directory API, please join our Discord server