Loading ToolBench
Persistent memory for AI coding tools — code graph indexing, memory storage, and context injection for Claude Code and other AI editors
Muninn has 21 tools with significant structural gaps. Most tools lack complete input schemas visible in source (only tool names and descriptions provided; no explicit JSON Schema definitions found in code). Descriptions vary widely: some are adequate (search: 'Search memory entries'), others are vague or overly technical (graph: no description visible; ask: 'Ask the Curator a question' lacks context on when/why). Parameter descriptions exist but schemas are inferred rather than explicitly defined in the codebase. No output schemas documented. Error handling is minimal, no recovery guidance or error categorization visible. Tool composition is reasonable (single responsibilities mostly respected), but naming could be clearer (e.g., 'mcp_muninn' is not verb-noun; 'save_ack' is cryptic). Security concerns: no visible secret injection pattern, no permission gates, no audit trail declarations.
Show the latest architecture summary for a project
Ask the Curator a question about a project
Run the memory-quality benchmark against a project
Print the memory context packet (SessionStart hook payload)
Crawl a project directory
Enqueue raw PostToolUse payload onto the observation queue for later summarization by `runar summarize`. Runs on every Edit/Write/Bash hook (not rule-filtered like `extract`). Dedup + 30-sec SHA256 window
Export memory entries as JSONL (one JSON object per line). Filter by project and/or type. Writes to stdout or --output file
Passive extraction — parse tool output from PostToolUse hook stdin and auto-save detected insights (bug fixes, decisions, config changes). Gated behind RUNAR_PASSIVE_LEARNING=true
Input schemas not explicitly visible in source code. Tool definitions appear to be inferred from CLI argument parsing rather than explicit MCP tool registration with JSON Schema. This violates the pattern:tool requirement for documented input schemas.
Cryptic tool names reduce discoverability. 'save_ack', 'nudge', 'hint', 'mcp_muninn' do not follow verb_noun convention and do not clearly convey intent. LLMs will struggle to select these tools without extensive description reading.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | <=2025-11-25 | v2 |
Query the symbol-level code graph built by `runar crawl --deep`
PreToolUse hook (Grep/Glob): name definitions matching the search
Initialize RunarForge configuration
Start Muninn MCP server (stdio transport)
Nudge Claude Code to save if idle (UserPromptSubmit hook stub)
Produce a multi-section onboarding report for a project
Save a memory entry directly from the CLI
Acknowledge a muninn_save call (PostToolUse hook stub)
Search memory entries
Configure an AI tool to use RunarForge
Show memory system stats (all namespaces by default)
SessionEnd hook: claim pending observations for this project, call the summarizer (Claude Haiku if `ANTHROPIC_API_KEY` is set, otherwise deterministic heuristic), write synthesized entries via `propose`, close the active session with a structured summary, and confirm the queue items. Best-effort — never fails the hook
Show tech-debt markers found by the crawler
Output schemas not documented. No visible documentation of what search(), graph(), ask(), or other tools return. LLMs cannot plan downstream tool calls or extract required fields without knowing response structure.
Minimal error handling guidance. No visible error categorization (retryable vs user-fixable vs fatal), no recovery suggestions, no actionable error messages. Agents will not know how to respond to failures.
No visible permission gates or audit trail declarations. Destructive tools (crawl, init, setup, save, extract, enqueue, summarize) lack permission checks and do not declare required scopes. No logging of who called what, when, or with what parameters.