How do I use mindcore-memory-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mindcore-memory-mcp Remember that my favorite color is blue." 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.

mindcore-memory-mcp

by woshilaohei

Overview Schema Related Servers Score Discussions

Python

Hybrid

Production-Hardened MCP Memory Server — Hybrid Search + Resilience for AI Agents

The only MCP memory server with circuit breaker, SLO tracking, and BM25+FAISS hybrid search. AI agents forget everything between sessions. MindCore Memory gives them persistent, searchable, production-grade memory — with 118/118 tests passing and full CI/CD.

⭐ If this project helps your AI remember, a star means the world to us.

PyPI version Python License: MIT Downloads MCP Registry GitHub stars

Quick Start

# 1. Install
pip install mindcore-memory

# 2. Launch (stdio mode — works with any MCP client)
mindcore-memory

# 3. Your AI agent remembers across sessions

{
  "mcpServers": {
    "mindcore-memory": {
      "command": "python",
      "args": ["-m", "mindcore_memory.server"],
      "env": { "MINDCORE_MEMORY_PATH": "~/.mindcore/memory" }
    }
  }
}

pip install mindcore-memory[semantic]
# Enables FAISS embeddings for hybrid BM25+semantic search

Related MCP server: Synapse Memory

Why MindCore — vs the Competition

Feature	MindCore Memory	Mem0	SynaBun	Letta (MemGPT)
Search	BM25 + FAISS Hybrid	FAISS only	sqlite-vec only	FAISS only
Circuit Breaker	✅ 3-state	❌	❌	❌
Retry (exp. backoff)	✅	❌	❌	❌
SLO Tracking	✅ P95/P99	❌	❌	❌
Prometheus Metrics	✅ `/metrics`	❌	❌	❌
Encryption at Rest	✅ Fernet	❌	❌	❌
Deduplication	✅ Exact-match merge	⚠️ Partial	❌	❌
IVF Index (500+)	✅ Auto-switch	❌	❌	❌
Local-First	✅ Zero deps	✅ (cloud optional)	✅	❌ (needs Docker)
CI/CD Pipeline	✅ Auto → PyPI + MCP	⚠️ Manual	❌	❌
Tests	118/118 (100%)	Unknown	Unknown	Unknown
License	MIT	Apache 2.0	Apache 2.0	Apache 2.0

MindCore is the only MCP memory server designed for production workloads from day one. Circuit breaker protects against embedding service failures. Retry with exponential backoff handles transient errors. SLO tracking alerts you before users notice. Metrics export for your monitoring stack. Every other server assumes nothing fails — MindCore doesn't.

Unique: 3D Boundary Balance Algorithm

MindCore is not just a memory store — it's a cognitive boundary engine. Every stored memory is automatically evaluated through a 4-dimensional scoring system based on the 正反公式 (Forward/Reverse Formula):

BND_score = 0.28·TRJ(Trajectory) + 0.28·EVO(Evolution) + 0.28·COG(Cognition) + 0.16·BALANCE

Forward cycle: TRJ → BND → EVO → COG → BND (each step draws a boundary, each boundary is growth)
Reverse chain: Chaos → Unknown → Risk → Harm → Death (2+ linked triggers → auto 50% score penalty)
3D balance: Variance across TRJ/EVO/COG penalizes lopsided memories (pure data dumps without insight)
No LLM calls: Pure algorithmic evaluation using keyword patterns, regex, and statistical variance

from mindcore_memory import BNDManager
bnd = BNDManager()
result = bnd.evaluate("基于之前修复, 理解到根因, 改进后提升30%", importance=4)
# → TRJ:0.63  EVO:0.54  COG:0.61  BALANCE:0.98  BND:0.75  ACCEPTED

📖 Full algorithm documentation

No other MCP memory server does this. BND transforms memory storage from a passive data dump into an active cognitive filter — rejecting noise, flagging risk chains, and ensuring only structured, growth-oriented knowledge enters the version chain.

Production Features

Resilience Layer

Circuit Breaker: CLOSED → OPEN → HALF_OPEN state machine. Protects FAISS/embedding operations from cascading failure.
Retry: Exponential backoff with jitter. Transient errors retry automatically, permanent errors fail fast.
Input Validation: Server-level sanitization against injection attacks.

Observability Layer

SLO Tracking: P95/P99 latency targets for all 6 operations. Violations logged and exported.
Prometheus /metrics: Zero-dependency Prometheus-compatible collector. Drop-in for any monitoring stack.

Data Layer

Encryption: Optional Fernet encryption at rest (mindcore-memory[encrypt]).
Deduplication: Exact-match merge — identical memory updates importance/confidence instead of storing duplicates.
Smart Eviction: Low-importance memory pruning with atomic disk sync. No zombie memories.

Core Tools

Memory (6 tools)

Tool	Description	Key Parameters
`memory_store`	Persist a memory (auto-BND evaluated)	`content`, `importance` (1-4), `tags`, `confidence`
`memory_recall`	Search memories (BM25+FAISS hybrid)	`query`, `tags`, `limit`, `session_id`
`memory_context`	Build LLM context window	`query`, `max_tokens`, `session_id`
`memory_update_confidence`	Adjust memory confidence	`memory_id`, `confidence`
`memory_delete`	Remove a memory	`memory_id`
`memory_stats`	System statistics	(no args)

Boundary & Deduction (3 tools) 🆕

Tool	Description	Key Parameters
`bnd_check`	4D boundary evaluation (TRJ/EVO/COG/BALANCE + Anti-Chain)	`content`, `importance`, `confidence`, `tags`
`bnd_stats`	BND manager stats: acceptance rate, scores, anti-chain triggers	(no args)
`deduce`	Cognitive deduction: pattern extraction from high-quality memories	`query`, `tags`

Search formula: score = BM25(40%) + FAISS(50%) + importance(5%) + recency(5%)

When FAISS embeddings are unavailable, automatically falls back to BM25-only keyword search.

Architecture

┌───────────────────┐     MCP JSON-RPC      ┌────────────────────────────┐
│  AI Client         │ ◄──────────────────► │  MindCore Memory           │
│  (Claude/Cursor)   │     stdio / HTTP     │  MCP Server                │
└───────────────────┘                       └──────────┬─────────────────┘
                                                       │
                                            ┌──────────▼─────────────────┐
                                            │  Memory Engine             │
                                            │  ┌──────────────────────┐  │
                                            │  │ Hybrid Search        │  │
                                            │  │  BM25 (keyword) 40%  │  │
                                            │  │  FAISS (semantic)50%│  │
                                            │  │  importance        5%│  │
                                            │  │  recency           5%│  │
                                            │  └──────────────────────┘  │
                                            │  ┌──────────────────────┐  │
                                            │  │ Resilience           │  │
                                            │  │  Circuit Breaker     │  │
                                            │  │  Retry + Backoff     │  │
                                            │  │  SLO Tracking        │  │
                                            │  └──────────────────────┘  │
                                            └──────────┬─────────────────┘
                                                       │
                                            ┌──────────▼─────────────────┐
                                            │  Storage                   │
                                            │  JSONL (append)            │
                                            │  + FAISS index (IVF > 500) │
                                            │  + Fernet encrypt (opt)    │
                                            └────────────────────────────┘

Embedded: No PostgreSQL, Redis, or external services needed. One binary, local JSONL + FAISS.
IVF Index: FAISS inverted file index activates at 500+ memories for O(√N) search.
MCP Native: Full MCP protocol over stdio and HTTP transports.

Available On

Platform	Status	Link
PyPI	Published v0.1.11	`mindcore-memory`
MCP Registry	Registered	View
Glama	Listed	View
MCP Market	Listed	View
MCP.so	Listed	View
LobeHub	Listed	View
mcpservers.org	Listed	View

Full Comparison

See docs/comparison.md for a detailed 5-server comparison covering architecture, search quality, latency, and migration guides.

Contributing

See CONTRIBUTING.md for the full guide. Quick path:

git clone https://github.com/woshilaohei/mindcore-memory-mcp.git
cd mindcore-memory-mcp
pip install -e ".[dev]"
pytest -v              # 118 tests
ruff check .           # linter
mypy mindcore_memory/  # type checker

License

⬆ back to top

⭐ If MindCore helps your AI remember, give it a star! ⭐

Available Tools

9 tools

bnd_checkA

Evaluate content through the 3D Boundary balance algorithm (Forward/Reverse Formula). Returns 4D scores (TRJ/EVO/COG/BALANCE) and accept/reject decision.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Tags for cognition dimension scoring.
`content`	Yes	Content to evaluate through the boundary algorithm.
`confidence`	No	Confidence 0.0-1.0.
`importance`	No	User-assigned importance 1-4.

TDQS

A3.5/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 the full burden. It discloses the algorithm name and output format but does not reveal behavioral traits like side effects, authentication needs, rate limits, or whether the call is safe. This is insufficient for a potentially complex evaluation tool.

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 with no filler or repetition. It front-loads the action and outputs, making it efficient for an AI agent to parse.

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 output schema and no annotations, the description explains the tool's core function and output but lacks details on parameter usage, prerequisites, error handling, or return value structure. It is minimally adequate but has gaps.

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 basic parameter descriptions. The description adds high-level output context (4D scores and decision) but does not explain how parameters like tags, confidence, or importance affect the evaluation or algorithm. Baseline 3 is appropriate because schema already documents parameters.

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 specifies a verb ('evaluate'), a resource ('content'), and a named algorithm ('3D Boundary balance algorithm'). It lists the exact output dimensions (TRJ/EVO/COG/BALANCE) and an accept/reject decision, distinguishing it clearly from sibling tools like bnd_stats or deduce.

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 tool is for evaluating content via a specific algorithm, but it does not explicitly state when to use it versus alternatives (e.g., bnd_stats) or when not to use it. No exclusions or context are provided.

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

bnd_statsA

Get BND manager stats: acceptance rate, score distributions, anti-chain triggers.

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 provided, so description bears full burden. It does not disclose behavioral traits such as whether it is read-only, if it has side effects, or any rate limits. Only states it 'gets' stats, which implies no changes but not explicitly.

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?

A single, front-loaded sentence that succinctly conveys the tool's purpose with no extraneous words. Every part is necessary and informative.

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 output schema, the description lists the types of stats returned, which is sufficient for an agent to understand the result. However, it could mention return format or time period for completeness.

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?

No parameters exist, so schema coverage is 100%. Baseline for 0 parameters is 4. Description adds no parameter info, but none is 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 explicitly states it gets BND manager stats and lists specific types: acceptance rate, score distributions, anti-chain triggers. The verb 'Get' and resource 'BND manager stats' are clear, and it distinguishes from sibling tools like bnd_check and memory tools.

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 like bnd_check. No context provided for appropriate usage scenarios or prerequisites.

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

deduceB

Run the Deduction engine on stored memories to derive new cognitive insights. Finds patterns across high-quality COG memories.

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No	Filter deduction sources by tags (optional).
`query`	Yes	What domain or question to focus deduction on.

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided; description lacks disclosure of side effects (e.g., whether it modifies memories), resource usage, or what 'high-quality COG memories' means.

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 no fluff, front-loading the action and outcome.

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?

Missing output schema and description of return format; 2 parameters and no annotations leave gaps for a tool that derives insights.

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 baseline is 3; description repeats schema definitions without adding extra meaning or format details.

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 'run the Deduction engine on stored memories to derive new cognitive insights' and 'finds patterns across high-quality COG memories,' distinguishing it from sibling memory and search tools.

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?

Implies use when pattern derivation is needed, but no explicit when-to-use or when-not-to-use guidance, nor alternatives mentioned.

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

memory_contextA

Build a context window from relevant memories for LLM input.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	What is the current task or question?
`max_tokens`	No	Approximate max tokens for the context. Default: 2000
`session_id`	No	Prioritize memories from this session.

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states 'Build a context window' without disclosing behaviors: whether it modifies state, what 'relevant' means (e.g., similarity-based?), auth requirements, or limits. Critical behavioral traits are 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?

The description is a single sentence of 9 words, containing no filler. It is front-loaded with the action and purpose. Every word 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 no output schema, the description should clarify return format or structure but only says 'context window'. It does not explain what 'relevant' means, error handling, or limits. Adequate for a simple tool but missing important details.

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%, so all three parameters have clear descriptions in the schema. The tool description adds no additional meaning beyond what the schema already provides. 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 action (Build), the resource (context window from relevant memories), and the purpose (for LLM input). It distinguishes from siblings like memory_recall by specifying the output is a context window, not just recalling memories.

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 (need a context window for LLM), but provides no explicit guidance on when not to use it or how it differs from siblings like memory_recall or memory_store. Usage context is implied rather than directed.

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

memory_deleteA

Delete a memory by its ID. Irreversible — use with caution.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes	The memory ID to delete.

TDQS

A4/5.0

Behavior3/5

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

Describes irreversibility, a key behavioral trait beyond the schema. No annotations exist to cover safety, so the description partially compensates but could detail more (e.g., permission needs, cascading 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?

Two efficient sentences; no filler. Purpose and caution front-loaded.

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 a simple one-param delete tool with no output schema or annotations, it conveys essential info (purpose, irreversibility). Minor gap: no note on error conditions or access.

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%, so baseline is 3. Description adds no extra meaning beyond the schema's 'The memory ID to delete.'

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?

Clearly states 'Delete a memory by its ID' — specific verb+resource. Distinguishes from siblings like memory_store, memory_recall.

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?

Explicitly warns 'Irreversible — use with caution,' providing clear usage context. Lacks explicit when-not-to-use or alternatives.

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

memory_recallC

Recall memories relevant to the query.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Filter by tags (optional).
`limit`	No	Max results to return. Default: 10
`query`	Yes	The query to search memories.
`session_id`	No	Filter by session (optional).

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations provided, the description should disclose behavioral traits like read-only nature, authentication requirements, or relevance scoring. It only says 'recall memories,' offering no transparency on side effects or underlying behavior.

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, which is efficient with no extraneous words. However, it sacrifices informativeness for brevity.

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 the tool has 4 parameters, no output schema, and no annotations, the description is too sparse. It fails to explain query behavior, result format, filtering logic, or error handling, leaving the agent with significant ambiguity.

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 has 100% description coverage, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain how parameters like tags or session_id affect the query.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Recall memories relevant to the query.' uses a specific verb and resource, but it is vague and does not distinguish from sibling tools like memory_context or memory_stats. It lacks detail on what 'recall' means (search vs. retrieve) and how it differs from similar 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 guidance is provided on when to use this tool versus alternatives such as memory_context or memory_stats. There is no mention of prerequisites, use cases, or when not to use this tool.

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

memory_statsB

Get stats: total count, importance distribution, avg confidence.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It only states it returns stats, but does not clarify if the operation is read-only, potentially expensive, or requires any permissions. For a safe retrieval tool, the description fails to confirm its non-destructive nature 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no extraneous information. Every word contributes to conveying the tool's function efficiently.

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 a simple no-parameter tool, the description provides the key output elements (count, distribution, confidence). Although there is no output schema, the listed stats give sufficient context. However, the absence of format details or response structure slightly reduces completeness.

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?

There are no parameters, and schema coverage is 100% (no params to describe). The description does not need to add parameter semantics. Baseline for 0 parameters is 4, and the description meets that baseline.

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 retrieves memory statistics (total count, importance distribution, avg confidence). It uses a specific verb ('Get') and lists the returned data, making the purpose unambiguous. However, it does not distinguish itself from sibling tools like bnd_stats, which might also provide statistical information.

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 is provided on when to use this tool versus alternatives such as memory_recall or memory_context. The description lacks context for preferred usage scenarios or when to avoid it.

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

memory_storeB

Store a new memory that should be remembered long-term.

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No	Tags for categorization and retrieval.
`source`	No	Source of this memory: 'user', 'agent', or 'tool'.	agent
`content`	Yes	The memory content to store. Be specific and factual.
`confidence`	No	Confidence level 0.0-1.0. Lower if uncertain.
`importance`	No	Importance: 1=episodic, 2=working, 3=semantic, 4=critical
`session_id`	No	Session identifier to group related memories.

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, and the description only states 'store' and 'long-term' without clarifying behavioral traits like idempotency, authorization requirements, side effects, or return values. The description is too minimal to provide adequate transparency.

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 of only 8 words, effectively front-loading the core purpose. Every word is necessary and there is no redundancy.

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 the tool has 6 parameters (including optional ones like tags, source, confidence, importance, session_id) and no output schema, the description is too brief. It omits details about storage behavior, error handling, and return values, making it incomplete for effective use.

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?

All 6 parameters have descriptions in the input schema (100% coverage). The description adds no additional meaning beyond the schema, so a 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 action ('store'), the resource ('memory'), and the purpose ('long-term'). It distinguishes the tool from siblings like memory_recall and memory_delete by focusing on storing new memories.

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 is provided on when to use this tool versus alternatives such as memory_context or memory_update_confidence. There is no mention of prerequisites, when not to use it, or contextual hints.

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

memory_update_confidenceA

Update a memory confidence score after correction.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes	The memory ID to update.
`confidence`	Yes	New confidence level 0.0-1.0.

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states 'update' without disclosing irreversibility, permissions, or side effects on memory storage. Lacks depth for a mutation 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?

Single sentence of 6 words, extremely concise with no redundant information. Every word serves a purpose.

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?

Minimally adequate for a simple update tool with full param coverage and no output schema. But lacks usage guidance and behavioral details to fully support agent decision-making.

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 descriptions for both parameters. Description adds 'after correction' context but does not enhance parameter meaning beyond what schema 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 specific action 'update' on resource 'memory confidence score' with context 'after correction'. Distinguishes from siblings like memory_store, memory_delete, memory_recall, and memory_stats.

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?

Implied usage 'after correction' but no explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions mentioned despite having related siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv0.1.15Jul 12, 2026
- First observedbnd_check
- First observedbnd_stats
- First observeddeduce
- First observedmemory_context
- First observedmemory_delete
- First observedmemory_recall
- First observedmemory_stats
- First observedmemory_store
- First observedmemory_update_confidence

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: BND algorithm evaluation, deduction, memory CRUD operations, context building, and stats. No overlapping functionality.

Naming Consistency4/5

Tools follow a consistent snake_case convention with prefixes like 'bnd_' and 'memory_', though 'deduce' deviates from the verb_noun pattern and 'memory_context' is noun_noun instead of verb_noun.

Tool Count5/5

9 tools is well within the ideal 3-15 range, covering all essential operations for a memory system with cognitive algorithms without being excessive.

Completeness4/5

Covers core memory operations (store, recall, delete, update confidence, stats, context) and specialized BND/deduction tools. Minor gaps like inability to update other memory fields or list all memories are acceptable.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Living MemoryOAuth
to.viibe
An MCP memory server. One memory your agents share — across models, devices and apps.
Knowledge & Memory Autonomous Agents AI & Machine Learning
22
memnodeOAuth
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2
XMemo AOAuth
io.github.yonro
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Autonomous Agents Knowledge & Memory
19212
mifactory-agent-memory C
io.github.mifactory-bot
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Knowledge & Memory Autonomous Agents Agent Orchestration
22

Related MCP Servers

elephantasm-mcp
Knowledge & Memory Autonomous Agents
kaminocorp
A
license
A
quality
D
maintenance
MCP server for long-term agent memory, providing persistent memory, searchable knowledge, and evolving identity for AI agents.
Updated 6 months ago (2026-03-19 00:48 UTC)
5
3
Apache 2.0
Synapse Memory
Knowledge & Memory Search
RaffaelFerro
A
license
Not graded
quality
C
maintenance
A lightweight MCP server that provides long-term memory for LLMs by storing and retrieving important facts, decisions, and preferences through smart semantic search and automatic organization.
Updated 4 days ago (2026-09-02 18:54 UTC)
10
MIT
MemAI
Knowledge & Memory Vector Databases
Filipe-Soares-de-Almeida
A
license
A
quality
B
maintenance
A long-term memory MCP server for AI agents that stores memories (facts, decisions, etc.) in a single SQLite database with hybrid search and full edit history, ensuring consistency across sessions.
Updated 7 days ago (2026-08-30 19:05 UTC)
24
MIT
Selti
Knowledge & Memory RAG Systems Vector Databases
Dek1m
F
license
Not graded
quality
B
maintenance
A persistent memory server for AI agents using MCP protocol, enabling semantic storage and retrieval of dialogues, documents, and agent states.
Updated 22 days ago (2026-08-16 00:07 UTC)
-

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/woshilaohei/mindcore-memory-mcp'

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