Skip to main content
Glama
cosmiccoder200x-sys

local-brain-mcp

by cosmiccoder200x-sys
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

brain_recall

Read-onlyIdempotent

Search your local codebase memory to surface relevant lessons, bug fixes, architecture decisions, and conventions from git history and AI sessions, filtered by file or package scope.

Instructions

Semantically search your local codebase memory across all agents. 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 with validation boost and contradiction penalties, token-capped to stay within 250 tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesWhat to search for. Plain English, e.g. "JWT auth bug" or "database connection pooling".
categoryNoOptional: filter by memory category.
file_pathNoOptional: current file path (repo-relative). Narrows search to relevant file and package scope.
max_itemsNoMaximum memories to return (default: 5, max: 10).
agent_filterNoOptional: filter memories created by a specific agent (e.g. "claude-code", "cursor", "antigravity").
min_confidenceNoOptional: minimum confidence threshold (0.0 to 1.0, default: 0.0).
include_deprecatedNoOptional: include stale and deprecated memories (default: false).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.3.1
    • addedInput schema / properties / agent_filter
      Added value: +{
+  "description": "Optional: filter memories created by a specific agent (e.g. \"claude-code\", \"cursor\", \"antigravity\").",
+  "type": "string"
+}
  2. First observedv1.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already provide read-only, idempotent, and non-destructive hints, so the description correctly avoids repeating them. It adds meaningful behavioral detail beyond those hints: deterministic ranking, validation boost and contradiction penalties, token-capped output, and file/package scoping.

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 compact and front-loaded: the first sentence states the core purpose, and the second sentence adds ranking and output constraints. There is no filler, repetition of schema details, or redundant annotation restatement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with full schema coverage and strong safety annotations, the description covers purpose, memory sources, scoping, ranking behavior, and output size limit. It does not describe the exact return shape, but the absence of an output schema is partially mitigated by the explicit statement of what is returned and the token cap.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter already has a meaningful description, default, or enum. The description's mention of 'current file and package scope' reinforces the file_path parameter, but it does not add significant new semantics beyond what the schema already documents.

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

Purpose4/5

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

The description clearly identifies an action ('semantically search') and a resource ('local codebase memory'), and it specifies the kinds of content returned: lessons, bug fixes, architecture decisions, and conventions. It distinguishes itself from write/delete siblings like brain_learn and brain_forget, but it does not explicitly contrast with potentially similar siblings like brain_trace or brain_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when the tool applies: retrieving relevant memories across agents, from git history and AI sessions, scoped to the current file/package. It does not explicitly name alternatives or provide when-not-to-use conditions, but the retrieval intent is clear enough to guide selection among the memory-management siblings.

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

Deploy Server

Other Tools