hebbian-mind-enterprise

Name: hebbian-mind-enterprise
Author: For-Sunny

by For-Sunny

Overview Schema Related Servers Score Discussions

Python

Hybrid

Hebbian Mind Enterprise

Memory that learns. Connections that fade.

An MCP server that builds knowledge graphs through use. Concepts connect when they activate together. Unused connections decay. The more you use it, the smarter it gets.

What It Does

Associative Memory - Save content. Query content. Related concepts surface automatically.
Hebbian Learning - Edges strengthen through co-activation. No manual linking required.
Concept Nodes - 100+ pre-defined enterprise concepts across Systems, Security, Data, Operations, and more.
MCP Native - Works with Claude Desktop, Claude Code, any MCP-compatible client.

Related MCP server: Lorekeeper

Installation

Three paths. Pick what fits.

Windows (Native)

# Clone the repo
git clone https://github.com/For-Sunny/hebbian-mind-enterprise.git
cd hebbian-mind-enterprise

# Install with pip
pip install -e .

# Verify
python -m hebbian_mind.server

The server runs on stdio. Press Ctrl+C to stop.

Linux / macOS (Native)

# Clone the repo
git clone https://github.com/For-Sunny/hebbian-mind-enterprise.git
cd hebbian-mind-enterprise

# Install with pip (use a virtual environment if you prefer)
pip install -e .

# Verify
python -m hebbian_mind.server

Linux gets automatic RAM disk support via /dev/shm when enabled.

Docker (Teams / Enterprise)

# Clone the repo
git clone https://github.com/For-Sunny/hebbian-mind-enterprise.git
cd hebbian-mind-enterprise

# Copy environment template
cp .env.example .env

# Build and start
docker-compose up -d

# View logs
docker-compose logs -f hebbian-mind

For RAM disk optimization:

docker-compose --profile ramdisk up -d

Claude Desktop Integration

Add to your claude_desktop_config.json:

Native Install:

{
  "mcpServers": {
    "hebbian-mind": {
      "command": "python",
      "args": ["-m", "hebbian_mind.server"]
    }
  }
}

Docker Install:

{
  "mcpServers": {
    "hebbian-mind": {
      "command": "docker",
      "args": ["exec", "-i", "hebbian-mind", "python", "-m", "hebbian_mind.server"]
    }
  }
}

Restart Claude Desktop. The tools appear automatically.

Configuration

Environment variables control behavior. Set them before running, or use .env with Docker.

Core Settings

Variable	Default	Description
`HEBBIAN_MIND_BASE_DIR`	`./hebbian_mind_data`	Data storage location
`HEBBIAN_MIND_RAM_DISK`	`false`	Enable RAM disk for faster reads
`HEBBIAN_MIND_RAM_DIR`	`/dev/shm/hebbian_mind` (Linux)	RAM disk path

Hebbian Learning

Variable	Default	Description
`HEBBIAN_MIND_THRESHOLD`	`0.3`	Activation threshold (0.0-1.0)
`HEBBIAN_MIND_MAX_WEIGHT`	`10.0`	Maximum edge weight cap

Deprecated: HEBBIAN_MIND_EDGE_FACTOR is no longer used. The asymptotic learning formula (LEARNING_RATE = 0.1) replaced the old harmonic strengthening factor. The env var still loads without error but has no effect on edge weights.

Optional Integrations

Variable	Default	Description
`HEBBIAN_MIND_FAISS_ENABLED`	`false`	Enable FAISS semantic search
`HEBBIAN_MIND_FAISS_HOST`	`localhost`	FAISS tether host
`HEBBIAN_MIND_FAISS_PORT`	`9998`	FAISS tether port
`HEBBIAN_MIND_PRECOG_ENABLED`	`false`	Enable PRECOG concept extraction

MCP Tools

Eight tools. All available through any MCP client.

save_to_mind

Store content with automatic concept activation and edge strengthening.

{
  "content": "Microservices architecture enables independent deployment",
  "summary": "Optional summary",
  "source": "ARCHITECTURE_DOCS",
  "importance": 0.8
}

Activates matching concept nodes. Strengthens edges between co-activated concepts.

query_mind

Query memories by concept nodes.

{
  "nodes": ["architecture", "deployment"],
  "limit": 20
}

Returns memories that activated those concepts.

analyze_content

Preview which concepts would activate without saving.

{
  "content": "API authentication using JWT tokens",
  "threshold": 0.3
}

Get concepts connected via Hebbian edges.

{
  "node": "security",
  "min_weight": 0.1
}

Returns the neighborhood graph - concepts that have fired together with "security".

list_nodes

List all concept nodes, optionally filtered.

{
  "category": "Security"
}

mind_status

Server health and statistics.

{}

Returns node count, edge count, memory count, strongest connections, dual-write status.

faiss_search

Semantic search via external FAISS tether (if enabled).

{
  "query": "authentication patterns",
  "top_k": 10
}

faiss_status

Check FAISS tether connection status.

Temporal Decay

Memories and edges both decay over time unless reinforced.

Memory decay: Same formula as CASCADE and PyTorch Memory. Memories lose effective importance over time. Accessed memories reset their clock. Immortal memories (importance >= 0.9) never decay.

Edge decay: Connections between concepts weaken if not co-activated. This is the inverse of Hebbian learning -- "neurons that stop firing together, stop wiring together." Edges decay toward a minimum weight (0.1), never to zero, preserving the structure of learned associations.

Decay Configuration

Variable	Default	Description
`HEBBIAN_MIND_DECAY_ENABLED`	`true`	Enable memory decay
`HEBBIAN_MIND_DECAY_BASE_RATE`	`0.01`	Base exponential decay rate
`HEBBIAN_MIND_DECAY_THRESHOLD`	`0.1`	Memories below this are hidden
`HEBBIAN_MIND_DECAY_IMMORTAL_THRESHOLD`	`0.9`	Memories at or above this never decay
`HEBBIAN_MIND_DECAY_SWEEP_INTERVAL`	`60`	Minutes between sweep cycles
`HEBBIAN_MIND_EDGE_DECAY_ENABLED`	`true`	Enable edge weight decay
`HEBBIAN_MIND_EDGE_DECAY_RATE`	`0.005`	Edge decay rate (slower than memory decay)
`HEBBIAN_MIND_EDGE_DECAY_MIN_WEIGHT`	`0.1`	Minimum edge weight floor

Decayed memories are hidden from query_mind by default. Pass include_decayed: true to retrieve them.

Architecture

Dual-Write Pattern

Write: Disk first (crash-safe) -> RAM second (speed)
Read: RAM (instant) with disk fallback
Startup: Copies disk to RAM if RAM is empty

Disk commits before RAM updates. If the RAM write fails, the data is already on disk -- the failure gets logged but nothing is lost. This order guarantees durability. A power loss mid-write never leaves you with RAM-only data that never reached disk.

RAM disk is optional. Without it, reads and writes go directly to SQLite on disk.

Concept Nodes

100+ pre-defined nodes across categories:

Systems & Architecture - service, api, component, integration
Security - authentication, authorization, encryption, access
Data & Memory - database, cache, persistence, schema
Logic & Reasoning - pattern, rule, validation, analysis
Operations - workflow, pipeline, monitoring, health
Quality - performance, reliability, scalability, test

Nodes have keywords and prototype phrases. Content activates nodes when keywords match.

Hebbian Learning

When concepts co-activate (appear in the same saved content):

Edge created if none exists (initial weight: 0.15)
Existing edges strengthen via asymptotic formula:

delta = (MAX_WEIGHT - current_weight) * LEARNING_RATE
new_weight = current_weight + delta

Each co-activation closes 10% of the gap between current weight and MAX_WEIGHT (10.0). An edge at 2.0 gains 0.8. An edge at 9.0 gains 0.1. Edges approach the ceiling but never hit it -- no saturation, no runaway weights.

Combined with time-based decay (idle edges lose 2% per tick) and homeostatic scaling (total edge weight per node stays near 50.0), the graph self-regulates. Active paths strengthen. Neglected paths fade. The topology stays meaningful.

"Neurons that fire together, wire together."

Troubleshooting

Server won't start

Check Python version (requires 3.10+):

python --version

Verify MCP SDK installed:

pip install mcp

No activations on save

Content must match node keywords above threshold. Lower the threshold:

export HEBBIAN_MIND_THRESHOLD=0.2

Or check what would activate:

{"tool": "analyze_content", "content": "your text here"}

Docker container won't connect

Ensure container is running:

docker ps | grep hebbian-mind

Check logs:

docker-compose logs hebbian-mind

High memory with RAM disk

Check node/edge counts via mind_status. Consider increasing HEBBIAN_MIND_THRESHOLD to activate fewer nodes, or lower HEBBIAN_MIND_MAX_WEIGHT to limit edge growth.

Performance

Metric	Value	Notes
Save latency	<10ms	Includes activation, Hebbian strengthening, and commit
Query latency	<5ms	Node lookup + JOIN + sort
RAM disk reads	<1ms	When `HEBBIAN_MIND_RAM_DISK=true`
Analyze latency	<1ms	Content analysis without save
Memory per node	~1KB	SQLite row with keywords and phrases
Memory per edge	~100 bytes	SQLite row with weight and timestamps
Startup (100 nodes)	<1 second	Schema creation + node loading + edge initialization

Reproducing Benchmarks

A benchmark script is included to verify these claims on your hardware:

python benchmarks/benchmark_performance.py

The script creates an isolated temp database, runs 200 iterations of each operation, and reports mean/median/P95/P99 latencies. Results are saved to benchmarks/latest_results.json with full system info for reproducibility.

Test conditions: Disk-only mode (no RAM disk), WAL journal mode, 20 enterprise nodes, single-threaded. RAM disk mode will produce faster read latencies.

Testing

# Install dev dependencies
pip install -e ".[dev]"

# Run tests
pytest

# Run with coverage
pytest --cov=hebbian_mind

Support

Documentation: cipscorps.io/docs/hebbian-mind
Email: support@cipscorps.io
Issues: GitHub Issues

License

MIT License. See LICENSE for terms.

Memory that learns. Concepts that connect. The more you use it, the smarter it gets.

Made by CIPS Corp

Website | Store | GitHub | glass@cipscorps.io

Enterprise cognitive infrastructure for AI systems: PyTorch Memory, Soul Matrix, CMM, and the full CIPS Stack.

Available Tools

8 tools

analyze_contentA

Analyze content against concept nodes without saving. Preview which concepts would activate.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	Content to analyze
`threshold`	No	Activation threshold 0-1 (default: configured threshold)

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that no saving occurs, which is helpful, but lacks other behavioral details such as whether content is stored temporarily, authorization requirements, or side effects.

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 brief sentences with no extraneous words, efficiently conveying purpose and key behavioral trait.

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 a low-complexity tool with no output schema, the description could be more complete by explaining what 'preview' means (e.g., returns list of node IDs) or providing usage context relative to siblings.

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% for both parameters; the description adds no additional meaning beyond the schema, so 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's action (analyze content against concept nodes) and the output (preview which concepts would activate), distinguishing it from siblings like save_to_mind (which saves) and query_mind (which queries).

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 dry-run usage with 'without saving' but does not explicitly state when to use this tool versus alternatives like save_to_mind or get_related_nodes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

faiss_searchB

Search external FAISS tether for semantic similarity search (if enabled).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query
`top_k`	No	Number of results (default: 10)

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states the tool performs semantic similarity search but does not disclose behavioral traits such as what happens when FAISS is disabled, whether it is read-only, or any performance implications.

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 a single sentence with no wasted words, conveying the core action and context efficiently.

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?

Despite having only 2 parameters and no output schema, the description omits essential details like the format of results (e.g., returns similar items with scores), prerequisites for enabling FAISS, or error handling. This leaves an agent underinformed.

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?

Input schema covers 100% of parameters with basic descriptions. The description adds no additional meaning beyond what the schema already provides, so 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 searches an external FAISS tether for semantic similarity search, with a conditional 'if enabled'. This verb-resource pair is specific and distinguishes it from siblings like faiss_status or get_related_nodes.

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?

The description only mentions 'if enabled' but provides no guidance on when to use this tool versus alternatives like get_related_nodes or query_mind. No explicit context or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

faiss_statusB

Check external FAISS tether status (if enabled).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It adds a single behavioral note ('if enabled') implying the tool may not work if FAISS is disabled, but lacks details on what happens in that case, permissions needed, or side effects.

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 a single sentence with no extraneous information, front-loading the essential action and condition.

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 no parameters, no output schema, and no annotations, the description is minimal but adequate for a simple status check. However, it lacks details on return format, what 'tether' means, and behavior when disabled.

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?

The tool has no parameters, so the input schema fully covers all semantics (none). Description is not required to add parameter meaning. Baseline for 0 parameters is 4.

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 the verb 'Check' and the resource 'external FAISS tether status', with a conditional note 'if enabled'. It differentiates from siblings like faiss_search (search operation) and mind_status (mind status).

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 guidance on when to use this tool versus alternatives. The only contextual hint is 'if enabled', but no explicit when-to-use or when-not-to-use instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_related_nodesB

Get nodes connected to a given node by Hebbian edges.

ParametersJSON Schema

Name	Required	Description	Default
`node`	Yes	Node name to find related nodes for
`min_weight`	No	Minimum edge weight (default: 0.1)

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It only states the basic function without mentioning read-only nature, permissions, or any side effects.

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 a single short sentence, front-loaded with the key information. However, it is extremely terse and could include a bit more context without being verbose.

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 is thin; it does not explain the return format or what 'related' means. With no output schema, the agent lacks information on what to expect.

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 clear descriptions for both parameters. The tool description does not add any additional meaning beyond what the schema already provides.

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 clearly states the verb 'get', resource 'nodes', and the specific relationship 'Hebbian edges', which distinguishes it from sibling tools like 'list_nodes' that lists all nodes.

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 fetching related nodes but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like 'faiss_search' for semantic similarity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_nodesB

List all concept nodes, optionally filtered by category.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Filter by category

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description is the sole source for behavioral traits. It fails to disclose limitations, pagination, error handling (e.g., invalid category), or performance implications.

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?

Description is short and front-loaded, with no redundant information. However, it could be more concise by removing the word 'all' if redundant, but overall efficient.

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 simplicity of the tool (one optional parameter, no output schema), the description covers the basic purpose. However, it lacks guidance on response format, error handling, and integration with sibling tools.

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%, and the description merely restates the filter functionality. No additional meaning or constraints beyond the schema are provided.

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 clearly states the action (list) and resource (concept nodes) with an optional filter by category. It distinguishes from sibling tools like get_related_nodes which imply relationships rather than listing all nodes.

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 guidance on when to use this tool over alternatives such as analyze_content or faiss_search. No conditions or exclusions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mind_statusA

Get Hebbian Mind health status including node count, edge count, memory count, and strongest connections.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It implies a read operation but does not explicitly state read-only nature, side effects, auth requirements, or rate limits. For a status tool, basic transparency is missing.

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?

Single sentence, no wasted words. Front-loaded with action and resource, clearly structured.

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 no parameters and no output schema, the description adequately summarizes the return. However, it could mention additional potential fields or format, but is sufficient for a simple status tool.

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 zero parameters, baseline is 4. The description adds value by listing output fields (node count, etc.), giving meaning beyond the empty schema. No param details needed.

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 verb 'Get' and resource 'Hebbian Mind health status', listing specific fields (node count, edge count, memory count, strongest connections). This distinguishes it from siblings like faiss_status (FAISS-specific) and list_nodes (node listing only).

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 guidance on when to use this tool versus alternatives such as faiss_status or get_related_nodes. The description solely states what it does, lacking context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_mindA

Query memories by concept nodes. Returns memories that activated specified concepts. Decayed memories are hidden by default.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results (default: 20)
`nodes`	No	List of node names to query
`include_decayed`	No	Include decayed memories below threshold (default: false)

TDQS

A3.5/5.0

Behavior3/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 behavioral disclosure. It mentions that decayed memories are hidden by default, which is a key behavioral trait. However, it does not disclose other important details such as the impact of querying, authentication requirements, or the format of returned data.

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, consisting of two sentences that directly convey the core functionality and a key behavioral detail. It is front-loaded and avoids unnecessary text, making it easy to parse. The brevity is appropriate given the tool's simplicity.

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 low complexity of the tool (3 parameters, no nested objects, no output schema), the description provides a sufficient overview. It explains the query logic and default filtering, which is enough for an agent to understand the basic operation. However, the lack of an output schema means the agent must infer the return format from the description, which is somewhat vague ('memories') but acceptable for a simple query.

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 describes all three parameters with 100% coverage. The description does not add new semantic information beyond what the schema provides; it only restates concepts like 'by concept nodes' and the default hiding of decayed memories. Thus, the description adds no additional 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 the tool's function: querying memories by concept nodes. It uses a specific verb-resource pair ('Query memories') and explains the mechanism ('by concept nodes'). However, it does not explicitly differentiate itself from sibling tools like faiss_search or get_related_nodes, which could lead to confusion.

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 the use case is retrieving memories related to specific concepts, but it offers no explicit guidance on when to use this tool over alternatives such as faiss_search or get_related_nodes. No exclusions or prerequisites are mentioned, leaving the agent to infer the appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

save_to_mindB

Save content to Hebbian Mind with automatic node activation and Hebbian edge strengthening.

ParametersJSON Schema

Name	Required	Description
`source`	No	Source identifier (default: HEBBIAN_MIND)
`content`	Yes	Content to save
`summary`	No	Optional summary
`importance`	No	Importance 0-1 (default: 0.5)
`emotional_intensity`	No	Emotional intensity 0-1 (default: 0.5)

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It mentions 'automatic node activation and Hebbian edge strengthening' but does not detail side effects, idempotency, permissions, or return behavior. This leaves significant gaps for an agent.

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?

Single sentence, 12 words, no fluff. Front-loaded with the action and resource. Every word earns its place.

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?

Given no output schema and no annotations, the description should explain what the tool returns (e.g., confirmation, node ID) and how the automatic activation works. It lacks completeness for a 5-parameter write 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 description coverage is 100%, so each parameter is documented. The description adds no additional parameter-specific meaning beyond the schema (e.g., format constraints, defaults). Baseline 3 applies.

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 uses specific verb 'save' and resource 'Hebbian Mind', clearly indicating it is a write operation. Distinguishes from sibling tools like query_mind and list_nodes which are read-oriented.

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 saving content to the mind, but provides no explicit guidance on when to use vs alternatives, when not to use, or prerequisites. Sibling tools suggest reading/querying, but the description does not clarify this distinction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: analyzing, searching, checking status, retrieving related nodes, listing, health query, memory query, and saving. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern, mostly verb_noun (e.g., analyze_content, list_nodes, query_mind). Even compound names like faiss_search are consistent in style.

Tool Count5/5

With 8 tools, the server is well-scoped for a knowledge management system. Each tool serves a core function without redundancy or excess.

Completeness4/5

The tool set covers key operations: preview, search, status, retrieval, listing, health, query, and save. Minor gaps exist such as missing explicit delete or update node tools, but the core workflows are covered.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

NeuralBrain
io.github.alexcurpan-cloud
NeuralBrain MCP Server - RAG, Vector Memory, LLM Routing, Agent Identity, x402 Payments
RAG Systems Vector Databases
2
Persis
io.github.alright-alright
Biological memory for AI agents. Pattern learning, decay, clustering, 8-drive behavior.
Knowledge & Memory Autonomous Agents Biology & Medicine
2
Brainbox
dev.thexi
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Knowledge & Memory AI & Machine Learning
2
Living Memory
to.viibe
An MCP memory server. One memory your agents share — across models, devices and apps.
Knowledge & Memory Autonomous Agents AI & Machine Learning
32

Related MCP Servers

CORTEX Memory MCP
Knowledge & Memory Vector Databases RAG Systems
alainrc2005
F
license
Not graded
quality
B
maintenance
Persistent semantic memory MCP server for AI agents with hybrid search, LLM scoring, and decay engine, fully local.
Updated 2 months ago (2026-07-09 23:48 UTC)
2
Lorekeeper
Autonomous Agents Knowledge & Memory RAG Systems
Jessinra
A
license
A
quality
A
maintenance
MCP memory server for AI agents that gets better with use
Updated a month ago (2026-08-03 13:20 UTC)
10
4
Apache 2.0
Hippocampal Memory MCP
Knowledge & Memory Databases Vector Databases
harbz07
F
license
B
quality
D
maintenance
An MCP server for neuroanatomically-inspired memory consolidation using Neo4j and semantic search, enabling episodic memory encoding, semantic retrieval, and graph operations.
Updated 8 months ago (2026-01-03 20:52 UTC)
8
1
Long-Term Memory
Knowledge & Memory RAG Systems
ihwooMil
A
license
Not graded
quality
D
maintenance
A persistent, self-organizing memory MCP server for AI assistants, using semantic search, knowledge graphs, and reinforcement learning to automatically manage and retrieve memories.
Updated 6 months ago (2026-03-03 11:54 UTC)
MIT

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/For-Sunny/hebbian-mind-enterprise'

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