Provides tools for storing and querying episodic memories, relationships, and graph structures using Neo4j, including Cypher read/write operations and bond evolution tracking.
Uses OpenAI embeddings for semantic vector search to retrieve memories based on similarity, enabling pattern completion and context-aware recall.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Hippocampal Memory MCP Encode a memory about our project kickoff meeting"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for neuroanatomically-inspired memory consolidation using Neo4j and semantic search.
Episodic Memory Encoding: Create memory events with emotional valence and temporal context
Semantic Retrieval: Vector similarity search using OpenAI embeddings
Graph Operations: Full Cypher query support for reading and writing
Relationship Tracking: Monitor bond strength evolution over time
Extensible Schema: Additional tools in hippocampus-extension.mjs ready for integration
Related MCP server: RAG Memory MCP
See CHECKLIST.md for daily startup instructions.
npm installYou need Neo4j Desktop running locally with a database on port 7687.
npm run setup-schemaStart ngrok to expose your local Neo4j:
ngrok tcp 7687Copy the tunnel URL (e.g., tcp://2.tcp.us-cal-1.ngrok.io:12841)
Edit %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"hippocampal-memory": {
"command": "node",
"args": ["C:\\Users\\harve\\Neo4j\\hippocampal-mcp-server.mjs"],
"env": {
"NEO4J_URI": "bolt://YOUR_NGROK_URL",
"NEO4J_USER": "neo4j",
"NEO4J_PASSWORD": "your_password",
"OPENAI_API_KEY": "your_openai_key"
}
}
}
}The MCP server will connect automatically.
hippocampus_write_event - Structured event creation with Who/Why/What/Where/Effects blocks
hippocampus_write_reflection - Agent-relative memory slices with egocentric perspective
hippocampus_search_events - Pattern completion retrieval with temporal/participant/effect filters
encode_memory - Save episodic memories with vector embeddings
recall_memory - Semantic + temporal + emotional search
query_graph - Read-only Cypher queries
mutate_graph - Write operations (CREATE, MERGE, etc.)
evolve_bond - Track relationship dynamics over time
Current Setup:
Neo4j Desktop running locally on port 7687
ngrok tunnel for remote access
Claude Desktop connects via stdio transport
Render deployment at https://hippocampal-memory-mcp.onrender.com (HTTP/SSE transport)
Files:
hippocampal-mcp-server.mjs - Main server (stdio for Claude Desktop)
remote-mcp-server.mjs - HTTP/SSE server (for remote connections)
hippocampus-extension.mjs - Additional biomimetic tools
setup-vector-index.mjs - Schema initialization
test-connection.mjs - Local connection test
test-tunnel.mjs - Tunnel connection test
Core Nodes:
Event - Episodic memories with vector embeddings
Person - Human and AI entities
Project - Ongoing work
Concept - Abstract ideas
Place, Catalyst, Entity, Target, Effect, Reflection, Agent (extension schema)
Key Relationships:
INVOLVES - Event → Entity (with role & salience)
PRECEDED - Event → Event (causal chains)
CONSOLIDATED_TO - Event → Concept/Person/Project
BOND - Person ↔ Person (with strength trajectory)
PARTICIPATED_IN, CATALYZED_BY, HELD_AT, HAD_EFFECT_ON, etc. (extension schema)
Indexes:
Vector index on Event.embedding (1536 dimensions, cosine similarity)
Unique constraints on id fields for Person, Project, Concept, Event
ngrok URL changes on every restart (unless you pay for static URL)
Update NEO4J_URI in Claude Desktop config when ngrok URL changes
Neo4j Desktop must be running before starting Claude Desktop
Environment variables are in Claude Desktop config (NOT .env file)
Render deployment requires persistent Neo4j (Aura) - local tunnel won't work
Test local connection:
node test-connection.mjsTest tunnel connection:
node test-tunnel.mjsCHECKLIST.md - Daily startup and tool addition guide
neo4j-agent.instructions.md - Comprehensive Neo4j/Cypher/GraphQL guide
docs/ - Archived setup guides and deployment notes
Currently deployed to Render at: https://hippocampal-memory-mcp.onrender.com
For deployment details, see archived docs.
Create episodic memory event with emotional valence, temporal context, and entity involvement. Automatically generates embeddings for semantic retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | ||
| involves | No | Entities involved in this event | |
| precedes | No | IDs of events this causally follows | |
| consolidates_to | No | Memory consolidation paths |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses mutation via 'Create' and the automatic embedding generation, which is useful. However, it does not mention permissions, reversibility, side effects on existing data, or the return format, leaving gaps for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The most important information (create event + embeddings) is front-loaded, and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, consolidation paths, causal links), the description is minimal but covers the core function. The rich schema fills in many details, but the description does not explain the purpose of fields like 'precedes' or 'consolidates_to' in a broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (75%), so the baseline is 3. The description's mention of 'emotional valence, temporal context, and entity involvement' maps to schema fields but adds no new detail beyond existing property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Create' with a clear resource ('episodic memory event') and highlights key attributes (emotional valence, temporal context, entity involvement). It also distinguishes from siblings by mentioning automatic embedding generation, which is a unique feature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or discussion of alternatives. The description implies use for storing episodic memories that need embeddings, but lacks exclusions or comparison with sibling tools like hippocampus_write_event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update bond strength between entities and track relationship trajectory over time. Automatically records milestones and calculates momentum.
| Name | Required | Description | Default |
|---|---|---|---|
| milestone | No | Description of what just happened | |
| new_strength | Yes | Updated bond strength | |
| to_entity_id | Yes | Target entity ID (typically Person) | |
| from_entity_id | Yes | Source entity ID (typically Person) | |
| emotional_resonance | No | Emotional quality of the bond | |
| interaction_context | No | Context of this bond evolution |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses useful behavioral traits: automatically records milestones and calculates momentum, and tracks trajectory over time. However, it does not disclose whether the update is destructive, whether permissions are required, or what the return value looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no filler words. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description leaves important gaps: no indication of what the tool returns, whether it is a destructive mutation, how 'momentum' is defined, or how to choose between this and mutate_graph. With no annotations and no output schema, the description is not fully contextualized for a 6-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a clear description. The description's mention of 'bond strength' and 'entities' aligns with the required parameters but adds no new semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates bond strength between entities and tracks relationship trajectory, using a specific verb ('Update') and resource ('bond strength'). It distinguishes itself from siblings like mutate_graph and hippocampus_write_event by focusing on relationship evolution and metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when updating bond strength), but it does not explicitly reference alternatives or exclusions. It doesn't mention sibling tools like mutate_graph or clarify when not to use this tool, so the agent must infer the intended scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve events using pattern completion. Supports semantic search, temporal filters, participant filters, and effect filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return | |
| place | No | Filter by location | |
| entities | No | Filter by entity IDs involved | |
| effects_on | No | Filter for events with effects on specific target | |
| time_range | No | Filter by temporal range (optional) | |
| participants | No | Filter by participant IDs (Person/Agent names) | |
| semantic_query | No | Natural language query for semantic search (optional) | |
| min_effect_intensity | No | Minimum emotional intensity threshold |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'pattern completion' as the underlying mechanism, which is extra context beyond the schema, but doesn't disclose behaviors like pagination, ordering, response format, or any caveats. The description is not misleading but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and lists supported filter categories efficiently. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no output schema and no annotations, the description is relatively brief. It doesn't explain what 'pattern completion' means, how results are ordered, or any constraints beyond parameter schema. It covers the basics but lacks deeper context for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description groups filters (semantic, temporal, participant, effect) which mirrors the schema but doesn't add new meaning or syntax details. It provides minimal added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve events using pattern completion' with the specific verb 'retrieve' and resource 'events'. It distinguishes from sibling write tools but doesn't explicitly differentiate from recall_memory or query_graph, though the name strongly implies event-specific searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving events with various filters, but it doesn't explicitly state when to use this tool over alternatives like recall_memory or query_graph. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an episodic Event with Who/Why/What/Where/Effects blocks. Mimics hippocampal CA3 pattern separation and binding.
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining side effects and runtime behavior. It only offers a biological metaphor ('Mimics hippocampal CA3 pattern separation and binding') without disclosing whether the write is persistent, idempotent, requires authentication, or how it affects retrievability via sibling search tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with the primary action front-loaded. No redundant phrasing or unnecessary detail. The second sentence adds a short analogy without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested schema, no output schema, and no annotations. The description does not mention persistence, side effects, or the expected response format. It is too terse to fully prepare an agent for correct invocation, though the schema compensates partially.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description groups parameters conceptually (Who/Why/What/Where/Effects), which maps to some schema properties. However, it omits many fields (id, description, title, happened_at) and does not explain that the 'event' parameter is a required nested object. The input schema has detailed descriptions, so the baseline is 3, but the description only partially compensates for the 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create') and resource ('episodic Event') with a structured format (Who/Why/What/Where/Effects blocks). This clearly distinguishes it from sibling tools like hippocampus_write_reflection and hippocampus_search_events, which target different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or situations where another tool (e.g., hippocampus_write_reflection) would be more appropriate. The intended use is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create agent-relative Reflection about an event. Mimics prefrontal cortex self-referential processing with egocentric perspective.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ID of the agent creating the reflection | |
| event_id | Yes | ID of the event being reflected upon | |
| reflection | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must disclose behavioral traits. It gives a metaphorical analogy (prefrontal cortex) but does not specify operational effects such as whether the event must exist, whether reflections are overwritten, or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, but the second sentence's metaphorical framing ('prefrontal cortex...') adds little operational value. Still, it is short and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool requires a nested object and all parameters are required, yet there is no output schema or annotations. The description does not explain how reflections relate to events or the broader memory system, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters, adding no meaning beyond the input schema. With schema coverage at 67%, the description could have clarified event_id or reflection structure but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Create agent-relative Reflection about an event,' providing a specific verb (Create) and resource (agent-relative Reflection). The 'egocentric perspective' phrasing distinguishes it from hippocampus_write_event, which likely records objective event details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The description implies usage when creating a reflection about an event but does not contrast with siblings like hippocampus_write_event or encode_memory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute arbitrary Cypher write operations for creating/updating nodes, relationships, and properties. Use for operations beyond specialized tools.
| Name | Required | Description | Default |
|---|---|---|---|
| cypher | Yes | Cypher query to execute (write operations) | |
| params | No | Parameterized query values |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavioral traits. It states 'arbitrary Cypher write operations' which implies a high-risk, unrestricted mutation capability, and mentions creating/updating. However, it does not disclose potential side effects, reversibility, permission requirements, or validation behavior, leaving the agent to infer these from Cypher knowledge. This is a moderate disclosure, better than a generic description but still lacking security context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action ('Execute arbitrary Cypher write operations') and immediately followed by usage guidance. Every phrase earns its place, with no redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an arbitrary execution tool with no output schema, the description adequately conveys purpose and usage boundaries (beyond specialized tools). However, it omits details about error handling, transactionality, and safety pitfalls of running arbitrary Cypher. Given the tool's complexity and potential impact, this is a minor gap, but the description is still sufficient for an agent to select it correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters (cypher and params) with exact descriptions, achieving 100% schema description coverage. The tool description adds no additional parameter-level context beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes arbitrary Cypher write operations for creating/updating nodes, relationships, and properties. This is a specific verb+resource couple (execute Cypher writes) and explicitly distinguishes itself from specialized tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs use for 'operations beyond specialized tools,' providing clear when-to-use guidance and implicitly naming alternatives (the specialized sibling tools). This tells the agent to prefer specialized tools when available and fall back on this only for arbitrary/untracked write operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute read-only Cypher queries for complex data retrieval. Use for custom queries, analytics, and exploring the graph structure.
| Name | Required | Description | Default |
|---|---|---|---|
| cypher | Yes | Cypher query to execute (read-only) | |
| params | No | Parameterized query values |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses read-only behavior and intended use cases, but lacks details on permissions, error handling, result format, or query constraints. This gives some behavioral context but not comprehensive disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, then usage. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no annotations), the description covers purpose and usage well. However, with sibling search tools like hippocampus_search_events, an explicit alternative statement would improve completeness. Overall, it is nearly complete but misses direct sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of the two parameters (cypher and params) with descriptions. The tool description does not add additional parameter semantics beyond the schema's read-only note, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes read-only Cypher queries for complex data retrieval, and specifies use cases (custom queries, analytics, exploring graph structure). It distinguishes from siblings by emphasizing read-only and custom query capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use ('Use for custom queries, analytics, and exploring the graph structure'), and explicitly says read-only. However, it does not name alternatives or explicitly exclude predefined search tools, so guidance is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve memories using semantic similarity, emotional valence, temporal range, or entity involvement. Returns ranked results combining vector similarity with Cypher filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results | |
| query | No | Natural language query for semantic search | |
| event_types | No | Filter by event types | |
| temporal_range | No | Filter by timestamp [start, end] in ISO 8601 format | |
| emotional_range | No | Filter by emotional valence [min, max] between -1.0 and 1.0 | |
| involves_entities | No | Filter by entity involvement (Person/Project/Concept IDs) | |
| include_consolidations | No | Include consolidation targets in results | |
| significance_threshold | No | Minimum significance level |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the non-mutating nature via 'Retrieve' and explicitly states the return behavior: 'Returns ranked results combining vector similarity with Cypher filters.' This is sufficient for a query-only tool, though it does not mention errors or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no filler, with the primary verb and resource front-loaded. It efficiently lists all key filtering dimensions and the output behavior in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description covers the main input dimensions and indicates the ranked-result output. It does not detail the exact result shape or disambiguate from hippocampus_search_events, but the complete parameter schema compensates for most omitted details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds meaningful context by mapping parameters to retrieval concepts: query to semantic similarity, emotional_range to emotional valence, temporal_range to temporal range, and involves_entities to entity involvement. It also explains that these filters combine with vector similarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('Retrieve memories') and specifies distinct retrieval dimensions (semantic similarity, emotional valence, temporal range, entity involvement). This differentiates it from sibling tools like hippocampus_search_events by focusing on memory recall with hybrid vector + Cypher filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternative search tools such as hippocampus_search_events. The usage context is implied by the retrieval-focused description, but there are no stated exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0encode_memoryevolve_bondhippocampus_search_eventshippocampus_write_eventhippocampus_write_reflectionmutate_graphquery_graphrecall_memoryScored across 8 tools
There is significant overlap between hippocampus_write_event and encode_memory, both creating episodic memory events with similar semantics. Similarly, hippocampus_search_events and recall_memory both retrieve memories with overlapping filters, making it unclear which tool to select. The distinction between generic graph operations (mutate_graph/query_graph) and specialized tools adds further ambiguity.
Naming mixes a hippocampus_ prefix on three tools (write_event, write_reflection, search_events) with plain verb_noun names on the rest (encode_memory, recall_memory, mutate_graph, evolve_bond, query_graph). While the verbs are fairly descriptive, the inconsistent prefix and overlapping vocabulary (write vs encode, search vs recall) break a predictable pattern.
Eight tools is a reasonable count for a memory and knowledge graph server. However, the presence of redundant event creation and retrieval tools means the count is slightly padded; the true functional set is smaller. Still, the overall number is appropriate for the domain.
The server covers creation (events, reflections), retrieval (search, recall), relationship manipulation (evolve_bond), and custom graph operations (mutate_graph, query_graph). However, there are no dedicated tools for updating or deleting memories, and mutating via raw Cypher is an indirect workaround. Notable gaps exist for lifecycle management of memories.
Graph-native persistent memory for AI agents — 33 MCP tools, zero-LLM writes.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Shared cross-LLM long-term memory over MCP: semantic recall, sessions, and media (pgvector).
Cloud-hosted MCP server for durable AI memory
