Loading ToolBench
Local project memory for AI coding agents: durable context, SQLite, MCP, Codex skill, embeddings, and autonomous maintenance.
dukememory exposes 19 tools with complete JSON schemas and descriptions, but exhibits significant quality gaps. All tools have descriptions (10-150 chars, mostly adequate) and input schemas with typed parameters. However, naming is inconsistent (memory_* prefix is repetitive; no clear verb-noun distinction), parameter descriptions lack actionable constraints (no enums, ranges, or format specs), and output schemas are undocumented. Error handling is absent from tool definitions. The server targets a specialized domain (project memory management) but lacks the polish expected of production tools. Composition is reasonable (each tool has a single responsibility), but parameter design forces agents to reason about optional fields and configuration paths rather than providing sensible defaults.
Add a typed memory card
Return agent-native context with planner directives and memory state
Automatically ingest session logs and transcripts into memory
Return a tiny verified task brief
Choose the smallest useful memory budget for a task
Return a compact relevant memory pack
Run diagnostics and maintenance on memory database before long sessions
All 19 tools use memory_* prefix, creating naming monotony. Verbs are buried (brief, impact, search, add, remember). LLMs struggle to distinguish intent when names are repetitive. Recommend: rename to action-first (brief_memory, search_memory, add_memory) or use domain-specific verbs (retrieve_brief, analyze_impact, ingest_transcript).
Parameters lack actionable constraints. 'scope' appears in 15+ tools with description 'Memory scope filter' but no enum of valid values (global, user, project, repo, thread, task). 'provider' and 'model' parameters accept free-form strings with no guidance on valid options. LLMs will hallucinate invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Query and update active project decisions and constraints
Detect cheap local memory drift before coding as bounded summary by default
Return provenance and evidence for a memory or query result
Perform a Deep Dive explanation of a specific memory component using its neighbors
Record lightweight useful/useless/missing feedback for memory reads
Answer a question using 1-hop graph-expanded RAG via LLM generation
Generate a pedagogical guided tour of the project memory via LLM generation
Return lightweight impact memory for a file, symbol, or topic
Generate a comprehensive Onboarding Guide from the knowledge graph
Answer a question using grounded project memory via LLM generation
Remember plain text as local memory
Search local memory with compact query-focused summaries
Output schemas are not documented in tool definitions. Agents cannot predict what fields to expect (e.g., does memory_search return [id, title, body, score] or [id, title, relevance_score, snippet]?). This forces agents to guess and wastes tokens on error recovery.
Numeric parameters (limit, budget, max_chars) lack min/max bounds. 'limit' could be 1 or 1,000,000; 'budget' could be 0 or unbounded. Agents will pass absurd values. Add constraints: limit 1 - 100, budget 100 - 100000, max_chars 100 - 10000.
Duplicate/alternative parameters (root vs project_root, db path) appear in all 19 tools. This creates ambiguity: which takes precedence? Should agents pass both? Consolidate to a single canonical parameter or document mutual exclusivity and precedence rules.