Skip to main content
Glama
cheveguerra

sqlite-local-ai-memory

by cheveguerra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

save_fact

Persist atomic facts, preferences, or technical rules into long-term memory with semantic deduplication and vector indexing. Returns a UUID and status for immediate logging.

Instructions

Persists an atomic fact, preference, or technical rule into long-term memory with automatic semantic deduplication and vector indexing (append-only write). Use for immediate logging; for search use 'search_memory', for evolution audits use 'get_fact_lineage', and for batch synthesis use 'consolidate'. Returns the assigned fact UUID and status.

Input Schema

NameRequiredDescriptionDefault
factYesThe concise fact, technical decision, architecture rule, or user preference to store (e.g. 'PostgreSQL runs on port 5432 with peer authentication'). Must be self-contained and clear without pronouns.
sourceNoProject or subsystem tag (e.g. 'HOMELAB', 'AUDIOBOOK', 'TOTALCONNECT'). Alphanumeric and underscores only. Used to partition and filter project memories.
userIdNoUser or agent namespace to scope the memory. Defaults to 'user_default' when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.2
    • changedInput schema / properties / fact / description
      Previous value: -"The fact or information to save."New value: +"The concise fact, technical decision, architecture rule, or user preference to store (e.g. 'PostgreSQL runs on port 5432 with peer authentication'). Must be self-contained and clear without pronouns."
    • changedInput schema / properties / source / description
      Previous value: -"Source or project tag, e.g. 'TOTALCONNECT', 'SQLITE_MEMORY' (optional, alphanumeric only)."New value: +"Project or subsystem tag (e.g. 'HOMELAB', 'AUDIOBOOK', 'TOTALCONNECT'). Alphanumeric and underscores only. Used to partition and filter project memories."
    • changedInput schema / properties / userId / description
      Previous value: -"Optional user ID to scope the memory fact."New value: +"User or agent namespace to scope the memory. Defaults to 'user_default' when omitted."
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it discloses append-only semantics, automatic semantic deduplication, vector indexing, and the return payload (UUID + status). It stops short of explaining what happens on a dedup hit (is the existing UUID returned, is the write rejected?) and says nothing about permissions or capacity limits, so a mutation tool is not fully transparent.

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?

Front-loaded with the action and behavior, then a compact sentence covering alternatives and returns — no wasted content. It is dense, packing four sibling references and the return contract into one sentence, which costs a little readability.

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?

For a 3-param write tool with no output schema, the description supplies the return contract (UUID and status), which is exactly what's otherwise missing. The remaining gap is the dedup outcome — an agent cannot know whether a duplicate creates a new entry, returns the existing UUID, or errors, which materially affects repeated logging.

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% and the parameter docs are already rich (format constraints, examples, defaults), so the baseline is 3. The description only adds the semantic framing that 'fact' can be a preference or technical rule, which is marginal value beyond 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?

Specific verb+resource ('Persists an atomic fact... into long-term memory') with concrete scope (atomic fact, preference, technical rule) and explicit distinguishing from siblings by naming the roles of search_memory, get_fact_lineage, and consolidate. An agent can identify this as the write path without opening any 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?

States the selection condition directly ('Use for immediate logging') and routes each alternative case to a named sibling: search_memory for search, get_fact_lineage for evolution audits, consolidate for batch synthesis. Explicit when-to-use plus alternatives.

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