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., "@local-brain-mcp what recurring bugs have we fixed in the auth module?"
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.
Local-first, Git-aware persistent memory for AI coding assistants.
Local Brain is a lightweight Model Context Protocol (MCP) server that indexes your repository's Git history and manual engineering decisions into an embedded SQLite vector database. It equips AI coding assistants (Claude Code, Cursor, GitHub Copilot, Windsurf, Zed) with long-term codebase memory—100% offline, zero egress, and zero cloud API keys.
Problem with cloud AI memory tools | How local-brain solves it |
🐌 150–800ms network latency per recall | ⚡ < 5ms — local SQLite vector search |
☁️ Your code sent to foreign servers | 🔒 100% on-device, zero egress |
💸 Token bloat on every session | 📦 Hard 250-token budget cap per recall |
🗑️ Stale outdated context from old decisions | 🔄 Git-diff invalidation marks old memories STALE |
🌊 WIP/typo commits pollute the brain | 🎯 Quality filter keeps only high-signal lessons |
🏗️ Monorepo noise across packages | 🎯 Path-scoped queries, per-package namespacing |
🔁 Duplicate memories waste tokens | 🧬 Smart deduplication + merge on ingest |
🤷 No record of how a decision evolved | 🔍 Full memory lineage with |
Related MCP server: Heimdall MCP Server
# 1. Navigate to your Git repository
cd /path/to/your-project
# 2. Auto-detect installed AI editors and link MCP configuration
npx local-brain init
# 3. Ingest your Git history into the local brain database
npx local-brain ingest
# 4. Check memory database statistics
npx local-brain status
# 5. Restart your AI editor (Claude Code, Cursor, Copilot, Windsurf, Zed)All tools carry MCP 1.5 annotations (readOnlyHint, destructiveHint, idempotentHint) so hosts can show confirmation dialogs before destructive operations.
brain_recallSemantic search your codebase memory. Results ranked by a composite score (similarity 45%, scope 20%, recency 10%, confidence 10%, importance 10%, quality 5%) and capped to 250 tokens.
{
"mcpServers": {
"local-brain": {
"command": "node",
"args": ["/absolute/path/to/local-brain-mcp/dist/mcp-server.js"],
"env": {}
}
}
}The Model Context Protocol (MCP) is an open standard created by Anthropic that allows AI applications (like Claude or Cursor) to securely interact with local tools and data sources.
┌─────────────────────────┐
│ AI Coding Assistant │
└───────────┬─────────────┘
│ Tool Invocation (JSON-RPC over stdio)
▼
┌─────────────────────────┐
│ Local Brain MCP │
└───────────┬─────────────┘
│ Parameterized SQL
▼
┌─────────────────────────┐
│ Embedded SQLite DB │
└─────────────────────────┘Local Brain runs locally as a background process over standard input/output (stdio). The AI invokes Local Brain tools whenever it needs to recall past lessons or remember new rules.
brain_recallSemantically searches codebase memories relevant to the query and optional file scope.
Type: Read-only
When to use: Before refactoring, fixing bugs, or implementing features to check if relevant lessons or constraints exist.
Parameters:
Parameter | Type | Required | Description |
|
| Yes | What to search for (max 1000 characters). |
|
| No | Repo-relative file path to scope the query (e.g. |
|
| No | Maximum memories to return (1–20, default: 5). |
|
| No | Filter by category: |
Example Input:
{
"query": "JWT token expiration bug",
"file_path": "src/auth/jwt.ts",
"max_items": 3
}Example Output:
## Brain Recall: "JWT token expiration bug"
• [src/auth/jwt.ts @ 8a4f12] (fix): JWT refresh race condition — RS256 cert rotates every 24h. Cache public keys with 1h TTL.
• [src/auth/session.ts @ c31d04] (bug): Sessions expire silently on Tuesday UTC maintenance window.brain_learnManually store a lesson or team convention with quality assessment. Low-signal content (shell noise, one-liners) is automatically filtered.
Type: Write
When to use: When you or the AI discover a crucial rule, edge case, or convention that is not documented in git commits.
Parameters:
Parameter | Type | Required | Description |
|
| Yes | Actionable lesson or decision (max 10000 characters). |
|
| No | Category: |
|
| No | Associated file path (e.g. |
|
| No | Importance multiplier between 0.5 and 2.0 (default: 1.0). |
Example Input:
{
"lesson": "Always use parameterized prepared statements in better-sqlite3 to prevent injection.",
"category": "convention",
"file_path": "src/db/queries.ts",
"importance": 1.5
}brain_traceFull chronological history of all memories for a specific file, including superseded and deprecated entries.
Type: Read-only
When to use: When investigating the maintenance history or past regressions of a specific source file.
Parameters:
Parameter | Type | Required | Description |
|
| Yes | Repo-relative file path (e.g. |
Example Input:
{
"file_path": "src/db.ts"
}brain_forgetPermanently remove or deprecate a specific memory by ID (idempotent).
{
"id": 42,
"hard_delete": false
}brain_pruneRemove stale/deprecated memories in bulk. Optionally triggers a full git-diff invalidation pass.
Type: Destructive Write
When to use: After major refactors or codebase rewrites to purge outdated knowledge.
Parameters:
Parameter | Type | Required | Description |
|
| No |
|
|
| No | If true, runs a git invalidation pass first (default: |
Example Input:
{
"status": "stale",
"run_invalidation": true
}brain_statusReturns health diagnostics: memory counts by status, DB size, schema version, oldest/newest entries.
{}local-brain init # setup wizard — writes MCP config for all detected editors
local-brain ingest # scan git history and build the brain DB
local-brain ingest --since "6 months ago" --verbose
local-brain status # show DB memory counts and diagnostics
local-brain prune --invalidate # detect + remove stale memories
local-brain learn "lesson text" --category convention --file src/db/client.ts
local-brain trace --file src/db/client.ts
local-brain forget --id 42git history
↓
[git-ingest.ts] — filters WIP/typo/format commits + quality assessment
↓ duplicate?
[db.ts] — findDuplicateMemory → smart merge (preserves richest summary)
↓
[embeddings.ts] — pure-JS TF-IDF feature hashing (384-dim, sub-1ms, zero network)
↓
[db.ts] — stores in .git/brain.db (provenance: author, branch, confidence, importance)
↓ (on file change)
[invalidation.ts] — marks stale if file changed > 30% (multi-file array support)
↓ (on MCP tool call)
[recall.ts] — cosine similarity + multi-factor ranking, scoped to package, capped to 250 tokens
↓
Claude Code / Cursor / Copilot / Windsurf / Zedrank_score = (similarity × 0.45)
+ (scope_boost × 0.20)
+ (recency × 0.10)
+ (confidence × 0.10)
+ (importance × 0.10)
+ (quality × 0.05)
× status_multiplier (active=1.0, stale=0.25, deprecated=0.05)inserted (active)
→ stale (git-diff invalidation if file changed > 30%)
→ deprecated (superseded by newer memory or manual forget)
→ deleted (hard prune)Each memory stores:
Field | Description |
| Raw commit message or lesson text |
| Distilled one-liner (merged on dedup) |
| Canonical file(s) this memory belongs to |
| Git commit author |
| Branch at ingest time |
| SHA of the commit |
| Float 0–1, updated on merge |
| Float, boosted by quality signals |
|
|
| FK to the memory that replaced this one |
| Float output of quality assessment |
local-brain-mcp/
├── src/
│ ├── cli.ts # Command-line interface and setup wizard
│ ├── db.ts # SQLite database management and migrations
│ ├── embeddings.ts # Code-aware TF-IDF feature hashing vectorizer
│ ├── git-ingest.ts # Commit filtering and git ingestion pipeline
│ ├── invalidation.ts # Git-diff staleness detection engine
│ ├── mcp-server.ts # MCP server definition and tool handlers
│ ├── recall.ts # Multi-factor ranking and token-capped search
│ ├── schema.sql # Core SQLite table schemas and triggers
│ └── scoping.ts # Monorepo package scope and path sanitization
├── tests/
│ ├── mcp-tools.test.js # MCP protocol and tool integration tests
│ ├── embeddings.test.js # Vectorizer and cosine math unit tests
│ ├── recall-ranking.test.js # Multi-factor ranking algorithm tests
│ ├── scoping.test.js # Monorepo scope and path security tests
│ ├── security.test.js # SQL injection and path traversal tests
│ ├── invalidation.test.js # Diff parsing and threshold tests
│ └── git-ingest.test.js # Commit filter regex and classifier tests
├── scripts/
│ ├── benchmark.mjs # Performance benchmark runner
│ ├── copy-schema.mjs # Build step copying SQL schema to dist
│ └── evaluate-retrieval.mjs # Information Retrieval evaluation runner
├── .github/workflows/ci.yml # Multi-version Node.js CI workflow
├── package.json
├── tsconfig.json
└── README.mdRun npx local-brain init to re-apply editor configurations.
Verify that your editor was completely restarted.
Check that node is available in your system PATH.
Ensure git history has been ingested: npx local-brain ingest.
Check database status: npx local-brain status.
If working in a subdirectory, check monorepo package scoping.
If a file had substantial changes (>30% lines), its memories are automatically marked stale.
Run npx local-brain prune --invalidate to clean outdated records and re-run npx local-brain ingest.
# Clone the repository
git clone https://github.com/cosmiccoder200x-sys/local-brain-mcp.git
cd local-brain-mcp
# Install dependencies
npm install
# Type check
npm run typecheck
# Build TypeScript to dist/
npm run build
# Run unit and integration tests
npm test
# Run performance benchmarks
npm run benchmark
# Run retrieval quality evaluation
npm run evalQ: Does Local Brain send code to the cloud?
A: No. Local Brain is 100% offline and makes zero external network requests.
Q: Do I need an OpenAI or Anthropic API key to run it?
A: No. Local Brain uses a built-in pure-JavaScript feature-hashing embedding engine.
Q: Where is the memory database saved?
A: In <your-repo>/.git/brain.db (or ~/.config/local-brain/brain.db outside git repos).
Q: Does it work with monorepos?
A: Yes. Local Brain auto-detects package boundaries (e.g. packages/auth, apps/web) and scopes recalls accordingly.
Protocol: @modelcontextprotocol/sdk (StdioServerTransport)
Storage: better-sqlite3 (SQLite WAL mode, BLOB float32 vectors)
Embeddings: Pure-JS TF-IDF feature hashing (384-dim, sub-1ms, 100% offline)
Git Engine: simple-git
CLI Engine: commander
Suite | Tests | Status |
MCP Tool Annotations | 8 | ✅ pass |
Database & Migrations | 4 | ✅ pass |
Deduplication & Smart Merge | 4 | ✅ pass |
Quality Assessment | 3 | ✅ pass |
Memory Supersession | 2 | ✅ pass |
MCP Server Lifecycle (integration) | 7 | ✅ pass |
Adversarial Retrieval (18 cases A–R) | 18 | ✅ pass |
npm test # runs all suitesMIT — build freely.
Remove or deprecate specific memories from Local Brain. Can target a memory by ID, file path, or search query. By default deprecates the memory to maintain audit trail; pass hard_delete: true to purge.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Exact memory ID to forget. | |
| query | No | Forget memories matching this text/topic. | |
| file_path | No | Forget all memories associated with this file path. | |
| hard_delete | No | If true, permanently deletes records from SQLite. Default is false (marks deprecated). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, idempotentHint=true), the description clearly discloses the soft-delete default, the audit-trail rationale, and the hard_delete behavior that purges records. It adds meaningful context about what happens to the data without contradicting the annotations.
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 dense sentences with no filler. The core action and targeting options come first, followed by the destructive/soft-delete distinction that matters most for a destructive tool.
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?
The description covers the main action, selectors, and default vs purge behavior, and the annotations cover safety. It is still missing guidance on whether at least one target selector is required, whether selectors are mutually exclusive, and what the tool returns or reports after forgetting.
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 schema already documents id, query, file_path, and hard_delete. The description usefully recasts them as targeting strategies and explains the default behavior of hard_delete, but it does not add details beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb phrase ('Remove or deprecate specific memories') and a clear resource ('Local Brain'), then names three targeting modes (ID, file path, search query). This makes it distinct from its sibling retrieval and pruning tools even though no sibling is named.
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 intended use is implied: call this when you need to forget memories, choosing an ID, file path, or query. However, it does not explicitly contrast with tools like brain_prune or brain_learn, and it does not state whether one selector is required or how to choose among the three when several apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a new durable lesson, architecture decision, bug root-cause, or team convention. Includes automatic quality evaluation, deduplication, provenance tracking, and supersession. Examples: "Never use RS256 in dev", "JWT refresh token expires in 7d; rotate on each use".
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | Optional: array of related files. | |
| lesson | Yes | The lesson, rule, or decision to remember. Be specific and actionable. | |
| category | No | Category for this memory. | manual |
| file_path | No | Optional: the primary file this lesson applies to. | |
| confidence | No | Confidence rating from 0.0 to 1.0 (default: 1.0). | |
| importance | No | Importance multiplier from 0.1 to 2.0 (default: 1.0). | |
| supersedes_id | No | Optional: ID of an older memory that is superseded/replaced by this new lesson. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no useful annotation hints (all false), the description carries the behavioral burden. It discloses several non-obvious behaviors: automatic quality evaluation, deduplication, provenance tracking, and supersession. However, it does not explain the consequences of supersession (e.g., whether it modifies or deletes existing memories) or what happens when deduplication triggers. This is a reasonable but incomplete disclosure.
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 three sentences: purpose, feature summary, and examples. It front-loads the core action and keeps the feature list compact. The examples are useful and relevant, though slightly redundant with the category list.
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?
The description names key behaviors (evaluation, dedup, provenance, supersession) but omits practical details an agent needs: return value or confirmation, failure modes (e.g., low-quality lesson rejected), and the exact side effects of supersedes_id. Given seven parameters, no output schema, and no annotation safety signals, this is a moderate gap.
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 schema already documents all seven parameters. The description does not add parameter-level meaning beyond the schema; it only provides example lessons, which are illustrative but not tied to specific parameters. Baseline 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 states a clear action ('Store') and a specific resource ('a new durable lesson, architecture decision, bug root-cause, or team convention'), with concrete examples. It does not explicitly differentiate from sibling tools like brain_recall or brain_forget, but the storage-oriented wording makes the distinction obvious.
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 the tool: when you have a lesson, decision, root-cause, or convention to persist. It does not explicitly say when not to use it, nor does it point to alternatives (e.g., use brain_recall to retrieve). Examples help, but exclusion guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clean up stale or deprecated memories from the brain. Run this after major refactors to prevent outdated context from polluting recalls. Optionally runs the full git-diff invalidation pass to detect modified/deleted files.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Which memories to remove. | stale |
| run_invalidation | No | If true, run the full git-based stale detection pass first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the mutating nature by saying 'clean up' and 'remove,' matching the destructiveHint annotation. It also adds useful context beyond the annotations by explaining the optional git-diff invalidation pass that detects modified/deleted files.
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 compact and front-loaded: it states the core purpose in the first sentence and provides the key usage trigger in the second. Every sentence earns its place with no redundant detail.
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 low complexity (2 optional parameters, no output schema) and the destructiveHint annotation, the description is complete enough for an agent to invoke it correctly. It covers what is removed, when to run it, and the optional invalidation behavior.
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 schema already documents both parameters. The description adds modest context by elaborating on the invalidation pass as git-diff based, but it does not substantially expand parameter meaning beyond what the schema provides.
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 a specific verb ('clean up'), resource ('memories'), and scope ('stale or deprecated'). It does not explicitly differentiate from sibling brain_forget, but the stale/deprecated framing and git invalidation context make the role reasonably distinct.
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 gives explicit timing guidance: 'Run this after major refactors.' It explains the benefit of preventing outdated context from polluting recalls, but it does not explicitly state when to prefer brain_forget or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantically search your local codebase memory. Returns the most relevant lessons, bug fixes, architecture decisions, and conventions from your git history and AI sessions — filtered to current file and package scope. Results are ranked deterministically and token-capped to stay within 250 tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to search for. Plain English, e.g. "JWT auth bug" or "database connection pooling". | |
| category | No | Optional: filter by memory category. | |
| file_path | No | Optional: current file path (repo-relative). Narrows search to relevant file and package scope. | |
| max_items | No | Maximum memories to return (default: 5, max: 10). | |
| min_confidence | No | Optional: minimum confidence threshold (0.0 to 1.0, default: 0.0). | |
| include_deprecated | No | Optional: include stale and deprecated memories (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it readOnly, idempotent, and non-destructive, and the description adds genuinely new behavioral detail: results are 'ranked deterministically' and 'token-capped to stay within 250 tokens', plus the current file/package scoping behavior. It also names the memory sources (git history and AI sessions), which the schema does not convey.
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?
Three sentences, front-loaded with the primary action and then adding return contents, scoping, and output constraints. Every sentence adds a distinct piece of information with 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 read-only search tool with no output schema, the description is self-sufficient: it states the source corpus, optional scope filter, result ranking determinism, and the 250-token cap. Combined with fully documented parameters, an agent has everything needed to decide whether and how to call it.
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 schema already documents all six parameters, including defaults and enums. The description adds context about search scope and result types but no per-parameter semantics that the schema doesn't already provide; the baseline 3 applies.
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 opens with 'Semantically search your local codebase memory', a specific verb-resource pair, and enumerates the content types returned: lessons, bug fixes, architecture decisions, and conventions. This clearly distinguishes it from sibling write/delete/lifecycle tools like brain_learn, brain_forget, and brain_prune.
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?
It gives clear context—use when you need to retrieve prior lessons or decisions from git history and AI sessions, optionally scoped to the current file/package—without explicitly naming exclusions or alternatives. It lacks an explicit 'when not to use' or a comparison to brain_trace, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get system diagnostics and memory statistics for Local Brain. Returns memory count, breakdown by status (active/stale/deprecated), source breakdown (git vs manual), and database storage path.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context by listing the returned diagnostics, but it doesn't disclose additional behavioral traits like authentication needs, freshness guarantees, or potential failure modes.
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 action-first sentence with no filler. Every clause adds distinct value: the operation, the resource, and the specific output categories.
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 zero-parameter diagnostic tool with thorough safety annotations, the description is complete. It covers the important return categories even without an output schema, and nothing critical appears missing for an agent to decide to call it.
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 tool has no parameters, so the description doesn't need to explain parameter semantics. The baseline of 4 applies because there is no parameter burden to address.
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 states a specific verb ('Get'), a clear resource ('system diagnostics and memory statistics for Local Brain'), and enumerates the exact return categories. This clearly distinguishes it from sibling memory-operation tools like brain_recall, brain_learn, brain_forget, and brain_prune.
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 clearly implies use when the agent needs system diagnostics or memory statistics rather than memory operations. It doesn't explicitly name alternatives or exclusion conditions, but for a zero-parameter status tool the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show all memory entries associated with a specific file. Returns the full fix history, architecture decisions, and past bugs for that file in chronological order. Includes confidence and status flags.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Repo-relative file path to trace (e.g. "src/auth/jwt.ts"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral detail beyond those annotations: results are chronological, include confidence and status flags, and cover fix history, architecture decisions, and past bugs. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The main action is front-loaded, and supporting details about return contents, ordering, and flags are packed efficiently.
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 simple single-parameter schema, rich annotations, and no output schema, the description is complete. It tells the agent what the tool returns, how it is ordered, and what kinds of memory entries are included.
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% and the single parameter file_path is clearly documented with an example. The description adds little beyond the schema, but it does reinforce that the parameter selects a specific file for tracing. Baseline 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 and resource: 'Show all memory entries associated with a specific file.' It also distinguishes this tool from siblings by framing it as a file-scoped trace of fix history, architecture decisions, and past bugs.
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 clearly implies when to use the tool: when you need all memory entries tied to a specific file, in chronological order. It does not explicitly name alternatives or exclusions, but the file-scoped framing and sibling names like brain_recall make the intended use reasonably clear.
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.
v1.1.0brain_forgetbrain_learnbrain_prunebrain_recallbrain_statusbrain_traceEach tool has a distinct primary role: status, semantic recall, storing, file-scoped tracing, targeted forgetting, and bulk pruning. Some overlap exists between recall and trace (both retrieve memories) and between forget and prune (both deprecate), but the descriptions clarify scope well enough.
All tool names follow the same brain_<verb> pattern using simple, consistent lowercase verbs. The naming convention is uniform and predictable across the entire set.
Six tools is well-scoped for a memory management server. Each tool covers a distinct phase of the memory lifecycle: store, recall, trace, deprecate, prune, and inspect.
The core memory lifecycle is covered: learn creates, recall/trace read, forget/prune delete or deprecate, and status reports health. There is no dedicated explicit update-by-ID tool, but supersession during learn and deprecation via forget provide reasonable workarounds.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Your company's brain for AI agents. Cited, permission-aware knowledge across every system.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cosmiccoder200x-sys/local-brain-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
