A cognitive memory system that helps the model remember and reason about past interactions
mcp-brain has three tools with complete input schemas and basic descriptions, but falls significantly short of production quality. Tool names follow verb-noun conventions (read_graph, create_entities, create_relations), which is positive. However, parameter descriptions are entirely absent, none of the 6 input parameters across the three tools have descriptions explaining what they control or what formats are expected. Tool descriptions are generic and lack specificity about when to use each tool or what downstream dependencies exist. The schema for create_entities and create_relations are well-formed with proper type hierarchies, but the complete lack of parameter-level documentation violates critical pattern requirements. Output schemas are not documented anywhere. Error handling is minimal, no recovery guidance, no error categorization, no validation of the entity_type or relation_type enums. The entities array in create_entities accepts arbitrary strings for entity_type and relation_type with no enum constraint, inviting hallucinated values from LLMs. No idempotency hints provided for write operations, making retries risky. The read_graph tool takes no parameters but its output schema is undocumented, the LLM has no way to know what structure it returns. Security is concerning: there are no permission checks or audit trails, and the Supabase credentials are loaded from environment variables but the tool definitions include no mention of what data access they grant.
Store new memories as entities in the brain's knowledge graph
Create connections between memories in the brain's knowledge graph
Read the brain's entire memory graph to recall past interactions and knowledge
All input parameters completely lack descriptions. The 'entities' parameter in create_entities and 'relations' parameter in create_relations are not explained, LLMs cannot infer what format, semantics, or constraints apply. The nested 'name', 'entity_type', 'observations', 'from', 'to', 'relation_type' fields are also undescribed.
Output schemas are completely undocumented. read_graph has no description of what fields it returns or how to extract entity/relation data. create_entities and create_relations do not document success responses, what IDs or references are returned for chaining?
entity_type and relation_type fields accept arbitrary strings with no enum constraint. LLMs will hallucinate invalid type names. A constrained enum (e.g. 'person', 'organization', 'event', 'knows', 'works_for') would prevent invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Write operations (create_entities, create_relations) provide no idempotency guarantees or hints. If an LLM retries a failed create_entities call, will duplicate entities be created? No idempotent hint is declared, and the implementation does not appear to use upsert-style semantics.
No error handling guidance. If create_entities fails, the response has no actionable recovery instructions. If an entity 'name' is a duplicate, the error does not suggest using read_graph first to check. Errors must guide the LLM to the next step.
Tool descriptions are generic. 'Store new memories as entities' does not explain when to use create_entities vs create_relations, what structure the knowledge graph enforces, or why observations are an array. Descriptions should answer: what, when, and why.
read_graph has no limit or pagination parameters despite reading 'entire memory graph'. If the knowledge graph grows large, returning all entities and relations will exhaust context and break reasoning. Should support limit/offset or result streaming.
No permission checks or scope declarations. Tools accept connections to any Supabase project and read/write any entity or relation without verifying agent authority. Should gate destructive operations and declare required permissions.