io.github.asklokesh/loki-mode
Autonomous spec-to-product coding-agent CLI with an MCP server exposing 34 tools over stdio.
Versions
7.34.1latestTools 36
loki_project_status Get the current project status including RARV cycle state, agent activity, and task progress. Returns: JSON with project status, phase, iteration, agents, and task counts
loki_agent_metrics Get agent metrics including token usage, task completion rates, and timing. Returns: JSON with per-agent metrics and aggregates
loki_checkpoint_restore List available checkpoints or restore project state from a specific checkpoint. Args: checkpoint_id: ID of checkpoint to restore (empty = list all) Returns: JSON with available checkpoints or restoration result
loki_quality_report Get quality gate results including blind review scores, council verdicts, and test coverage. Returns: JSON with quality gate status, review results, and coverage metrics
loki_memory_retrieve Retrieve relevant memories for a task using task-aware retrieval. Args: query: Search query describing what you're looking for task_type: Type of task (exploration, implementation, debugging, review, refactoring) top_k: Maximum number of results to return Returns: JSON array of relevant memory entries with summaries
loki_memory_store_pattern Store a new semantic pattern learned during this session. Args: pattern: Brief description of the pattern category: Category (api, testing, security, performance, architecture, etc.) correct_approach: The correct way to handle this situation incorrect_approach: What to avoid (optional) confidence: Confidence level 0.0-1.0 Returns: Pattern ID if successful
loki_task_queue_list List all tasks in the Loki Mode task queue. Returns: JSON array of tasks with status, priority, and description
loki_task_queue_add Add a new task to the Loki Mode task queue. Args: title: Brief task title description: Detailed task description priority: Priority level (low, medium, high, critical) phase: SDLC phase (discovery, architecture, development, testing, deployment) Returns: Task ID if successful
loki_task_queue_update Update a task's status or priority. Args: task_id: ID of the task to update status: New status (pending, in_progress, completed, blocked) priority: New priority (low, medium, high, critical) Returns: Updated task if successful
loki_state_get Get the current Loki Mode state including phase, metrics, and status. Returns: JSON object with current state information
loki_metrics_efficiency Get efficiency metrics for the current session. Returns: JSON object with token usage, tool calls, and efficiency ratios
loki_memory_capture_session_summary v7.7.18 capture wedge: store an episode for the current agent session. Call this voluntarily at iteration close (or session end) to write a structured Episode into the project's .loki/memory/ store. Solves the diagnosis root cause where memory only captured during `loki start` sessions, missing all interactive Claude Code / Cursor / Cline / Aider work. Args: goal: Short description of what the session tried to accomplish (will be truncated to 500 chars, scrubbed for secrets). outcome: One of "success" | "failure" | "partial". Default "success". files_modified: List of file paths that were created or edited. files_read: List of file paths that were read for context. tool_calls_summary: Optional free-text summary of major actions taken (truncated to 1000 chars, scrubbed). duration_seconds: Approximate session duration. Default 0. Returns: JSON: {"episode_path": "<path>"} on success, or {"error": "...", "disabled": true} if LOKI_MEMORY_CAPTURE_DISABLED env var blocks capture, or {"error": "..."} on failure.
loki_consolidate_memory Run memory consolidation to extract patterns from recent episodes. Args: since_hours: Process episodes from the last N hours Returns: Consolidation results with patterns created/merged
loki_complete_task Declare that the current PRD / task is complete. Replaces the legacy 'COMPLETION PROMISE FULFILLED: ...' prose string with a structured tool call. The orchestrator (run.sh) detects this via a signal file and stops the iteration loop gracefully. Args: completion_statement: A short statement of what is complete (for example, "PRD requirements implemented, all tests passing, checklist 100%"). evidence: Concrete evidence supporting the claim -- tests that passed, checklist items verified, files created/modified, metrics hit. confidence: One of 'high', 'medium', 'low' (default 'medium'). 'low' signals the orchestrator should still run the completion council. Returns: JSON: {"recorded": true, "path": ".loki/events.jsonl"} on success, {"error": "..."} otherwise.
loki_start_project Start a new Loki Mode project from a PRD. Args: prd_content: Inline PRD content (takes priority over prd_path) prd_path: Path to a PRD file on disk Returns: JSON with project initialization status
loki_code_search Search the loki-mode codebase semantically. Finds functions, classes, and code sections by meaning, not just keywords. Returns file paths, line numbers, and code snippets ranked by relevance. Args: query: Natural language search query (e.g., "rate limit detection", "model selection for RARV tier", "how does the council vote") n_results: Number of results to return (default 10, max 30) language: Filter by language: "shell", "python", "markdown" (optional) file_filter: Filter by file path substring (e.g., "autonomy/", "dashboard/") (optional) type_filter: Filter by chunk type: "function", "class", "header", "section", "file" (optional)
loki_code_search_stats Get statistics about the code search index. Shows total chunks, files indexed, breakdown by language and type. Useful for verifying the index is up to date.
mem_search Search memory using full-text search (FTS5). Fast keyword search across all memory types. Supports AND, OR, NOT operators and prefix matching (e.g. "debug*"). Args: query: Search query (plain text or FTS5 syntax) collection: Which memories to search (episodes, patterns, skills, all) limit: Maximum results to return Returns: JSON array of matching memories with relevance scores
mem_timeline Get chronological context from memory timeline. Shows recent actions, key decisions, and episode traces in time order. Use around_id to get context surrounding a specific memory entry. Args: around_id: Optional memory ID to center the timeline around limit: Maximum timeline entries to return since_hours: Only show entries from the last N hours (default 24) Returns: JSON timeline with actions and decisions
mem_get Fetch full details for one or more memory entries by ID. Use after mem_search to get complete data for specific results. Args: ids: Comma-separated list of memory IDs to fetch Returns: JSON object with full memory details keyed by ID
loki_get_hotspots Get the most frequently changed files in the repository. Identifies code hotspots based on git commit frequency analysis. These files deserve extra care during changes (higher risk of regressions). Args: limit: Number of top hotspot files to return (default 10, max 30)
loki_get_co_changes Find files that frequently change together with a given file. Uses git co-change analysis to identify coupling between files. Useful for understanding hidden dependencies and ensuring related files are updated together. Args: file_path: Path to the file to find co-change partners for
loki_get_doc_coverage Get documentation coverage status for the project. Reads from the docs manifest to report which files are documented, which have stale documentation, and which are missing docs entirely. Useful for prioritizing documentation work.
loki_findings Read structured code-review findings for a given iteration. Args: iteration: iteration number (default -1 = most recent). Returns: JSON {iteration, review_id, findings: [...]}.
loki_learnings Read recent learnings (newest first) from relevant-learnings.json.
loki_graph_query Answer a codebase question from a knowledge graph instead of reading files. WHY THIS EXISTS Loading a large repo into context is the dominant token cost of working on it, and on a big codebase it is simply impossible. Measured on this repo: `autonomy/` alone is 85 files / 3,194,940 bytes, roughly 798,735 tokens if naively read. No context window holds that. MEASURED on this repo, same question, same subtree: naive file load 101,739 bytes ~= 25,434 tokens graph query 3,335 bytes ~= 833 tokens A ~30x reduction, and the answer arrives with exact file:line citations plus a provenance label on every edge (EXTRACTED / INFERRED / AMBIGUOUS) -- the same facts-vs-inference split the Evidence Receipt uses, which is why it composes cleanly with the rest of this server. This is the brownfield unlock: a ten-year-old enterprise repo is unreachable by reading, and reachable by querying. REQUIRES a graph built by graphify (`graphify <path>`), which is deterministic AST parsing with no LLM and no network. If no graph exists this returns a structured hint rather than silently degrading to a guess. Args: question: natural-language question about the codebase budget: cap the answer at roughly this many tokens (default 1500) path: repo root containing graphify-out/ (default: current directory) Returns: JSON: {ok, answer, tokens_estimate, budget, source} or {ok:false, hint}
lsp_workspace_symbols Fuzzy-search symbols across the entire workspace. Use when an agent is hunting for the right name (knows the function/class is about "config loading" but isn't sure of the actual identifier). Returns LSP workspace/symbol results scoped to the detected language (or the language override). Args: query: Symbol query (substring or fuzzy per LSP server impl). limit: Max results to return (default 20, hard cap 100). language: Optional language override. Returns: JSON: {"matches": [...], "count": N, "language": "...", "elapsed_ms": float}.
loki_verify_fast Verify code deterministically in milliseconds. No model call, no network. This is the embeddable verification primitive: an IDE, another agent, a CI step, or a third-party tool can call it and get a structured verdict back faster than a keystroke round-trip. MEASURED on loki-mode itself (1,932 tracked source files): full repo, cold 298 ms full repo, warm 87 ms diff-scoped 19 ms against an 11,040 ms shell-based baseline. The speedup came from architecture, not micro-optimization: walk the tree ONCE via the git index, run every detector as a pure function in ONE process, and cache findings by file CONTENT hash so an unchanged file is never re-read. WHY THERE IS NO LLM HERE, AND WHY THAT IS THE POINT Everything this returns is reproducible by anyone with the same commit. A verdict you can re-derive is a FACT; a verdict a model produced is an OPINION. Keeping this path purely deterministic is what makes it both fast and safe to embed in someone else's product -- they do not have to trust our model choices, only our arithmetic. Args: path: repository or directory to verify (default: current directory) diff_base: optional git ref. When given, only files changed against it are verified, which is the normal case for a pull request and the fastest path. Returns: JSON: verdict (PASS | FAIL | INCONCLUSIVE), findings[] with rule/path/line/message/severity, files_scanned, files_from_cache, elapsed_ms, and exogenous=true.
loki_counter_evidence_template Generate a counter-evidence file template for the given iteration. Pre-fills canonical findingId for each Critical/High finding so the user only has to fill in `claim` + `proofType`. Save the template body to .loki/state/counter-evidence-<iteration>.json to dispute findings via the override council.
loki_memory_redact Redact memory versions in the managed-agents store whose content matches a regex. Iterates memory versions within the requested scope and calls ``client.beta.memory_stores.memory_versions.redact(...)`` for each match. Requires ``LOKI_MANAGED_AGENTS=true`` and ``LOKI_MANAGED_MEMORY=true`` -- otherwise raises ``ManagedDisabled``. Args: pattern: Python regex compiled with ``re.search`` against each version's content. scope: One of ``user``, ``org``, or ``all`` (default). Returns: JSON ``{"redacted_count": int, "errors": [...], "scanned": int}``.
lsp_find_references Find references to the symbol at the given file / line / character. Args: file: Absolute or cwd-relative path to the source file. line: 0-indexed line number (LSP convention). character: 0-indexed character offset within the line. include_declaration: If True, include the symbol declaration in results. Returns: JSON-encoded string. Success: {"result": [...], "language": ...}. Error: {"error": "..."}.
lsp_go_to_definition Resolve the definition location for the symbol at file / line / character. Args: file: Absolute or cwd-relative path to the source file. line: 0-indexed line number. character: 0-indexed character offset within the line. Returns: JSON-encoded string with `result` (LSP Location | Location[] | LocationLink[]) on success or `error` on failure.
lsp_symbol_at_position Return the hover / symbol info at the given file / line / character. Uses LSP `textDocument/hover` which returns a `MarkupContent` plus an optional range. Args: file: Absolute or cwd-relative path to the source file. line: 0-indexed line number. character: 0-indexed character offset within the line. Returns: JSON-encoded string with `result` (LSP Hover) on success or `error` on failure.
lsp_check_exists Cheap existence check for a symbol in the current workspace. The single most useful grounding primitive: an agent about to write `flightApi.getStatus()` should call `lsp_check_exists("getStatus")` first. If false, it means LSP could not find that name anywhere in the workspace; the agent should resolve via find / grep / read before writing the call. Args: symbol: Symbol name to look for (substring match per LSP spec). kind: Optional filter: 'function', 'class', 'method', 'variable', etc. If provided, only symbols whose LSP SymbolKind matches are counted. language: Optional language override. If None, auto-detected from workspace markers (package.json, requirements.txt, etc.). Returns: JSON-encoded string: {"exists": bool, "matches": N, "samples": [...], "language": "...", "elapsed_ms": float}. On no-LSP-available: {"error": "...", "exists": null}.
lsp_get_diagnostics Return current LSP diagnostics (errors + warnings) for a file. Diagnostics are published asynchronously by LSP servers via `textDocument/publishDiagnostics`. This tool opens the file (if not already open, or re-syncs it via didChange if edited since first open) and waits up to 1 second for diagnostics to arrive, then returns whatever has been published. Args: file: Absolute or cwd-relative path to the source file. Returns: JSON: {"diagnostics": [{severity, message, range, source}, ...], "count_errors": N, "count_warnings": M, "language": "...", "elapsed_ms": float}.
lsp_find_definition_by_name Find where a named symbol is defined, without needing a file position upfront. Convenience wrapper: runs workspace/symbol then returns the first result's location. Args: symbol: Symbol name to find. language: Optional language override. Returns: JSON: {"location": {uri, range} | null, "name": str | null, "language": "...", "elapsed_ms": float}.
Permissions 5
network medium filesystem low shell high database medium env_vars low