Skip to main content
Glama

AiAkiv Memory

by com.aiakiv
OverviewDiscussionsAdmin

save_memory

Save a piece of conversation content to memory.

Use this when the user explicitly asks to save or record something. Do not
use it on a bare "remember this" or a request to summarize; those are not
save requests.

Writes a new record. The destination project and folder come from the active
target and cannot be set from here.

Args:
    payload: Alternative call form bundling {summary, entities, content,
        tags} into this one argument, as a JSON object or a JSON string.
        The other arguments are ignored when it is given.
    summary: The retrieval surface, required unless `payload`, up to 500
        characters. Searches rank against this rather than the content, so
        exact identifiers kept verbatim and the acting party named in the
        first sentence are what make the record findable later.
    entities: NER results [{name, type}, ...], required unless `payload`.
        One canonical spelling per entity; records connect on shared names.
    tags: List of short slash-paths. Reusing the closest paths from a prior
        response's `suggested_tags` or `tag_tree` keeps them consistent.
        Ids, hashes, and dates are soft-rejected.
    content: The original text, required unless `payload`, up to 50000
        characters. Longer text is split across calls, each passing the
        previous `event_id` as `prev_event_id`, with its own summary.
    prev_event_id: The prior call's `event_id` when this save continues it.
    allow_truncation_marker: Content carrying a truncation marker left by
        upstream tooling is refused with `truncation_marker_detected`, since
        nothing downstream can distinguish a cut body from a whole one. Set
        it True when the marker is part of what is being recorded.
    assert_project: The server refuses the save if the resolved target
        differs from this project name. It blocks, never redirects.
    timestamp: ISO 8601; defaults to the current time.
    source: Upstream origin `{provider, address, version?}` when the content
        came from outside this conversation.

Returns:
    `{event_id, tags, tag_tree, suggested_tags?, saved_entities,
    rejected_tags?, continuation_hint, edit_command, active_target}`.
    `saved_entities` and `rejected_tags` let the user correct a wrong entity
    or a dropped tag through `update_memory`. `suggested_entities` is
    advisory — a literal name match does not establish that it denotes the
    same thing here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoList of short slash-paths. Reusing the closest paths from a prior response's `suggested_tags` or `tag_tree` keeps them consistent. Ids, hashes, and dates are soft-rejected.
sourceNoUpstream origin `{provider, address, version?}` when the content came from outside this conversation.
contentNoThe original text, required unless `payload`, up to 50000 characters. Longer text is split across calls, each passing the previous `event_id` as `prev_event_id`, with its own summary.
payloadNoAlternative call form bundling {summary, entities, content, tags} into this one argument, as a JSON object or a JSON string. The other arguments are ignored when it is given.
summaryNoThe retrieval surface, required unless `payload`, up to 500 characters. Searches rank against this rather than the content, so exact identifiers kept verbatim and the acting party named in the first sentence are what make the record findable later.
entitiesNoNER results [{name, type}, ...], required unless `payload`. One canonical spelling per entity; records connect on shared names.
timestampNoISO 8601; defaults to the current time.
prev_event_idNoThe prior call's `event_id` when this save continues it.
assert_projectNoThe server refuses the save if the resolved target differs from this project name. It blocks, never redirects.
allow_truncation_markerNoContent carrying a truncation marker left by upstream tooling is refused with `truncation_marker_detected`, since nothing downstream can distinguish a cut body from a whole one. Set it True when the marker is part of what is being recorded.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses key write behavior: it creates a new record, the target project/folder is fixed by the active target, truncated content is refused unless explicitly allowed, and long content must be split with prev_event_id. It also clarifies that assert_project blocks rather than redirects. This gives the agent strong behavioral expectations.

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 long but every section earns its place: purpose, usage boundary, parameter semantics, and return-value interpretation. It is logically ordered and front-loaded with the core use case. The length is justified by 10 parameters and nuanced policies.

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 10-parameter write tool with an output schema, the description is essentially complete: required-alternation rules, error/refusal cases, destination control, continuation handling, and return interpretation via update_memory are all covered. There is a minor naming inconsistency between suggested_tags and suggested_entities, but it does not leave a material gap for invoking the tool correctly.

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

Parameters5/5

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

Though schema coverage is 100%, the description adds substantial semantic value: summary is the retrieval surface with ranking implications, entities require one canonical spelling, tags soft-reject ids/hashes/dates, payload overrides other arguments, and continuation semantics are explained. This exceeds the baseline for already-covered schemas.

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 clearly states the verb ('save') and resource ('conversation content to memory'), and explicitly contrasts with excluded cases like a bare 'remember this' or a summarization request. This distinguishes it well from sibling tools such as update_memory, search_memory, and describe_memory_schema.

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?

It explicitly specifies when to use the tool ('when the user explicitly asks to save or record something') and when not to ('bare remember this' or 'request to summarize'). It does not name alternative sibling tools for those exclusions, but the guidance is unambiguous and actionable.

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

All AiAkiv Memory toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources