Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Open Brain Knowledge MCP Server recall what we discussed about error handling in the last session"
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.
A persistent, cross-session knowledge base for AI agents. Built on the Model Context Protocol (MCP), this server gives AI coding assistants like Claude Code long-term memory — they can recall what happened in previous sessions, store permanent knowledge, and search across their entire history.
The problem: AI agents start from zero every session. They forget what you worked on, what decisions were made, and what errors were resolved.
The solution: Open Brain indexes every session into a searchable SQLite database with full-text search (FTS5). Agents can query it with kb_recall to find anything from any previous session — errors, decisions, code patterns, stored facts — instantly.
Claude Code has a file-based memory system (~/.claude/projects/<project>/memory/) — but it's just markdown files loaded into context at session start. It's manual, not searchable, and not connected to session history.
Open Brain Knowledge is fundamentally different — it's an automated, searchable, indexed knowledge base that captures everything across every session and makes it queryable.
Capability | Claude Code Built-in | Open Brain Knowledge |
Cross-session recall | No — each session starts from zero | Yes — |
Full-text search over history | No | Yes — FTS5 with ranked results |
Persistent knowledge storage | No | Yes — |
Project-scoped vs global memory | No | Yes — scoped by default, global on demand |
Session indexing | No | Yes — automatic via SessionEnd hook |
Session summarization | No | Yes — |
Auto-tagging | No | Yes — tech keywords, error types, file extensions |
TTL-based pruning | No | Yes — 90-day default |
Searchable by category/tags/time | No | Yes — filter by error, project, timeframe |
Claude Code's memory is like sticky notes. Open Brain Knowledge is a searchable database with full-text indexing.
Related MCP server: Memory MCP
When you're working on multiple projects, you don't want session history from Project A polluting searches in Project B. But you do want general knowledge (preferences, processes, learned facts) available everywhere.
Open Brain Knowledge solves this with scoped-by-default, global-on-demand architecture:
Data Type | Default Behavior | Override |
Session chunks & summaries | Scoped to project when |
|
Stored knowledge | Global by default (available everywhere) |
|
# Search only the current project's history (recommended default)
kb_recall({ queries: ["auth bug"], project: "/path/to/myapp" })
# Search everything across all projects
kb_recall({ queries: ["auth bug"], global: true })
# Store a fact available everywhere
kb_store({ content: "Deploy process: ...", key: "deploy-process" })
# Store a fact only relevant to one project
kb_store({
content: "Uses Clerk for auth with custom middleware",
key: "auth-setup",
scope: "project",
project_dir: "/path/to/myapp"
})
# List knowledge for current project (global + project-scoped)
kb_list({ project: "/path/to/myapp" })Session data is project-scoped by default — agents should always pass their working directory as project when calling kb_recall
Stored knowledge is global by default — facts, preferences, and decisions are typically useful across projects
Global knowledge always surfaces — even in project-scoped searches, knowledge with no project_dir is included
Single database — no schema splits or sync headaches; scoping is done via filtering
┌─────────────────┐ ┌──────────────────┐ ┌───────────────────┐
│ Claude Code │────▶│ context-mode │────▶│ Session .db │
│ (AI Agent) │ │ (MCP plugin) │ │ files │
└─────────────────┘ └──────────────────┘ └────────┬──────────┘
│ │
│ kb_recall / kb_store │ SessionEnd hook
│ │ (auto-index.mjs)
▼ ▼
┌─────────────────────────────────────────────────────────────────────┐
│ Open Brain Knowledge MCP │
│ │
│ ┌─────────────┐ ┌──────────┐ ┌────────────┐ ┌──────────────┐ │
│ │ sessions │ │ chunks │ │ knowledge │ │ summaries │ │
│ │ (metadata) │ │ (FTS5) │ │ (FTS5) │ │ (FTS5) │ │
│ └─────────────┘ └──────────┘ └────────────┘ └──────────────┘ │
│ │
│ ~/.claude/context-mode/knowledge.db │
└─────────────────────────────────────────────────────────────────────┘context-mode (dependency MCP plugin) captures session events as .db files during each Claude Code session
When a session ends, the SessionEnd hook (auto-index.mjs) automatically indexes new events into the knowledge base
Events are chunked (max 2000 chars), categorized, and auto-tagged with tech keywords, error types, and file extensions
All content is indexed with SQLite FTS5 (porter stemming + unicode61 tokenizer) for fast, ranked full-text search
Agents query the knowledge base via MCP tools (kb_recall, kb_store, etc.)
Open Brain Knowledge depends on context-mode to capture session data. context-mode records everything that happens during a Claude Code session (prompts, tool results, file changes, errors, commands) into per-session SQLite .db files.
Install context-mode:
npm install -g @anthropic/context-mode
# or follow the context-mode repo's installation instructionscontext-mode must be registered as a Claude Code plugin. After installation, verify it appears in your Claude Code settings:
// ~/.claude/settings.json
{
"enabledPlugins": {
"context-mode@context-mode": true
}
}Package | Version | Purpose |
| ^1.26.0 | MCP server framework (StdioServerTransport) |
| ^12.6.2 | SQLite database driver with FTS5 support |
| ^3.25.0 | Schema validation for tool parameters |
Package | Version | Purpose |
| ^5.7.0 | TypeScript compiler |
| ^4.21.0 | TypeScript execution for development |
| ^7.6.13 | Type definitions |
| ^22.19.11 | Node.js type definitions |
The recommended install location is ~/.claude/knowledge-mcp/ — right alongside the ~/.claude/context-mode/ directory. Both are Claude Code infrastructure and belong together.
~/.claude/
├── context-mode/ # Session capture (dependency)
│ ├── sessions/ # Per-session .db files
│ └── knowledge.db # The knowledge base (created by this server)
├── knowledge-mcp/ # ← This server lives here
│ ├── src/
│ ├── build/
│ ├── scripts/
│ └── package.json
├── settings.json
└── projects/cd ~/.claude
git clone https://github.com/YOUR_USERNAME/open-brain-knowledge.git knowledge-mcp
cd knowledge-mcp
npm install
npm run buildAdd the server via the Claude Code CLI:
claude mcp add open-brain-knowledge -- node ~/.claude/knowledge-mcp/build/server.jsOr manually add it to your Claude Code settings file (~/.claude/settings.json):
{
"mcpServers": {
"open-brain-knowledge": {
"command": "node",
"args": ["~/.claude/knowledge-mcp/build/server.js"]
}
}
}The SessionEnd hook automatically indexes new session data when a Claude Code session ends. Add it to your Claude Code settings:
// ~/.claude/settings.json
{
"hooks": {
"SessionEnd": [
{
"type": "command",
"command": "node ~/.claude/knowledge-mcp/scripts/auto-index.mjs"
}
]
}
}Start a new Claude Code session and ask the agent to run kb_stats. You should see output showing the knowledge base tables are initialized.
Open Brain Knowledge exposes 10 tools via MCP:
kb_recallSearch across all indexed sessions, stored knowledge, and session summaries. This is the primary tool agents use to remember things. By default, results are scoped to the project you specify — always pass your current working directory as project for best results.
Parameter | Type | Required | Description |
|
| Yes | Search queries — batch multiple questions in one call |
|
| No | Limit to last N sessions |
|
| No | Time window (e.g. |
|
| No | Filter: |
|
| No | Your current working directory — scopes results to this project |
|
| No | Search across ALL projects instead of scoping (default: |
|
| No | Filter by tags (e.g. |
|
| No | Return full content instead of snippets (default: |
|
| No | Results per query (default: |
Example usage by an agent:
# Project-scoped search (recommended)
kb_recall({
queries: ["authentication bug", "login error fix"],
project: "/home/user/myapp",
since: "7 days",
category: "error",
verbose: true
})
# Global search across all projects
kb_recall({
queries: ["deploy process"],
global: true
})kb_indexIndex a specific session .db file. Supports incremental updates — if the session was already indexed but has new events, only new data is processed.
Parameter | Type | Required | Description |
|
| Yes | Absolute path to a session |
kb_reindexScan the sessions directory and index all new or updated .db files. Incremental by default.
Parameter | Type | Required | Description |
|
| No | Drop and rebuild the entire knowledge base (default: |
kb_storeStore a piece of knowledge permanently. By default, knowledge is stored globally (available across all projects). Set scope to "project" and pass a project_dir to restrict it to a specific project.
Parameter | Type | Required | Description |
|
| Yes | The knowledge to store |
|
| No | Short label for retrieval (e.g. |
|
| No | Tags for categorization |
|
| No | Origin (default: |
|
| No |
|
|
| No | Project directory to scope to (only used when scope is |
kb_forgetRemove stored knowledge by ID or key.
Parameter | Type | Required | Description |
|
| No | Knowledge entry ID |
|
| No | Knowledge key |
kb_listList all manually stored knowledge entries. Pass project to see only global + project-scoped entries for that directory.
Parameter | Type | Required | Description |
|
| No | Max entries to return (default: |
|
| No | Filter to global + this project's knowledge entries |
kb_summarizeReturns unsummarized session chunks for the calling agent to read and summarize. No external API needed — the agent itself writes the summary.
Parameter | Type | Required | Description |
|
| No | Summarize a specific session |
|
| No | Return last N unsummarized sessions (default: |
kb_store_summaryStore an agent-generated session summary.
Parameter | Type | Required | Description |
|
| Yes | The session ID |
|
| Yes | Summary text (3-8 sentences) |
kb_statsShow knowledge base statistics — sessions indexed, chunks, tags, stored knowledge, summaries, disk usage, breakdowns by project and category.
kb_pruneRemove sessions older than their TTL (default: 90 days).
The knowledge base lives at ~/.claude/context-mode/knowledge.db (SQLite, WAL mode).
Table | Purpose |
| Session metadata (id, project_dir, timestamps, event_count, TTL) |
| Session events broken into searchable chunks (max 2000 chars) |
| FTS5 virtual table over chunks (porter + unicode61 tokenizer) |
| Many-to-many chunk tags (auto-extracted: tech keywords, error types, file extensions) |
| Manually stored knowledge (permanent, optionally project-scoped via |
| FTS5 virtual table over knowledge |
| Agent-generated session summaries |
| FTS5 virtual table over summaries |
Content is automatically tagged during indexing:
Tech keywords — typescript, react, convex, docker, claude, etc. (~80 keywords)
Tool names — tool:read, tool:bash, tool:edit, etc.
Error types — error:enoent, error:typeerror, error:econnrefused, etc.
File extensions — ext:ts, ext:py, ext:json, etc.
Event categories — prompt, tool_result, file_change, error, command_output, etc.
To make AI agents reliably use the knowledge base, you need to add hardened memory instructions to your Claude Code configuration. Without these, agents will default to saying "I don't remember" instead of searching the knowledge base.
They are rules placed in Claude Code's memory system that tell the agent to always check the knowledge base before claiming it has no memory of something. This transforms the agent from a stateless assistant into one with persistent recall.
Add the following to any project's CLAUDE.md file where you want agents to have persistent memory:
## Persistent Memory
This project uses Open Brain Knowledge MCP for cross-session memory.
- When asked about previous sessions or past work, ALWAYS call `kb_recall` before responding
- Always pass your current working directory as `project` when calling `kb_recall` to scope results
- Never say "I don't have memory of that" without first searching the knowledge base
- Use broad AND specific queries to maximize recall (e.g., both the topic name and related keywords)
- Store project-specific decisions with `kb_store({ scope: "project", project_dir: "<this dir>" })`
- Store general knowledge (preferences, processes) with `kb_store` (global by default)If you use Claude Code's built-in memory (the ~/.claude/projects/<project>/memory/ directory), create a feedback memory file that reinforces the behavior:
Create ~/.claude/projects/<project>/memory/feedback_use_knowledge_base.md:
---
name: Use Open Brain Knowledge MCP for previous session recall
description: When the user asks about previous sessions or past conversations, always use kb_recall from Open Brain Knowledge MCP before saying "I don't remember"
type: feedback
---
When the user asks about something from a previous session, ALWAYS search Open Brain Knowledge MCP (`kb_recall`) before responding. Never say "I don't have any memory of that" without checking first.
**Why:** Open Brain stores cross-session context. Saying "I don't remember" without checking is incorrect — the knowledge may be there.
**How to apply:**
1. When the user references a previous session or asks "what were we talking about", immediately call `kb_recall` with relevant queries.
2. Use broad and specific query variations to maximize recall (e.g., both the topic name and related keywords).
3. Only after checking Open Brain and finding nothing should you tell the user the information wasn't found.MEMORY.md indexIn your ~/.claude/projects/<project>/memory/MEMORY.md, add a pointer to the feedback file:
## Feedback
- [feedback_use_knowledge_base.md](feedback_use_knowledge_base.md) — Always check Open Brain kb_recall before saying "I don't remember" when asked about previous sessionsStore a test marker in one session:
Agent: kb_store({ content: "TEST MARKER — purple octopus test", key: "test-marker", tags: ["test"] })Start a new session and ask about it:
User: "We were talking about a purple octopus, why?"
Agent: [should call kb_recall before responding]If the agent finds the marker without prompting, your hardened instructions are working.
For even stronger memory behavior, you can instruct the agent to proactively check the knowledge base at the start of every session. Add this to your feedback memory:
---
name: Read memory at session start
description: Always read user profile and key memory files at the start of every session
type: feedback
---
Read memory files at the start of every session before responding.
**Why:** The user expects continuity across sessions. Forgetting context feels impersonal and wastes time.
**How to apply:** At the beginning of each session, read MEMORY.md and relevant memory files so you know the user's name, preferences, and current project context.# Run in development mode (hot reload via tsx)
npm run dev
# Build for production
npm run build
# Run production build
npm startknowledge-mcp/
├── src/
│ ├── server.ts # MCP server — tool definitions and handlers
│ ├── db.ts # SQLite database layer, schema, queries
│ ├── indexer.ts # Session file indexing (incremental)
│ └── tags.ts # Auto-tag extraction (regex-based)
├── scripts/
│ └── auto-index.mjs # SessionEnd hook for automatic indexing
├── build/ # Compiled JavaScript output (gitignored)
├── package.json
└── tsconfig.jsonMIT
Remove a piece of stored knowledge by ID or key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Knowledge entry ID to remove | |
| key | No | Knowledge key to remove |
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 action 'Remove' with no mention of destructive nature, side effects, or irreversibility, which is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is too brief to provide necessary context. It sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description does not cover behavioral details, return values, or error handling. It is incomplete for an agent to make an informed choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no additional meaning beyond the schema's parameter descriptions. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' and resource 'stored knowledge', and hints at differentiation by requiring ID or key for identification. However, it does not explicitly distinguish from sibling tool kb_prune, which also removes knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use kb_forget versus alternatives like kb_prune or kb_store. The description lacks any contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Index a specific session .db file into the persistent knowledge base. Supports incremental updates — if the session was already indexed but has new events, only the new data is processed.
| Name | Required | Description | Default |
|---|---|---|---|
| db_file | Yes | Absolute path to a session .db file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses incremental update behavior, which is key. No annotations exist, so description carries full burden. Lacks details on permissions or data integrity, but sufficient for the tool's scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with key purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-param tool with no output schema, description covers purpose and key behavioral trait (incremental updates). Adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with parameter description. Description adds no extra semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Index', resource 'session .db file', and target 'persistent knowledge base'. Distinguishes from sibling tools like kb_forget, kb_list, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when needing to add session data to knowledge base, but no explicit when-not or alternative comparisons. Context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all manually stored knowledge entries. Pass your working directory as project to see only global + project-scoped entries.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entries to return (default: 20) | |
| project | No | Filter to global + this project's knowledge entries |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Implies a read-only list operation with no destructive effects, but without annotations, it could disclose more about behavior such as rate limits, ordering, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy; each sentence serves a clear purpose: stating the action and providing a usage tip.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list tool, but missing details about return format, ordering, and what distinguishes 'manually stored' entries from others.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions. The description adds practical context for the project parameter (working directory) but does not add substantial new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'manually stored knowledge entries' with a specific verb and resource. It adds context about the project parameter but does not explicitly distinguish from sibling tools like kb_recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on using the project parameter to filter entries but lacks explicit when-to-use vs. alternatives or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove sessions older than their TTL (default 90 days). Returns count of pruned sessions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the destructive nature ('Remove sessions') and return value, but lacks details like required permissions, irreversibility, or impact on other tools. Adequate for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Action ('Remove sessions') is front-loaded, followed by condition and return value. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers all necessary information: what it does, when (older than TTL), and what it returns. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds value by explaining the default TTL and return behavior, which goes beyond the empty schema. Baseline 4 for zero parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Remove sessions'), the condition ('older than their TTL, default 90 days'), and the return value ('Returns count of pruned sessions'). It distinguishes itself from siblings like kb_forget (targeted forgetting) and kb_list (listing) by specifying it prunes old sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cleanup of old sessions but provides no explicit guidance on when not to use or alternatives. It states the default TTL but does not mention prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across all indexed sessions, stored knowledge, and session summaries. Returns ranked results. By default, results are scoped to the project you specify — always pass your current working directory as project for best results. Set global: true to search across all projects. Global knowledge (stored without a project) is always included regardless of scope.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter by tags (e.g. ['typescript', 'error:enoent', 'ext:ts']) | |
| limit | No | Results per query (default: 5) | |
| since | No | Time window, e.g. '7 days', '30 days', '2 hours' | |
| global | No | If true, search across ALL projects instead of scoping to the current one | |
| project | No | Your current working directory — used to scope results to the current project | |
| queries | Yes | Search queries — batch all questions in one call | |
| verbose | No | If true, return full chunk content instead of just snippets | |
| category | No | Filter by event category | |
| sessions | No | Limit to last N sessions |
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 that results are ranked, that global knowledge is always included, and mentions the verbose parameter for full content. However, it does not discuss pagination, rate limits, or potential side effects, which is acceptable for a read-only search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, with no filler. It front-loads the purpose and then provides actionable usage tips. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 9 parameters and no output schema, the description covers the core usage pattern (scoping, global, batching). It could mention the return format more explicitly, but for a search tool with ranked results, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining the scoping rule and batching recommendation ('batch all questions in one call'). This helps the agent use parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Search across') and clearly identifies the resource ('indexed sessions, stored knowledge, and session summaries'). It distinguishes itself from sibling tools like kb_store, kb_index, etc., which focus on writing or maintenance rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use scoped vs. global search ('always pass your current working directory as `project` for best results', 'Set `global: true` to search across all projects'). It does not explicitly state when not to use the tool, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan the sessions directory and index any new or updated session .db files. Incremental by default — only processes sessions with new events. Use force to rebuild everything.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | If true, drop and rebuild the entire knowledge base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses incremental vs force behavior and the resource affected, but omits details like permissions, side effects (e.g., locking), or return values. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the main action and options. Every sentence provides essential information without redundancy. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the primary functionality and options. It lacks mention of output or prerequisites, but is largely complete given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a clear description for the only parameter 'force'. The tool description adds context about default behavior ('incremental by default'), which enhances understanding beyond the schema alone. Schema coverage is 100%, baseline 3, plus extra context earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans sessions directory and indexes new/updated .db files, with specific verbs 'scan' and 'index'. It distinguishes incremental vs force rebuild but does not explicitly contrast with sibling like kb_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use force vs default incremental mode, but does not provide explicit guidance on when to use this tool over alternatives like kb_index or kb_prune. Usage context is more inferred than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show statistics about the persistent knowledge base — sessions, chunks, tags, stored knowledge, summaries, and disk usage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description indicates read-only behavior but doesn't explicitly confirm non-destructive nature or mention side effects, though it's implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence front-loaded with action and resource, listing specific statistics without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter stats tool; covers main output categories but lacks detail on output format or aggregation methods.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the schema (100% coverage). Description provides no parameter details but does not need to, as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool shows statistics about the knowledge base, listing specific categories (sessions, chunks, tags, stored knowledge, summaries, disk usage), distinguishing it from sibling tools like kb_list or kb_store.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs siblings, such as noting it's for overview or comparison with kb_list for details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a piece of knowledge in the brain. Use for facts, notes, preferences, or anything worth remembering permanently. By default, knowledge is stored globally (available across all projects). Set scope to 'project' and pass your working directory as project_dir to scope it to a specific project.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Short label for easy retrieval (e.g. 'wifi-password', 'deploy-process') | |
| tags | No | Tags for categorization | |
| scope | No | 'global' (default) = available everywhere. 'project' = scoped to a specific project directory. | global |
| source | No | Where this knowledge came from (e.g. 'manual', 'agent', 'import') | manual |
| content | Yes | The knowledge to store | |
| project_dir | No | Project directory to scope this knowledge to (only used when scope is 'project') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes persistence and scope behavior, but omits overwrite semantics (e.g., what happens if key exists) and 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first summarizes purpose and usage, second details scoping. No wasted words. Front-loaded with most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, scope, and parameter use cases. Lacks return value description (no output schema), but for a store operation this is a minor gap. Adequate given sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all params have descriptions). Description adds context for key ('short label for easy retrieval'), tags, source, and scope usage, going beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Store a piece of knowledge in the brain' and lists use cases (facts, notes, preferences). Distinguishes from siblings like kb_recall (retrieve) and kb_list (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions 'use for facts, notes, preferences' and provides guidance on scoping (global vs project). Lacks explicit alternatives or when-not-to-use, but direction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a session summary generated by the calling agent. Use this after kb_summarize returns session chunks and you have written a summary.
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | The summary text (3-8 sentences) | |
| session_id | Yes | The session ID to store the summary for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes a write operation ('store') but does not disclose whether it overwrites existing summaries, required permissions, or any side effects. This lack of behavioral detail is significant for a storage tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. It front-loads the purpose and then provides usage context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema), the description is largely complete. It covers the purpose and when to use. However, it could benefit from mentioning the return value or error behavior, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented. The description adds minimal extra meaning beyond restating 'summary' and 'session ID'. Baseline 3 is appropriate as it does not add substantial value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it stores a session summary generated by the calling agent. It uses a specific verb ('store') and identifies the resource ('session summary'). It distinguishes from siblings by requiring prior use of kb_summarize.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: after kb_summarize returns session chunks and the agent has written a summary. This provides clear context, though it does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns session chunks for the calling agent to summarize. The agent should read the chunks, write a concise summary (3-8 sentences covering what was worked on, key decisions, errors resolved, files changed, and outcome), then call kb_store_summary to save it. No API key needed — YOU are the summarizer.
| Name | Required | Description | Default |
|---|---|---|---|
| last | No | Return the last N un-summarized sessions (default: 5) | |
| session_id | No | Summarize a specific session |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It correctly identifies the operation as retrieving session chunks but does not disclose that it is read-only or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: first describes the tool's action, second provides usage instructions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions that it returns session chunks and specifies un-summarized sessions. Could be improved by describing the chunk format, but is mostly adequate for an agent that knows the KB domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The tool description adds no extra semantics beyond the schema; it only echoes the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: returns session chunks for summarization. Differentiates from sibling kb_store_summary by instructing to use that after summarizing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (to get session chunks for summarization) and gives step-by-step instructions. Lacks explicit when-not-to-use or alternatives, but is sufficient for the intended purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0kb_forgetkb_indexkb_listkb_prunekb_recallkb_reindexkb_statskb_storekb_store_summarykb_summarizeEach tool has a clearly distinct purpose: forget, index list, prune, recall, reindex, stats, store, store_summary, and summarize. Even similar operations like kb_index and kb_reindex are differentiated (single file vs. batch scanning). No ambiguity.
All tools follow the 'kb_verb[_noun]' pattern consistently. Underscore snake_case is used throughout. The verbs are appropriate and mostly single-word except 'store_summary', which is still clear and consistent.
10 tools is well-scoped for a knowledge base management server. They cover essential operations without being excessive or too sparse.
The tool set covers creating, retrieving, updating (via reindex/incremental indexing), searching, listing, forgetting, and pruning. A minor gap: there is no explicit tool to update or delete a stored summary, but the workflow allows overwriting through kb_store_summary.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for AI agents. Search, store, and recall across sessions.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Universal persistent memory and knowledge retrieval layer for AI agents and LLMs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/melvenac/open-brain-knowledge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
