Skip to main content
Glama

knowmind_store_memory

Persists a single durable fact, decision, preference, or event as a new memory entry with graph relations, making it recallable later.

Instructions

Store durable insights the moment they arise - decisions, preferences, facts, results, appointments. Persists one memory entry in the tenant corpus (Postgres + vector index + graph node), afterwards findable via knowmind_recall and knowmind_list_recent. Always creates a new entry; an earlier entry with the same title stays valid, because titles do not identify entries here (to supersede, use knowmind_update_fact, or knowmind_upload_document, which replaces by title); sha-identical content is detected as idempotent (unchanged). Returns the new memory id. Use for a single short fact; for long or multi-fact text use knowmind_upload_document. GIVE THE EDGES ALONG: whatever the text says about people, organisations, projects, hosts or technologies belongs into relations in THIS call - name the counterpart, the server creates its node and the edge, no second call needed. A memory without edges is a note; with edges it becomes a graph that answers questions nobody wrote down. Use knowmind_link separately only to connect two entries that already exist. ENTRIES ARE NEVER HARD-DELETED, they are superseded: correct a fact with knowmind_update_fact, remove an edge with knowmind_unlink_entities. Both keep the history auditable, which is the point of this store - what was true when, and when that changed. Requires write scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoFree-text keywords for later filtering (lowercase, no spaces recommended).
titleNoShort human-readable title (a few words). Not a uniqueness key - duplicate titles create separate entries.
domainNoKnowledge domain this entry belongs to, by its short key (e.g. 'sales', 'engineering'). Unknown keys are ignored and the entry stays unassigned - it is never guessed into a domain.
sourceNoWhere this came from - URL, file path, or a short note. Free text, stored for provenance.
contentYesThe memory text. Keep it to one atomic fact per entry so it stays retrievable and updatable.
relationsNoEdges from this entry to the things it talks about - set them HERE, in the same call. Name the counterpart in plain words; the server finds or creates its node and draws the edge, so you need neither knowmind_recall nor knowmind_entity nor knowmind_link for it. Example: storing 'Anna Meier leitet die IT bei der Muster GmbH' carries [{predicate: 'WORKS_FOR', object: 'Muster GmbH', object_class: 'Organization'}]. An entry without edges is a note; with edges it answers questions nobody wrote down. Allowed predicate values: ABOUT (Contract|Document|FileResource → Topic), ASSIGNED_TO (ActionRecord|Task → Agent|Organization|Person|SoftwareAgent), CLIENT_OF (Agent|Organization|Person|SoftwareAgent → Organization), CONTACT_PERSON_FOR (Person → Organization), COVERED_BY (Topic → Contract|Document|FileResource), DELIVERED_AS (Application → Product), DELIVERED_BY (Product → Application), DEPENDS_ON (Application → Application), DEPLOYED_TO (Application → Container), DEVELOPED_BY (Application → Agent|Organization|Person|SoftwareAgent), DEVELOPS (Agent|Organization|Person|SoftwareAgent → Application), ENABLES (Application → Application), FOR_CLIENT (Project → Agent|Organization|Person|SoftwareAgent), HAS_ASSIGNED_TASK (Agent|Organization|Person|SoftwareAgent → ActionRecord|Task), HAS_CHILD (Person → Person), HAS_CLIENT (Organization → Agent|Organization|Person|SoftwareAgent), HAS_CONTACT_PERSON (Organization → Person), HAS_EMPLOYEE (Organization → Person), HAS_OPERATED_APPLICATION (Agent|Organization|Person|SoftwareAgent → Application), HAS_PARENT (Person → Person), HAS_PREDECESSOR (ActionRecord|Project|Task → ActionRecord|Project|Task), HAS_PROJECT (Agent|Organization|Person|SoftwareAgent → Project), HAS_ROLE (Person → Role), HAS_SIBLING (Person → Person), HAS_SKILL (Agent|Organization|Person|SoftwareAgent → Skill), HAS_SUCCESSOR (ActionRecord|Project|Task → ActionRecord|Project|Task), HOSTED_ON (Container → Host), HOSTS (Host → Container), HOSTS_APPLICATION (Container → Application), INFRASTRUCTURE_PROVIDED_BY (Host → Organization), INTEGRATES_WITH (Application → Application), IS_LED_BY (Organization → Person), KNOWS (Person → Person), LEADS (Person → Organization), OPERATED_FOR (Application → Agent|Organization|Person|SoftwareAgent), PAID_BY (Agent|Organization|Person|SoftwareAgent → Agent|Organization|Person|SoftwareAgent), PARTNER_OF (Organization → Organization), PAYS (Agent|Organization|Person|SoftwareAgent → Agent|Organization|Person|SoftwareAgent), PRODUCED_BY (Contract|Document|FileResource → Project), PRODUCES (Project → Contract|Document|FileResource), PROVIDES_INFRASTRUCTURE (Organization → Host), ROLE_OF (Role → Person), SERVED_UNDER (Application → Domain), SERVES (Domain → Application), SKILL_OF (Skill → Agent|Organization|Person|SoftwareAgent), SPOUSE_OF (Person → Person), SUPPLIED_BY (Agent|Organization|Person|SoftwareAgent → Organization), SUPPLIES (Organization → Agent|Organization|Person|SoftwareAgent), SUPPLIES_TECHNOLOGY (Organization → Technology), SUPPORTED_BY (Contract|Document|FileResource → Contract|Document|FileResource), SUPPORTS (Contract|Document|FileResource → Contract|Document|FileResource), TECHNOLOGY_SUPPLIED_BY (Technology → Organization), TECHNOLOGY_USED_BY (Technology → Application), USES_TECHNOLOGY (Application → Technology), WORKED_ON_BY (Project → Agent|Organization|Person|SoftwareAgent), WORKS_FOR (Person → Organization), WORKS_ON (Agent|Organization|Person|SoftwareAgent → Project)
memory_typeNoKind of memory: semantic (durable fact), episodic (event), procedural (how-to), reference (pointer to a resource). Default semantic.semantic

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.3.7
    • changedInput schema / properties / content / description
      Previous value: -"Volltext des Memory-Eintrags"New value: +"The memory text. Keep it to one atomic fact per entry so it stays retrievable and updatable."
    • addedInput schema / properties / domain
      Added value: +{
      +  "description": "Knowledge domain this entry belongs to, by its short key (e.g. 'sales', 'engineering'). Unknown keys are ignored and the entry stays unassigned - it is never guessed into a domain.",
      +  "type": "string"
      +}
    • addedInput schema / properties / memory_type / description
      Added value: +"Kind of memory: semantic (durable fact), episodic (event), procedural (how-to), reference (pointer to a resource). Default semantic."
    • addedInput schema / properties / relations
      Added value: +{
      +  "description": "Edges from this entry to the things it talks about - set them HERE, in the same call. Name the counterpart in plain words; the server finds or creates its node and draws the edge, so you need neither knowmind_recall nor knowmind_entity nor knowmind_link for it. Example: storing 'Anna Meier leitet die IT bei der Muster GmbH' carries [{predicate: 'WORKS_FOR', object: 'Muster GmbH', object_class: 'Organization'}]. An entry without edges is a note; with edges it answers questions nobody wrote down. Allowed predicate values: ABOUT (Contract|Document|FileResource → Topic), ASSIGNED_TO (ActionRecord|Task → Agent|Organization|Person|SoftwareAgent), CLIENT_OF (Agent|Organization|Person|SoftwareAgent → Organization), CONTACT_PERSON_FOR (Person → Organization), COVERED_BY (Topic → Contract|Document|FileResource), DELIVERED_AS (Application → Product), DELIVERED_BY (Product → Application), DEPENDS_ON (Application → Application), DEPLOYED_TO (Application → Container), DEVELOPED_BY (Application → Agent|Organization|Person|SoftwareAgent), DEVELOPS (Agent|Organization|Person|SoftwareAgent → Application), ENABLES (Application → Application), FOR_CLIENT (Project → Agent|Organization|Person|SoftwareAgent), HAS_ASSIGNED_TASK (Agent|Organization|Person|SoftwareAgent → ActionRecord|Task), HAS_CHILD (Person → Person), HAS_CLIENT (Organization → Agent|Organization|Person|SoftwareAgent), HAS_CONTACT_PERSON (Organization → Person), HAS_EMPLOYEE (Organization → Person), HAS_OPERATED_APPLICATION (Agent|Organization|Person|SoftwareAgent → Application), HAS_PARENT (Person → Person), HAS_PREDECESSOR (ActionRecord|Project|Task → ActionRecord|Project|Task), HAS_PROJECT (Agent|Organization|Person|SoftwareAgent → Project), HAS_ROLE (Person → Role), HAS_SIBLING (Person → Person), HAS_SKILL (Agent|Organization|Person|SoftwareAgent → Skill), HAS_SUCCESSOR (ActionRecord|Project|Task → ActionRecord|Project|Task), HOSTED_ON (Container → Host), HOSTS (Host → Container), HOSTS_APPLICATION (Container → Application), INFRASTRUCTURE_PROVIDED_BY (Host → Organization), INTEGRATES_WITH (Application → Application), IS_LED_BY (Organization → Person), KNOWS (Person → Person), LEADS (Person → Organization), OPERATED_FOR (Application → Agent|Organization|Person|SoftwareAgent), PAID_BY (Agent|Organization|Person|SoftwareAgent → Agent|Organization|Person|SoftwareAgent), PARTNER_OF (Organization → Organization), PAYS (Agent|Organization|Person|SoftwareAgent → Agent|Organization|Person|SoftwareAgent), PRODUCED_BY (Contract|Document|FileResource → Project), PRODUCES (Project → Contract|Document|FileResource), PROVIDES_INFRASTRUCTURE (Organization → Host), ROLE_OF (Role → Person), SERVED_UNDER (Application → Domain), SERVES (Domain → Application), SKILL_OF (Skill → Agent|Organization|Person|SoftwareAgent), SPOUSE_OF (Person → Person), SUPPLIED_BY (Agent|Organization|Person|SoftwareAgent → Organization), SUPPLIES (Organization → Agent|Organization|Person|SoftwareAgent), SUPPLIES_TECHNOLOGY (Organization → Technology), SUPPORTED_BY (Contract|Document|FileResource → Contract|Document|FileResource), SUPPORTS (Contract|Document|FileResource → Contract|Document|FileResource), TECHNOLOGY_SUPPLIED_BY (Technology → Organization), TECHNOLOGY_USED_BY (Technology → Application), USES_TECHNOLOGY (Application → Technology), WORKED_ON_BY (Project → Agent|Organization|Person|SoftwareAgent), WORKS_FOR (Person → Organization), WORKS_ON (Agent|Organization|Person|SoftwareAgent → Project)",
      +  "items": {
      +    "properties": {
      +      "confidence": {
      +        "description": "Edge confidence in [0..1]; 1.0 for a fact stated verbatim, 0.7 for a clear paraphrase. Below that, leave the edge out.",
      +        "type": "number"
      +      },
      +      "object": {
      +        "description": "Proper name of the counterpart, as it would be written in a document ('Muster GmbH', not 'the client').",
      +        "type": "string"
      +      },
      +      "object_class": {
      +        "description": "Class of the counterpart (Person, Organization, Application, Host, Technology, ...). Pick it from knowmind_schema.",
      +        "type": "string"
      +      },
      +      "object_description": {
      +        "description": "One sentence about the counterpart, used when its node has to be created. Optional.",
      +        "type": "string"
      +      },
      +      "predicate": {
      +        "description": "Edge type in UPPER_SNAKE_CASE from the allowed list.",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "predicate",
      +      "object"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / source / description
      Previous value: -"Quelle/Herkunft, frei-text"New value: +"Where this came from - URL, file path, or a short note. Free text, stored for provenance."
    • changedInput schema / properties / tags / description
      Previous value: -"Schlagworte für Filterung"New value: +"Free-text keywords for later filtering (lowercase, no spaces recommended)."
    • changedInput schema / properties / title / description
      Previous value: -"Kurz-Titel des Memory-Eintrags"New value: +"Short human-readable title (a few words). Not a uniqueness key - duplicate titles create separate entries."
  2. First observedv0.3.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations give the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds substantial context beyond them: 'Always creates a new entry' with titles as non-keys, sha-identical content treated as idempotent, the never-hard-delete/supersede model, the write-scope requirement, and 'Returns the new memory id.' The idempotency nuance refines rather than contradicts the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and scoping, but the body is long and repeats content already in the schema and annotations — notably the 'A memory without edges is a note...' metaphor appears here and again verbatim in the relations schema description. The all-caps emphasis and duplicated predicate list dilute the density.

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 7-param mutation tool with no output schema, the description covers everything an agent needs: effect (creates one entry), return value (the new memory id), auth scope, the never-deleted/superseded lifecycle, and the edge-creation side effect. Nothing material 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 schema already documents all 7 parameters and even embeds the allowed predicate list. The description still adds meaning by insisting relations be set in THIS call ('GIVE THE EDGES ALONG') and warning that the server creates the counterpart node and edge, so no separate knowmind_recall/entity/link call is needed — semantics 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?

States a specific verb+resource ('Store durable insights... Persists one memory entry in the tenant corpus') and enumerates what qualifies (decisions, preferences, facts, results, appointments). It explicitly separates the tool from siblings: knowmind_recall/knowmind_list_recent for retrieval, knowmind_upload_document for long text, knowmind_update_fact for superseding, knowmind_link for connecting existing entries.

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?

Gives explicit when-to-use and when-not: 'Use for a single short fact; for long or multi-fact text use knowmind_upload_document' and 'Use knowmind_link separately only to connect two entries that already exist.' It also routes supersession to knowmind_update_fact and removal to knowmind_unlink_entities, covering the alternatives by name.

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