Skip to main content
Glama
Skitchy

Rekindle

by Skitchy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

store_memory

Persist preferences, lessons learned, project context, and relationship notes in a local SQLite database so they remain available across sessions for orientation and search.

Instructions

Store a new memory in the local SQLite database. Creates a persistent row with an auto-generated UUID, timestamp, and the provided content. Use for preferences, lessons learned, project context, relationship notes, or general information worth remembering across sessions. Memories persist across sessions and are surfaced by boot_report, search_memory, and list_memories. Returns the generated ID on success. Does not deduplicate — calling twice with the same content creates two separate memories.

Input Schema

NameRequiredDescriptionDefault
contentYesThe memory content to store. Plain text, no length limit. Should be self-contained — future retrieval may return this memory without surrounding context.
projectNoProject name to scope this memory to. When set, boot_report can filter orientation to this project. Omit for cross-project memories.
categoryNoMemory category. Determines how the memory is weighted during orientation: 'preference' and 'relationship' contribute to the orientation score. 'context' is used for checkpoints and session handoffs. 'lesson' is used for constraints and warnings. 'general' is the default catch-all.general
importanceNoImportance score from 1 (low) to 10 (critical). Higher-importance memories are ranked first in search results. Constraints default to 9, checkpoints to 8, general notes to 5.
provenanceNoWrite attribution. Required when REKINDLE_REQUIRE_WRITE_PROVENANCE=1; never proof of authorization.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.1
    • addedInput schema / properties / provenance
      Added value: +{
+  "description": "Write attribution. Required when REKINDLE_REQUIRE_WRITE_PROVENANCE=1; never proof of authorization.",
+  "properties": {
+    "author_identity": {
+      "description": "Claimed writer identity; attribution, not authentication.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "authorization_reference": {
+      "description": "Caller-supplied authority reference. Stored as unverified and never treated as authorization.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "client": {
+      "description": "Client performing the write, for attribution only.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "request_id": {
+      "description": "Unique caller request identifier.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "thread_id": {
+      "description": "Calling thread or session identifier.",
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "required": [
+    "client",
+    "thread_id",
+    "request_id",
+    "author_identity",
+    "authorization_reference"
+  ],
+  "type": "object"
+}
  2. Changed4 schema fields changedv0.3.0
    • changedInput schema / properties / category / description
      Previous value: -"Memory category"New value: +"Memory category. Determines how the memory is weighted during orientation: 'preference' and 'relationship' contribute to the orientation score. 'context' is used for checkpoints and session handoffs. 'lesson' is used for constraints and warnings. 'general' is the default catch-all."
    • changedInput schema / properties / content / description
      Previous value: -"The memory content to store"New value: +"The memory content to store. Plain text, no length limit. Should be self-contained — future retrieval may return this memory without surrounding context."
    • changedInput schema / properties / importance / description
      Previous value: -"Importance score 1-10 (higher = retrieved more often)"New value: +"Importance score from 1 (low) to 10 (critical). Higher-importance memories are ranked first in search results. Constraints default to 9, checkpoints to 8, general notes to 5."
    • changedInput schema / properties / project / description
      Previous value: -"Project scope for this memory"New value: +"Project name to scope this memory to. When set, boot_report can filter orientation to this project. Omit for cross-project memories."
  3. First observedv0.2.0

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden and does well: it discloses persistence across sessions, the auto-generated ID returned on success, and the non-deduplicating write semantics that would otherwise surprise a caller. It stops short of failure behavior or what happens to the memory lifecycle after storage.

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 what is created, then use cases, then the return value, then the dedup caveat. Dense and mostly waste-free, though the use-case list and the sibling enumeration add a little length.

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 5-parameter write tool with a nested provenance object, no annotations and no output schema, the description covers the return value (generated ID), persistence, and the non-dedup gotcha. The conditional provenance requirement is left entirely to the schema, which is a minor residual gap.

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 parameters are already fully documented, including the provenance object and the importance/category semantics. The description only references 'the provided content' and adds no additional guidance on project scoping or category selection beyond what the schema says, which is the correct baseline 3.

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+resource ('Store a new memory in the local SQLite database') and enumerates exactly what is created (UUID, timestamp, content). It also situates the tool relative to siblings by naming boot_report, search_memory and list_memories as the surfacing paths, so an agent can place it in the workflow without opening other schemas.

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?

Gives explicit usage contexts ('preferences, lessons learned, project context, relationship notes, or general information worth remembering across sessions'). The dedup caveat implicitly signals that updating an existing memory is a different operation, but it never names update_memory or states when not to use this tool.

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