Skip to main content
Glama
Sign In
Aletheia

Aletheia

by mohamed-ashraf-elsaed
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Save a memory

save_memory
Idempotent

Store a durable memory such as a decision, gotcha, convention or fix so every connected tool can find it later. Secrets are redacted before storage, and duplicate saves return the existing id.

Instructions

Store one durable memory (a decision, gotcha, convention or fix) that every connected tool can later find. Secrets in the text are redacted before storage. Saving the same project, title and text again is a no-op and returns the existing id. Use work_state_write for a running to-do list and add_rule for a standing instruction. Returns "Saved as #id in project." or "Already saved as #id.".

Input Schema

NameRequiredDescriptionDefault
textYesThe memory body, up to 20000 characters. Required.
typeNoMemory type. Default note.
titleNoShort headline, up to 400 characters. Default: the first 100 characters of text.
pinnedNoList the memory under Pinned in session_start_context. Default false.
projectNoProject key to file the memory under. Default: the project of the server's working directory, else "default".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.3
    • addedInput schema / properties / pinned / description
      Added value: +"List the memory under Pinned in session_start_context. Default false."
    • addedInput schema / properties / project / description
      Added value: +"Project key to file the memory under. Default: the project of the server's working directory, else \"default\"."
    • addedInput schema / properties / text / description
      Added value: +"The memory body, up to 20000 characters. Required."
    • addedInput schema / properties / title / description
      Added value: +"Short headline, up to 400 characters. Default: the first 100 characters of text."
    • addedInput schema / properties / type / description
      Added value: +"Memory type. Default note."
  2. First observedv0.1.2

TDQS

A4.9/5.0
Behavior5/5

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

Adds behavior the annotations cannot express: secrets are redacted before storage, and duplicate project+title+text submissions are a no-op returning the existing id. Also gives the exact return strings, filling the gap left by the absence of an output schema.

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?

Four short sentences, front-loaded with the core action, then constraints, then alternatives, then return values. No sentence is filler, and the return-value sentence earns its place because there is no output schema.

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?

Covers scope, redaction, idempotency semantics, sibling routing and return format for a 5-parameter mutation tool with no output schema. Nothing an agent needs in order to call it correctly is missing.

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, but the description adds real meaning by identifying the dedupe key (project + title + text), which is not derivable from the schema. Minor inconsistency: "convention" is listed as a memory kind in prose but is not a value in the type enum, which could mislead an agent choosing a type.

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?

States a specific verb and resource ("Store one durable memory") and enumerates what qualifies (decision, gotcha, convention, fix) plus the cross-tool reach. An agent can tell this apart from add_rule and work_state_write 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?

Explicitly routes adjacent intents to siblings: work_state_write for a running to-do list, add_rule for a standing instruction. That is a concrete when-not-to-use statement naming the alternatives, not an implied one.

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