Skip to main content
Glama

brief_memory

Create structured briefs by retrieving and summarizing scattered memories into indexed, reusable documents for persistent knowledge retrieval.

Instructions

Create a structured memory brief by retrieving and summarizing relevant memories, then persist it as a reusable asset indexed for future recall. Use this when you want to consolidate scattered knowledge on a topic into a single retrievable document. Side effect: writes a new brief asset to disk and indexes it in the vector store for future search.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesNatural language topic or task to brief, e.g. 'deployment pipeline architecture decisions'
limitNoMaximum number of source memories to include in the brief (default: 8)
scopeNoRestrict search to a specific scope, e.g. 'project:myapp'. Omit to use the default scope
sessionIdNoSession identifier to infer session-scoped search, e.g. 'abc123'
allScopesNoSet to true to search across all scopes instead of the default scope
profileNoRetrieval profile that tunes ranking weights: 'writing' for narrative, 'debug' for technical, 'fact-check' for high-precision
titleNoHuman-readable title for the brief asset, e.g. 'Q1 Auth Migration Summary'. Auto-generated if omitted
Behavior4/5

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

With no annotations provided, the description carries full disclosure burden. It explicitly warns of side effects: 'writes a new brief asset to disk and indexes it in the vector store for future search.' This reveals the mutation nature and persistence mechanism. Could improve by mentioning idempotency or overwrite behavior.

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?

Three sentences with zero waste: first defines the action (create/retrieve/summarize/persist), second gives usage context (consolidation), third discloses side effects. Front-loaded with core verb and resource. No redundant phrases.

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

Completeness3/5

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

Given 7 parameters and a complex multi-step operation (retrieval + summarization + persistence), the description covers the conceptual model well. However, with no output schema provided, it fails to specify what the tool returns (the brief content itself or an asset reference), which is essential for agent invocation.

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 the schema fully documents all 7 parameters (query, limit, scope, sessionId, allScopes, profile, title). The description focuses on high-level behavior rather than parameter semantics, which is appropriate given the comprehensive schema. Baseline 3 is correct.

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?

The description explicitly states the tool creates a structured memory brief by 'retrieving and summarizing relevant memories, then persist it as a reusable asset.' It clearly distinguishes this from sibling tools by emphasizing consolidation into a 'single retrievable document' versus simple storage or search.

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?

Provides explicit when-to-use guidance: 'Use this when you want to consolidate scattered knowledge on a topic into a single retrievable document.' This effectively differentiates it from search_memory (simple retrieval) and store_memory (raw storage). Lacks explicit 'when not to use' exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AliceLJY/recallnest'

If you have feedback or need assistance with the MCP directory API, please join our Discord server