Loading ToolBench
daimon-memory cross-tool surface: streamable-HTTP /mcp + versioned REST /v1 over the deterministic engine. MCP-over-HTTP (JSON-RPC 2.0) surface for daimon-memory with deterministic hybrid recall (full-text + semantic vectors, RRF-fused, no LLM).
daimon-mcp presents a well-structured memory system with thoughtful tool naming (verb-noun convention), comprehensive parameter schemas, and clear descriptions that articulate the 'when' and 'why' of each tool. All 9 tools have explicit, detailed descriptions (median ~150 chars) and properly typed JSON Schema inputs. The server follows strong composition principles: each tool has one responsibility, output enables tool-chaining (via URIs and structured fields), and error handling includes recovery guidance. However, several tools lack output schema documentation (critical for LLM planning), some parameter descriptions could be more prescriptive about constraints, and a few patterns (idempotency, batch operations) are underdeveloped. The architecture, deterministic, LLM-free, validation-focused, is production-grade, but the MCP definitions themselves have room for refinement to fully match A-tier quality.
Persist a dated FOLLOW-UP / next-session item.
List memory uris under a namespace prefix. Use before saving to avoid duplicates, or to explore what exists.
Retract a memory by uri (marks it forgotten). user/ and session/ records forget freely; durable agent/ and resources/ records require confirm=true.
Persist a non-obvious DECISION (chose A over B). State what was rejected. Call the moment a real choice is made.
Persist an INCIDENT / failure (regression, rollback, outage, data loss, wasted effort). No blame. Ask the user before logging if unsure.
Persist a reusable LESSON or a corrected mistake. Call immediately when corrected or when you learn something not to repeat.
Output schemas not documented. While input schemas are comprehensive and well-typed, the response structures for all 9 tools lack explicit schema documentation. LLMs cannot plan downstream tool calls or know which fields are returned (e.g., does 'recall' return 'uri', 'score', 'abstract'? what fields does 'read' return?). This violates pattern:response-shaper and forces agents to infer structure from descriptions alone.
Parameter descriptions lack prescriptive constraints. Many parameters (e.g., 'kind' enum values in 'remember', 'query' in 'recall', 'due' date format in 'add_reminder') document the semantic purpose but do not state format rules, length limits, or regex patterns explicitly in the description text. LLMs cannot reliably parse JSON Schema 'enum' or 'pattern' fields, they need human-readable constraint descriptions. E.g., 'kind' should say '(one of: decision, runbook, incident_summary, ...; case-sensitive)'.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 81 | 2026-07-28+ | v2 |
Fetch a memory's full content by its daimon:// uri.
Deterministic hybrid recall (full-text + semantic vectors, RRF-fused, no LLM). Returns ranked hits with scores, abstract + uri.
Store a typed memory. The control layer validates the schema; recall is deterministic.
Missing idempotency declarations and retry guidance. 'remember', 'log_decision', 'log_lesson', 'log_incident', and 'add_reminder' are WRITE operations but do not state whether they are idempotent or how agents should handle retries. If an agent retries a 'remember' call due to a transient network error, will it create a duplicate memory or overwrite the existing one? This ambiguity violates pattern:idempotent-operation.
'forget' tool lacks pre-execution confirmation pattern. The tool description notes 'confirm=true' is required for durable records but does not recommend a dry-run or explicit pre-deletion review. Agents may pass 'confirm=true' and delete agent/ or resources/ memories without user confirmation. Pattern:confirmation-request recommends supporting a two-step delete (preview what will be removed, then confirm deletion).
Error response guidance incomplete. Descriptions state that tools return 'ranked hits', 'full content', or similar, but do not specify what happens on errors. E.g., what does 'recall' return if the database is unavailable? What error code? What recovery action should the agent take? Missing error classification (retryable vs. user-fixable vs. fatal) per pattern:error-classification.
No batch operations. Tools like 'add_reminder' and 'log_incident' operate on single items. If an agent needs to log 5 lessons or create 5 reminders, it must call the tool 5 times, wasting tokens and latency. Pattern:tool recommends batch variants (e.g., 'add_reminders' accepting an array) for tools agents call in loops.