Skip to main content
Glama

brain_context

Read-onlyIdempotent

Answer from the user's past: one bounded text packet to read before replying.

Instructions

Answer from the user's past: one bounded text packet to read before replying.

    The default memory call: use it whenever a request may depend on earlier conversations,
    facts, preferences, decisions or work. It returns `context`, a size-capped text of the
    relevant memories and conversation turns, each with its date and source. For structured
    rows, ids or one thing's history use brain_recall instead.

    Set `recent=true` whenever the question is about what happened lately or what the user was
    just doing: "what was I working on?", "where did we leave off?", "what did I do
    yesterday?", "최근에", "아까", "어제", "지금 뭐 하고 있었지?". Results then come newest
    first instead of by word overlap; naming something ("what did Kongi do lately") keeps them
    about that. Set `since` (ISO date or time) to drop anything earlier, e.g. "this week".
    Set `about_assistant=true` when the user asks what YOU said earlier: "which restaurant did
    you recommend?", "what were the steps you gave me?", "네가 아까 뭐라고 했지?". Your own
    past answers are then searched by meaning too, not only by their words.
    Set `around` when the question is about WHEN WE TALKED: "what did we discuss last week?",
    "지난달에 얘기한 거" -> resolve it yourself to a date or "start..end" (e.g. "2026-09-23"
    or "2026-09-01..2026-09-30"). Conversations from then rank first; nothing is dropped.
    Do not set it for when something HAPPENED ("the event I went to two weeks ago"): people
    mention events days or weeks before or after, so that date misleads (measured: on dev2
    it pushed the answering turn out in 2 of 11 questions and helped 2).

    Each conversation item is one excerpt of one turn. Never tell the user you don't know
    without first opening the item most likely to hold the answer:
    brain_recall(source=<the text after "Source: <app> / ">) returns that turn in full with
    the turns around it (your reply to that request, the rest of a list, the line before).
    Open it too when an item you rely on is cut off.
    

Input Schema

NameRequiredDescriptionDefault
as_ofNoISO time: only what had happened by then (default now).
limitNoMost items to return.
queryYesThe user's request, in their words.
sinceNo
aroundNo
policyNoauto skips requests with no sign of the past.always
recentNo
scopesNoOnly these scopes, e.g. ["global"] or a project; default all.
max_charsNoSize cap of the returned text.
about_assistantNo
knowledge_cutoffNoISO time: only what had been saved by then (default as_of).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.9.5
    • addedInput schema / properties / as_of / description
      Added value: +"ISO time: only what had happened by then (default now)."
    • addedInput schema / properties / knowledge_cutoff / description
      Added value: +"ISO time: only what had been saved by then (default as_of)."
    • addedInput schema / properties / limit / description
      Added value: +"Most items to return."
    • addedInput schema / properties / max_chars / description
      Added value: +"Size cap of the returned text."
    • addedInput schema / properties / policy / description
      Added value: +"auto skips requests with no sign of the past."
    • addedInput schema / properties / query / description
      Added value: +"The user's request, in their words."
    • addedInput schema / properties / scopes / description
      Added value: +"Only these scopes, e.g. [\"global\"] or a project; default all."
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile needs no restating. The description adds real behavioral detail beyond that: results come newest-first vs. by word overlap, `around` ranks but drops nothing, `about_assistant` searches by meaning, and each item carries date and source. However, it leaves the size-cap interaction (`max_chars`) and the `policy=auto` skip behavior to the schema, so it is strong 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.

Conciseness3/5

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

Front-loaded well: the core purpose and the sibling routing come first. But the body is long and uneven, padding with multilingual example strings and a measured ablation statistic (2 of 11 questions) that informs implementation choices rather than the calling decision, so some sentences do not earn their space.

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?

The description covers trigger conditions, return shape, the follow-up path (open an item via brain_recall when it is cut off), and the key false-negative failure mode. An output schema exists, so return structure need not be restated in full. Minor gap: the `policy`, `limit`, and `scopes` knobs and their interaction are not addressed in prose.

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 only 64%, and the description compensates for the four undocumented flags: `recent`, `since`, `about_assistant`, and `around` each get concrete trigger phrases and, for `around`, the expected value syntax ('2026-09-01..2026-09-30'). `as_of`, `limit`, `scopes`, `max_chars`, and `knowledge_cutoff` are left entirely to the schema.

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 concrete verb and resource ('answer from the user's past: one bounded text packet'), names the return field (`context`), and positions itself as 'the default memory call.' It explicitly contrasts with brain_recall for structured rows, ids, or one thing's history, so the agent can discriminate it from its closest sibling without opening a 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?

Gives the selection rule (use whenever a request may depend on earlier conversations, facts, preferences, decisions, work), names the alternative tool and its condition (brain_recall for structured rows/ids/history), and adds a case-specific negative instruction: do not set `around` for when something happened, with a stated reason. Nearly every branch is decided for the agent.

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