Skip to main content
Glama

knowmind_store_memory

Store durable insights, facts, decisions, and preferences as memory entries, optionally linking related entities like people or projects for later retrieval.

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. Append-only: the same title replaces nothing (use knowmind_update_fact to supersede); 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. 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.6/5.0
Behavior4/5

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

Beyond the annotations, the description reveals append-only behavior ('the same title replaces nothing'), a specific idempotence rule ('sha-identical content is detected as idempotent'), the returned value ('new memory id'), and a prerequisite ('Requires write scope'). It also explains that relations are persisted in the same call with no second tool needed. Slightly opaque on failure/error behavior and what happens to the graph node when there are no edges, so not a full 5.

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?

The description is front-loaded with the core purpose and a routing sentence in the first two lines. It is longer than it strictly needs to be because the 'GIVE THE EDGES ALONG' section and the schema description for relations repeat the same example and explanation. Still, most sentences earn their place by addressing behavior, routing, or parameters.

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?

Given a complex tool with 7 parameters and no output schema, the description covers what matters most: what counts as an atomic memory, how to add relations in the same call, which sibling to use instead, and that it returns the new memory id. It is sufficiently complete for an agent to call the tool without requiring the schema or separate documentation.

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 meaningful operational nuance to key parameters: content should be a single short fact, relations should be filled in the same call with a concrete example, and title is not a uniqueness key. It also rationalizes the relations parameter by explaining the difference between a note and a graph memory, which helps an agent decide how to fill it.

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 opens with a specific verb and resource: 'Store durable insights' and 'Persists one memory entry in the tenant corpus (Postgres + vector index + graph node)'. It clearly differentiates this tool from close siblings: 'for long or multi-fact text use knowmind_upload_document' and 'use knowmind_update_fact to supersede'. An agent can immediately tell what this tool does and where it fits among the other memory tools.

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?

The description gives explicit selection criteria: 'Use for a single short fact; for long or multi-fact text use knowmind_upload_document' and names knowmind_update_fact for superseding existing entries. It also tells the agent when not to use linking tools here: 'Use knowmind_link separately only to connect two entries that already exist'. This is full usage guidance with routing to alternatives.

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