Evidence-first enterprise memory lifecycle for AI infrastructure — preserves, audits, and retrieves operational knowledge for agents. Exposes memory search, timeline, causal chain, working memory, and lifecycle management tools over the Model Context Protocol using FastMCP's stdio transport.
BrainCore defines 25 tools with schemas and descriptions present, but quality is inconsistent. Naming follows verb_noun convention (memory-search, lifecycle-event-enqueue) which is good. However, descriptions are often generic and lack actionable context for LLM selection. Parameter descriptions exist but are minimal (10-30 chars typical). No output schemas are documented, critical for agents planning downstream calls. Error handling guidance is absent. Tools like memory-search and memory-timeline have reasonable descriptions (80-120 chars), but many others (memory-session-list-active, lifecycle-stats) lack specificity. Parameter constraints (enums, ranges, formats) are largely absent, e.g., 'status' in lifecycle-event-list accepts 'pending, completed, failed' but this is not formalized as an enum. No evidence of idempotency hints, permission gates, or recovery guidance. The server appears to be a working prototype but lacks production-grade polish.
Record an audit entry for context recall operations
Enqueue a lifecycle event for asynchronous processing
List pending and completed lifecycle events
Retry a failed lifecycle event
Backfill intelligence metadata for existing memory objects
Retrieve lifecycle processing statistics and queue status
Retrieve event frames before and after a given timestamp with optional subject and scope filtering
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., does memory-search return memory_id, timestamp, relevance_score?). This violates pattern:tool and pattern:response-shaper.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Retrieve causal episodes and their constituent event frames ordered by causality
Retrieve remediation steps that failed for a given query and scope
Record user feedback on memory object quality and relevance
Set the lifecycle status of a memory object (active, archived, deleted, etc.)
Retrieve the next recommended step in a procedure given a query and scope
Hybrid retrieval across full-text search, vector embeddings, structured metadata, and graph paths with optional reranking and path explanations
Search for procedure steps matching a query with scope isolation
Search for visual memory artifacts (diagrams, screenshots, images) with optional scope filtering
Close an active task session and finalize working memory
List all active task sessions
Create a new task session for working memory tracking
Update an active task session with new working memory entries
Temporal point-in-time query returning event frames ordered by timestamp with optional scope and event-type filtering
Retrieve previously attempted steps for a given procedure query and scope
Add an entry to the working memory buffer for the current session
Remove expired entries from the working memory buffer
List all entries in the working memory buffer for a session
Mark a working memory entry as a candidate for promotion to long-term memory
Parameter descriptions are minimal (10-30 chars) and lack actionable constraints. E.g., 'status' in lifecycle-event-list says 'Filter by status (pending, completed, failed)' but does not formalize as enum. No ranges for numeric params (limit, max_age_seconds). Violates pattern:constrained-input.
No error handling guidance. Tools do not document what errors are retryable, user-fixable, or fatal. No recovery suggestions (e.g., 'If session not found, call memory-session-list-active first'). Violates pattern:recovery-guide.
Destructive/write tools lack confirmation or dry-run support. memory-session-close, memory-lifecycle-status-set, and lifecycle-event-retry modify state without documented safeguards. Violates pattern:confirmation-request.
Tool descriptions lack context for LLM selection. Many are under 60 chars and do not explain WHEN to use the tool vs similar ones. E.g., memory-next-step vs memory-what-did-we-try are semantically close but descriptions do not clarify the distinction. Violates pattern:tool-description.