Hippocampal Memory MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
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 Consistency2/5
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.
Tool Count4/5
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.
Completeness3/5
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.
Average 3.7/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hippocampal-memory-mcp MCP server](https://glama.ai/mcp/servers/harbz07/hippocampal-memory-mcp/badges/card.svg)](https://glama.ai/mcp/servers/harbz07/hippocampal-memory-mcp)

Score Badge

Copy to your README.md:

[![hippocampal-memory-mcp MCP server](https://glama.ai/mcp/servers/harbz07/hippocampal-memory-mcp/badges/score.svg)](https://glama.ai/mcp/servers/harbz07/hippocampal-memory-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/harbz07/hippocampal-memory-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server