SLayer

Overview Schema Source Related Servers Discussions Admin

save_memory

Persist a free-form note linked to SLayer entities or a query, making agent learnings discoverable through future searches.

Instructions

Save an agent memory: a free-form note plus the SLayer entities it concerns.

linked_entities accepts either:

a list of entity reference strings — each item is resolved to the canonical <datasource>.<model>[.<leaf>] form. Bare names use the datasource priority list; ambiguous bare-column matches are rejected. memory:<id> is also valid here (cross-memory references; the target memory must exist).
a SlayerQuery (dict) — entities are auto-extracted from source_model, dimensions, time_dimensions, measures, and filters; resolution warnings are non-fatal. The query itself is stored alongside the learning, so the memory surfaces in search's example_queries list (vs the memories list for entity-list memories).

DEV-1428: id is an optional canonical memory id. Omit to auto-allocate a monotonic int-shaped id ("1", "2", ...); supply a string for a stable user-controlled id ("kb.policy.42"). Charset excludes :, /, ?, #, whitespace. Duplicate id → unconditional upsert, created_at preserved.

Returns the assigned memory_id (string), the canonical entities stored, and any non-fatal warnings.

Cascade-on-delete: when a model / datasource / measure is deleted, every memory:<id> and <ds>.<model>[.<leaf>] reference under it is automatically stripped from every other memory's entities list. Memories with zero entities after the strip are kept (the learning text stands alone).

Search is lenient: stale entity tags in saved memories are filtered out at retrieval time rather than raising.

Args: learning: The note text. Required, non-empty. linked_entities: List of entity strings, or an inline SlayerQuery payload. id: Optional canonical memory id (see above).

Examples: save_memory( learning="orders.is_returned in {0,1,NULL}; treat NULL as not returned", linked_entities=["orders.is_returned"], )

save_memory(
    learning="Paid revenue by status",
    linked_entities={
        "source_model": "orders",
        "measures": [{"formula": "sum(amount)"}],
        "filters": ["status = 'paid'"],
    },
    id="kb.paid-revenue",
)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No
`learning`	Yes
`description`	No
`linked_entities`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.10.0Sep 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers extensively. It discloses upsert semantics, id auto-allocation rules, charset restrictions, cascade-on-delete behavior, lenient stale-tag filtering, and non-fatal resolution warnings. This is far beyond what an agent could infer from the schema alone.

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?

The description is long but well-organized, with a leading one-sentence summary followed by clearly scoped sections and practical examples. The length is justified by the absence of annotations and schema descriptions, though a few sections could be tightened without losing value.

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 complex tool with no annotations and rich schema, the description covers purpose, input forms, id behavior, deletion side effects, search integration, and return values. The only notable omission is the optional description parameter, but overall the agent has everything needed to invoke the tool correctly and anticipate consequences.

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 description coverage is 0%, so the description must compensate, and it thoroughly explains learning, linked_entities, and id, including accepted formats, edge cases, and examples. However, the schema also exposes a 'description' parameter that the description never mentions, leaving one of the four parameters undocumented.

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 opens with a precise verb and resource: 'Save an agent memory: a free-form note plus the SLayer entities it concerns.' It distinguishes the tool from siblings like search and forget_memory, and even explains where saved memories surface in search's results, making its role unambiguous.

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 provides strong context for when to save a memory, including two distinct input modes (entity list vs SlayerQuery) and explains that query-based memories appear in search's example_queries list. It does not explicitly name alternatives or state when not to use this tool, but the save-versus-search/forget relationship is clear from context.

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