Skip to main content
Glama
Sign In
xy-claude

brain-core

by xy-claude
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

brain_recall

Read-onlyIdempotent

Search long-term memory across sessions, notes, and stores to retrieve past decisions, preferences, and facts as one deduplicated, relevance-ranked result list before answering or remembering.

Instructions

Search the agent's long-term memory: facts, patterns, decisions, corrections, session notes, raw sources, entity relations and the Claude Code session transcripts of this folder, across SQLite, the markdown vault, Hindsight and the graph, returned as one deduplicated list ranked by relevance and recency and capped at about 6k tokens. scope='transcript' searches only what past sessions said and ran.

    Use it before answering anything about past sessions, earlier decisions or the user's
    preferences, and before brain_remember to avoid writing a duplicate. Not for health
    checks (brain_status) and not for reading a file you already know the path of.

    Read-only. Partial results are normal: `stores` lists hits per store and names any store
    that was unreachable instead of failing the call. A value a `⚠ Fact changed` banner
    superseded is returned but ranked below the banner.

Input Schema

NameRequiredDescriptionDefault
limitNoMax results after dedup; default 10.
queryYesFree-text search; keywords beat sentences.
scopeNo'all' (default), one kind (fact|pattern|decision|correction|note|raw|relation|transcript) or one store (sqlite|vault|hindsight|graph|transcripts).all
formatNo'concise' (default) for text to quote; 'detailed' adds ids, scores and store names for chained calls.concise

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • changedInput schema / properties / scope / description
      Previous value: -"'all' (default), one kind (fact|pattern|decision|correction|note|raw|relation) or one store (sqlite|vault|hindsight|graph)."New value: +"'all' (default), one kind (fact|pattern|decision|correction|note|raw|relation|transcript) or one store (sqlite|vault|hindsight|graph|transcripts)."
  2. Changed4 schema fields changedv0.2.6
    • addedInput schema / properties / format / description
      Added value: +"'concise' (default) for text to quote; 'detailed' adds ids, scores and store names for chained calls."
    • addedInput schema / properties / limit / description
      Added value: +"Max results after dedup; default 10."
    • addedInput schema / properties / query / description
      Added value: +"Free-text search; keywords beat sentences."
    • addedInput schema / properties / scope / description
      Added value: +"'all' (default), one kind (fact|pattern|decision|correction|note|raw|relation) or one store (sqlite|vault|hindsight|graph)."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses deduplication, relevance+recency ranking, a ~6k token cap, and that partial results are normal with a `stores` field naming unreachable stores rather than failing. It also explains the `⚠ Fact changed` supersession ranking rule, which is non-obvious behavior an agent must interpret correctly.

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?

Front-loaded with the core verb and scope, then usage guidance, then behavioral caveats — a clear three-part structure with no filler sentences. It is somewhat dense and long, but nearly every clause carries actionable information.

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

Completeness5/5

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

For a multi-store search with a full output schema, the description covers everything an agent needs to call and interpret it: scope semantics, ranking/cap, partial-failure behavior, supersession banners, and sibling routing. Return-value detail is correctly delegated to the output schema.

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?

Schema coverage is 100%, so the baseline is 3; the description adds real meaning on top by explaining that scope='transcript' searches only what past sessions said and ran, and by framing results as a single deduplicated list. It does not re-explain limit/format, but the schema already does that well.

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?

Opens with a specific verb+resource ('Search the agent's long-term memory') and enumerates exactly what content kinds and backends are covered (SQLite, markdown vault, Hindsight, graph), plus the ranking/dedup/cap behavior. An agent can immediately tell this apart from brain_remember and brain_status without inspecting the schema.

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

Usage Guidelines5/5

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

Explicit when-to-use ('before answering anything about past sessions, earlier decisions or the user's preferences, and before brain_remember to avoid writing a duplicate') and explicit when-not ('Not for health checks (brain_status) and not for reading a file you already know the path of'), naming the sibling to route to.

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