How do I use memory-bank-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., "@memory-bank-mcp search for 'project alpha' evidence" 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.

memory-bank-mcp

by axrbarsic

Overview Schema Related Servers Score Discussions

Python

Verifiable Memory Bank

Русский | English | Українська

Verifiable Memory Bank создает локальную воспроизводимую внешнюю память для людей и AI-клиентов. К каждому результату прикреплено точное доказательство, поэтому найденный фрагмент можно проверить в именованном нормализованном представлении, а его происхождение вернуть к неизменяемым исходным байтам, датам, атрибуции и SHA-256.

Зачем это нужно

По папке документов трудно искать. Векторная база находит похожие формулировки, но одно сходство не доказывает утверждение. Verifiable Memory Bank разделяет эти задачи:

исходные байты хранятся в неизменяемом хранилище с адресацией по содержимому;
детерминированные адаптеры превращают поддерживаемые форматы в неперекрывающиеся сегменты;
политика доверия помечает материал как canon, context или unresolved;
полнотекстовый поиск SQLite и TF-IDF плюс NumPy SVD дают точный и смысловой поиск;
Reciprocal Rank Fusion объединяет оба рейтинга в режиме hybrid;
каждый результат содержит стабильный segment_id, а evidence связывает его с хешированным нормализованным представлением через TextPosition и TextQuote selectors и с исходным объектом через SHA-256;
MCP-сервер только для чтения открывает AI-клиентам тот же интерфейс, ориентированный на доказательства.

Банк не считает автоматическим подтверждением смысловую близость, свежую дату публикации, результат OCR, цитату или речь без надёжной атрибуции.

Related MCP server: Evidence MCP

Быстрый старт

Нужны Python 3.11 или новее и uv.

git clone https://github.com/axrbarsic/verifiable-memory-bank.git
cd verifiable-memory-bank
uv tool install .

memory-bank --bank .memory-bank init
memory-bank --bank .memory-bank ingest examples/sample-corpus
memory-bank --bank .memory-bank search "amber current" --mode hybrid --limit 5

Скопируйте segment_id из результата и откройте точное доказательство:

memory-bank --bank .memory-bank evidence SEGMENT_ID
memory-bank --bank .memory-bank health

Флаг --json после memory-bank или подкоманды включает машиночитаемый вывод. Тот же банк можно выбрать через MEMORY_BANK_HOME.

В подробном руководстве описаны конфигурация, JSON, загрузка из inbox, приёмка и устранение неполадок.

Вымышленный sample corpus намеренно оставлен на английском. Это стабильная fixture для воспроизводимых англоязычных поисковых тестов, а не часть пользовательской документации.

Интерфейс CLI

memory-bank --bank PATH [--json] init
memory-bank --bank PATH [--json] ingest INPUT [INPUT ...]
memory-bank --bank PATH [--json] ingest-inbox [INBOX]
memory-bank --bank PATH [--json] status
memory-bank --bank PATH [--json] search QUERY [--mode exact|semantic|hybrid] [--limit N]
memory-bank --bank PATH [--json] source SOURCE_ID
memory-bank --bank PATH [--json] evidence SEGMENT_ID
memory-bank --bank PATH [--json] dossier TOPIC [--limit N]
memory-bank --bank PATH [--json] chronology TOPIC [--limit N]
memory-bank --bank PATH [--json] health
memory-bank --bank PATH [--json] accept
memory-bank --bank PATH [--json] migrate

Все фильтры и аргументы показывает memory-bank COMMAND --help.

MCP

memory-bank-mcp обслуживает один банк через stdio и не предоставляет инструменты изменения. Безопасный для desktop запуск по умолчанию использует ~/.memory-bank, а CLI использует локальный для проекта .memory-bank. Переменная MEMORY_BANK_HOME выбирает другой абсолютный путь для обоих:

{
  "mcpServers": {
    "verifiable-memory-bank": {
      "command": "memory-bank-mcp",
      "env": {
        "MEMORY_BANK_HOME": "/absolute/path/to/.memory-bank"
      }
    }
  }
}

Доступны инструменты status, search, dossier, chronology, source и evidence. Перед тем как представить существенное утверждение подтверждённым, клиент должен получить точное доказательство.

MCP возвращает переносимый object_ref и не передает абсолютный путь банка или локальный file: URI в контекст модели. Локальный CLI и Python API сохраняют операторский object_path.

Плагин Codex

В plugins/verifiable-memory-bank/ находится плагин с переиспользуемым процессом проверки доказательств. Руководство по установке объясняет подключение через marketplace Codex и запуск MCP-сервера.

Форматы и расширение

В ядро входят детерминированные адаптеры для обычного текста, разметки, структурированных данных и субтитров. Опциональные extras добавляют PDF, OCR и медиа:

uv tool install '.[pdf]'
uv tool install '.[ocr]'
uv tool install '.[media]'
uv tool install '.[all]'

Неизвестный формат получает needs_adapter, а не вымышленный успешный результат. См. руководство по адаптерам и рабочий пример собственного адаптера.

Доверие и доказательства

Доверие задаётся явной политикой, а не поисковой оценкой. canon может сделать прямой первичный материал допустимым для подтверждения, context объясняет или цитирует его, а unresolved сохраняет материал, которому ещё нужны атрибуция или проверка. Сегменты quote, ocr и derived сами по себе не проходят этот gate. Поле claim_evaluation: not_evaluated напоминает, что банк не проверял entailment конкретного тезиса.

Подробности: доверие и доказательства, examples/trust-config.yaml и examples/acceptance.yaml.

Архитектура и проверка

При загрузке система строит полную версию-кандидат, проверяет базу данных, хеши объектов, смещения сегментов, полнотекстовый индекс, семантический артефакт и ссылки, запечатывает effective trust policy в manifest, затем атомарно переключает указатель ACTIVE. Читатели видят либо предыдущую валидную сборку, либо новую валидную сборку.

Для разработки репозитория:

make install
make check
make acceptance

make acceptance строит wheel, устанавливает его в чистое окружение Python 3.13, дважды загружает sample corpus, проверяет идемпотентность и активацию, затем вызывает search, health и acceptance через установленный CLI.

Лицензии

Материал	Лицензия
Программный код и исполняемые примеры	0BSD
Документация и оригинальные иллюстрации	CC0-1.0
Полностью вымышленный sample corpus и YAML-примеры	CC0-1.0
Загруженные пользователем материалы	Проект их не перелицензирует

См. полную карту лицензий, текст 0BSD и юридический текст CC0-1.0.

Available Tools

6 tools

chronologyC

Return dated evidence for a topic in chronological order.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`topic`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states the output (dated evidence in order), but does not disclose whether the tool has side effects, requires authentication, or has rate limits. No contradictions with annotations.

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 sentence, concise and front-loaded with the core action. Every word earns its place, though more detail would improve it without sacrificing conciseness.

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 an output schema (which reduces the need to explain return values), the tool has two parameters with no schema descriptions and no additional context in the description. For a tool with sibling tools and a simple but under-specified interface, the description is insufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning beyond the parameter names. It does not explain what 'topic' means, what 'limit' controls, or any format expectations. The description fails to compensate for the lack of parameter 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?

The description clearly states the tool returns dated evidence for a topic in chronological order, specifying the verb 'return', the resource 'dated evidence', and the ordering. This distinguishes it from siblings like 'evidence' (likely unordered) and 'search' (general).

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 provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about prerequisites or typical use cases. The sibling tools are not mentioned.

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

dossierC

Return an evidence-backed dossier for a topic.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`topic`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as data sources, aggregation methods, performance implications, or any restrictions. The term 'evidence-backed' hints at behavior but lacks specifics.

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 sentence, front-loading the core purpose. However, it is under-specified for the complexity; it could include a brief note on parameters or usage without becoming 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?

Given the tool has two parameters and an output schema, the description lacks detail on what constitutes a dossier, how evidence is gathered, and what the output contains. It feels incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description adds no meaning beyond the schema. The parameters 'topic' and 'limit' are not explained (e.g., what topic format, how limit affects results).

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 it returns an evidence-backed dossier for a topic, specifying the action (return) and resource (dossier). It distinguishes from siblings like search, source, and evidence by focusing on a compiled report.

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. Does not mention any prerequisites, exclusions, or comparisons to sibling tools like search or source.

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

evidenceB

Return the exact evidence packet for one search segment.

ParametersJSON Schema

Name	Required	Description	Default
`segment_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

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 bears full burden for behavioral disclosure. It states 'return' (read operation) but does not mention whether authorization is needed, how large the packet might be, or if there are any side effects. This is insufficient for a tool with zero annotation coverage.

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 fluff. Every word contributes meaning, and it is appropriately sized for a simple tool.

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 simplicity (1 parameter, no nested objects, output schema exists), the description is minimally adequate. However, it does not mention how to locate or format the segment_id, nor any limitations (e.g., single segment only, no pagination).

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?

Schema description coverage is 0% for the single parameter 'segment_id'. The description does not explain what a segment_id is, how to obtain it, or its expected format. The parameter name is somewhat self-explanatory, but the description should add more context given the lack of schema docs.

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 a specific verb ('return') and resource ('evidence packet') with a clear scope ('for one search segment'), making it easy to understand what the tool does. It also implies a difference from siblings like 'search' or 'dossier'.

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 provides no guidance on when to use this tool vs. siblings (e.g., 'status', 'search', 'dossier', 'chronology', 'source'). No context on prerequisites or exclusion cases is given.

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

searchC

Search the bank with exact, semantic, or hybrid ranking.

ParametersJSON Schema

Name	Required	Default
`mode`	No	hybrid
`limit`	No
`query`	Yes
`trust_status`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

Minimal disclosure: no annotations, so description should explain behavior (e.g., read-only, permissions), but it only mentions search modes without detailing effects or requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Single sentence is concise but sacrifices necessary detail; adequate but could be more informative 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?

Given 4 parameters, no output schema insight, and missing usage context, the description is incomplete for effective tool selection and 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?

With 0% schema description coverage, description fails to add meaning beyond the schema; only repeats mode values already in enum.

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 the bank with three ranking modes, distinguishing it from sibling tools like status, dossier, etc., which have different purposes.

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 or when to choose each mode; lacks context for optimal use.

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

sourceB

Return one immutable source record and its provenance.

ParametersJSON Schema

Name	Required	Description	Default
`source_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only says 'immutable' hinting at read-only, but omits error behavior, access requirements, or response format. Minimal transparency.

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?

Extremely concise single sentence. Front-loaded with verb and resource. Could slightly expand without losing conciseness.

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 low complexity (1 param, output schema exists), the description is adequate but could elaborate on 'provenance' and mention that it returns exactly one record. Missing context about use cases.

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?

Schema coverage is 0% and the description adds no meaning for the sole parameter 'source_id' (e.g., format, source, how to obtain it). The schema alone provides no additional semantics.

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 'Return' and the resource 'source record', adding 'immutable' and 'provenance'. This distinguishes it from sibling tools like 'search' (which returns multiple) and 'status' (which likely returns state).

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 siblings like 'search' or 'status'. It does not specify prerequisites or alternatives.

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

statusA

Return bank readiness, counts, and ingestion warnings.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

The description discloses that the tool returns readiness, counts, and warnings, which indicates a read-only operation. However, with no annotations, it lacks details on potential side effects, error conditions, or data freshness.

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, clear sentence that front-loads the essential information. Every word adds value, and there is no extraneous text. It is appropriately concise.

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 (0 parameters, no annotations), the description adequately covers its purpose and output categories. It could mention potential error states or response format, but overall it is sufficient for an agent to understand basic behavior.

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 zero parameters, and the schema covers all inputs (none). The description adds no parameter information, but for 0-parameter tools, the baseline is 4. No additional semantics are 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 tool returns bank readiness, counts, and ingestion warnings. It uses specific nouns ('bank readiness', 'counts', 'ingestion warnings') and contrasts with sibling tools that likely perform different functions like searching or dossier management.

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 when needing system status information, but provides no explicit guidance on when to choose this over sibling tools like search or dossier. No alternatives or exclusions are mentioned.

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

B3.4/5.0

Disambiguation5/5

Each tool targets a distinct retrieval need: system status, search, topic dossier, chronology, single source, and evidence segment. No two tools serve the same purpose, making selection unambiguous.

Naming Consistency5/5

All tool names are single-word lowercase nouns, following a consistent style. Though not verb_noun, the pattern is uniform and predictable.

Tool Count5/5

6 tools is well-scoped for a memory bank server, covering querying, summarization, and provenance retrieval without excess or deficiency.

Completeness3/5

The tool surface covers retrieval comprehensively but lacks any write or update tools (e.g., add_memory, delete_source). This leaves a notable gap for interactive maintenance.

Maintenance

ActivitySlowing

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

Vocci
ai.vocci
Read-only MCP access to authorized Vocci sessions, notes, files, and memory search.
Note Taking Knowledge & Memory
2
GENESIS ProofRelay MCP Verifier A
io.genesisre
Read-only verifier for 25 ProofRelay MCP tools and non-confidential evidence bundles.
Security Testing & QA Tools
262
Agenda Intelligence MD A
io.github.vassiliylakhonin
Evidence-readiness MCP server: validate, audit, and score briefs, memos, and evidence packs.
Legal & Compliance Research & Data
116
AIﾉアカリ☆ Agent Trust Receipt A
ai.ai-akari
Read-only Remote MCP for externally grounded AI agent trust receipts.
Security Autonomous Agents
22

Related MCP Servers

artagon-vault-mcp
artagon
F
license
Not graded
quality
C
maintenance
Read-only MCP server for querying an evidence-aware knowledge vault with temporal and provenance-aware data, supporting agent memory and semantic graph projections.
Updated a month ago (2026-07-20 21:32 UTC)
Evidence MCP
RAG Systems Search Documentation Access
zzkws
A
license
Not graded
quality
A
maintenance
Provides an evidence-oriented MCP interface for Evidence RAG Pilot, enabling retrieval of evidence packages, chunks, and evidence images from PDF-based corpora.
Updated 16 days ago (2026-08-18 12:59 UTC)
1
Apache 2.0
HexWitness
Knowledge & Memory Code Analysis
siaginw
A
license
Not graded
quality
A
maintenance
Enables AI agents to query persistent, build-scoped evidence memory for reverse engineering, combining static analysis, runtime captures, and claims with honest uncertainty. Provides read-only access to an evidence graph and MCP prompts for structured investigations.
Updated 20 days ago (2026-08-14 14:03 UTC)
54
1
Apache 2.0
Aegis
RAG Systems Search Education & Learning Tools
Demi8-patch
F
license
A
quality
C
maintenance
Provides read-only MCP tools to search and retrieve evidence-grounded knowledge compiled from video content, including hybrid semantic and lexical search with citations.
Updated 17 days ago (2026-08-16 20:24 UTC)
5

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/axrbarsic/verifiable-memory-bank'

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