knowmind
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KNOWMIND_TOKEN | No | API token; optional, needed only for tools/call | |
| KNOWMIND_API_URL | No | API URL (default https://knowmind.de) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| knowmind_recall_memoriesA | Retrieve relevant knowledge before answering anything that benefits from prior context - decisions, preferences, project state, people, deadlines, past conversations. Hybrid recall (BM25 + pgvector + knowledge graph) over the tenant corpus; returns the top-k memory chunks, each with a relevance score and source reference. Suitable whenever earlier context would improve the answer; use knowmind_recall_at_time when you need what was valid at a past point in time. Passages from pages in Open Knowledge Format carry metadata.review_flags: stale once stale_after is reached, unverified when no verification is recorded, superseded when the page's status is deprecated or superseded or its valid_to is reached, drifted when code cited by the page's claims changed or was removed since the page was written; an empty list means none applies. When kein_belastbarer_treffer is true, the corpus most likely holds no answer; unless the hits clearly answer the question, say so. Read scope suffices. |
| knowmind_get_healthA | Return the health of the knowmind backend (Postgres, memory service, graph). Use before a batch of writes or when calls fail, to tell an outage apart from an empty result. Returns a status object per component. Read scope suffices; takes no parameters. |
| knowmind_get_statsA | Return current counts for the tenant corpus: memories, graph edges and vector chunks. Use to gauge how much has been stored; for the actual entries use knowmind_list_recent or knowmind_recall. Read scope suffices; takes no parameters. |
| knowmind_list_recentA | List the most recently created documents/memories in the tenant corpus, newest first (by created_at). Same corpus that recall searches. Use to review what was just stored or confirm a write landed; use knowmind_recall when you already know what you are looking for. Graph-only entities without a timestamp do not appear, so this count intentionally differs from stats.memories. Read scope suffices. |
| knowmind_store_memoryA | 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 |
| knowmind_upload_documentA | Ingest a longer text as one document into the tenant corpus: chunk splitting, embeddings, vector chunks and graph nodes. Upsert-by-title (server default): if a valid document with the same title exists in the same domain, the new version supersedes it; the old version stays retrievable via knowmind_recall_at_time, and the superseded ids come back in replaced_document_ids. If the same text already exists in another valid document of the same domain, no new document is created and the response carries deduplicated. Use for long-form or multi-fact content (a report, a page, a doc); for a single short fact use knowmind_store_memory. Returns the document id and the number of chunks written. AFTER INGESTING: extract the facts the text states about people, organisations, projects, products, technologies and hosts, and create the corresponding edges via knowmind_link. Requires write scope. |
| knowmind_update_factA | Supersede a known fact without losing history: the existing memory gets valid_to=now, a new memory with valid_from=now is created and linked via SUPERSEDES. Use this instead of knowmind_store_memory when a fact CHANGES (address moved, contract renewed) - old statements are marked outdated, not deleted, so the timeline stays auditable and queryable via knowmind_recall_at_time. Returns the new memory id. Requires write scope. |
| knowmind_recall_at_timeA | Time-travel recall: return only memories that were valid at a given instant (valid_from <= as_of <= valid_to, or still open). Answers 'what did the agent know on March 14?'. Use instead of knowmind_recall when the point in time matters; otherwise use knowmind_recall for the current truth. Passages from pages in Open Knowledge Format carry metadata.review_flags (stale, unverified, superseded, drifted); stale and superseded are judged against as_of. When kein_belastbarer_treffer is true, the corpus as of as_of most likely holds no answer; it is judged on the hits visible at as_of. Unless they clearly answer the question, say so. Read scope suffices. |
| knowmind_upsert_entityA | Create the node for a thing the corpus talks about - a person, an organisation, an application, a host, a technology - or return the existing one. THE GRAPH NEEDS THESE: memories are texts, and two texts mentioning the same server stay unconnected until that server exists as its own node. Create an entity when a name recurs across memories or when you are about to link something that has no node yet, then connect it with knowmind_link. Same name, same class and same tenant always return the same id, so calling twice creates no duplicate. Give the entity its plain proper name ("PostgreSQL", not "the database we use"), and pick the class from the catalogue in knowmind_schema. Requires write scope. |
| knowmind_link_entitiesA | Create a typed relation between two memory nodes (a knowledge-graph edge). THIS IS HOW THE GRAPH IS BUILT: after storing memories, connect them - a corpus without edges answers only what a single note already says. The server checks the edge against the ontology's shapes before writing it: the subject and object must belong to the classes the predicate requires (for entries without a class the check only warns), entity names must carry no role or suffix, and the edge must name its evidence - the id of the entry that states the relation. A rejected edge returns the violated rule. The inverse edge is materialized automatically, and derived edges (RUNS_ON, WORKS_FOR_CLIENT, HOST_SERVES_CLIENT, DEPENDS_ON_SUPPLIER) are computed by the server - never set them by hand. Get both node IDs via knowmind_recall first, and call knowmind_schema for the full catalogue with explanations. Allowed rel_type 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). Requires write scope. |
| knowmind_get_schemaA | Return the relation catalogue of this tenant's knowledge graph: every allowed edge type with its subject and object classes and an explanation of when to use it. Call this before building edges with knowmind_link, so you pick the right predicate instead of the nearest-sounding one. Read scope suffices. |
| knowmind_unlink_entitiesA | End a relation between two memories; inverse and inferred edges end with it. It stays in history, where knowmind_recall_at_time finds it. Repeating it does nothing. Fixes a wrong knowmind_link. Requires write scope. |
| knowmind_list_relationsA | List all relations of one memory (incoming and outgoing), each with its edge type and the connected node. Use to inspect how an entity is connected before adding or removing edges with knowmind_link/knowmind_unlink; find the memory_id first via knowmind_recall. Read scope suffices. |
| knowmind_list_inferredA | List relations that wait for a human decision, each with its review state (open, confirmed, rejected) and its reason: inferred_from_text (knowmind inferred it from a text) or starts_from_document (it starts from a document although its kind needs a person, organisation or similar). Per relation also the two connected entries, where it came from (source), the entry that supports it (evidence), and the counts per state. Open relations do not feed the derivation rules until someone confirms them. Use to review what the graph learned on its own; record a decision with knowmind_review_inferred. Read scope suffices. |
| knowmind_review_inferredA | Record a human decision on one inferred relation from knowmind_list_inferred. confirm: the relation counts as checked and feeds the derivation rules from now on. reject: the relation, its reverse relation and every relation derived from it get valid_to=now; nothing is deleted. undo: takes a rejection back and restores the reverse and derived relations. Pass the edge_id from the list and, if there is one, the id of the entry that supports the decision as evidence. Returns the state before and after and the number of reverse and derived relations affected. Requires write scope. |
| knowmind_recallA | DEPRECATED, removed on 2027-03-31: use knowmind_recall_memories. This name keeps answering unchanged until then. Retrieve relevant knowledge before answering anything that benefits from prior context - decisions, preferences, project state, people, deadlines, past conversations. Hybrid recall (BM25 + pgvector + knowledge graph) over the tenant corpus; returns the top-k memory chunks, each with a relevance score and source reference. Suitable whenever earlier context would improve the answer; use knowmind_recall_at_time when you need what was valid at a past point in time. Passages from pages in Open Knowledge Format carry metadata.review_flags: stale once stale_after is reached, unverified when no verification is recorded, superseded when the page's status is deprecated or superseded or its valid_to is reached, drifted when code cited by the page's claims changed or was removed since the page was written; an empty list means none applies. When kein_belastbarer_treffer is true, the corpus most likely holds no answer; unless the hits clearly answer the question, say so. Read scope suffices. |
| knowmind_healthA | DEPRECATED, removed on 2027-03-31: use knowmind_get_health. This name keeps answering unchanged until then. Return the health of the knowmind backend (Postgres, memory service, graph). Use before a batch of writes or when calls fail, to tell an outage apart from an empty result. Returns a status object per component. Read scope suffices; takes no parameters. |
| knowmind_statsA | DEPRECATED, removed on 2027-03-31: use knowmind_get_stats. This name keeps answering unchanged until then. Return current counts for the tenant corpus: memories, graph edges and vector chunks. Use to gauge how much has been stored; for the actual entries use knowmind_list_recent or knowmind_recall. Read scope suffices; takes no parameters. |
| knowmind_entityA | DEPRECATED, removed on 2027-03-31: use knowmind_upsert_entity. This name keeps answering unchanged until then. Create the node for a thing the corpus talks about - a person, an organisation, an application, a host, a technology - or return the existing one. THE GRAPH NEEDS THESE: memories are texts, and two texts mentioning the same server stay unconnected until that server exists as its own node. Create an entity when a name recurs across memories or when you are about to link something that has no node yet, then connect it with knowmind_link. Same name, same class and same tenant always return the same id, so calling twice creates no duplicate. Give the entity its plain proper name ("PostgreSQL", not "the database we use"), and pick the class from the catalogue in knowmind_schema. Requires write scope. |
| knowmind_linkA | DEPRECATED, removed on 2027-03-31: use knowmind_link_entities. This name keeps answering unchanged until then. Create a typed relation between two memory nodes (a knowledge-graph edge). THIS IS HOW THE GRAPH IS BUILT: after storing memories, connect them - a corpus without edges answers only what a single note already says. The server checks the edge against the ontology's shapes before writing it: the subject and object must belong to the classes the predicate requires (for entries without a class the check only warns), entity names must carry no role or suffix, and the edge must name its evidence - the id of the entry that states the relation. A rejected edge returns the violated rule. The inverse edge is materialized automatically, and derived edges (RUNS_ON, WORKS_FOR_CLIENT, HOST_SERVES_CLIENT, DEPENDS_ON_SUPPLIER) are computed by the server - never set them by hand. Get both node IDs via knowmind_recall first, and call knowmind_schema for the full catalogue with explanations. Allowed rel_type 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). Requires write scope. |
| knowmind_schemaA | DEPRECATED, removed on 2027-03-31: use knowmind_get_schema. This name keeps answering unchanged until then. Return the relation catalogue of this tenant's knowledge graph: every allowed edge type with its subject and object classes and an explanation of when to use it. Call this before building edges with knowmind_link, so you pick the right predicate instead of the nearest-sounding one. Read scope suffices. |
| knowmind_unlinkA | DEPRECATED, removed on 2027-03-31: use knowmind_unlink_entities. This name keeps answering unchanged until then. End a relation between two memories; inverse and inferred edges end with it. It stays in history, where knowmind_recall_at_time finds it. Repeating it does nothing. Fixes a wrong knowmind_link. Requires write scope. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 22 tools
Among the active tools, purposes are distinct: store/upload split by content length, recall vs recall_at_time split by time semantics, entity vs link vs unlink, and inferred-review pair. However, 7 tools (recall, health, stats, entity, link, schema, unlink) are deprecated aliases that still answer, creating seven near-duplicate pairs an agent could misroute to if it skims.
Active tools follow a clean knowmind_verb_noun snake_case pattern (get_health, store_memory, link_entities, recall_at_time). The deprecated aliases (knowmind_health, knowmind_stats, knowmind_entity, knowmind_link) drop the verb and break the pattern, a minor but visible inconsistency.
22 tools is on the heavy side; 7 of them are deprecated aliases, so the effectively supported surface is ~15, which is reasonable for a memory-plus-graph server. The alias inflation pushes the raw count into the borderline-heavy band.
Coverage is broad: write (store/upload), supersede (update_fact), time-travel and current recall, listing (recent/relations), entity upsert, link/unlink, inferred-relation review, plus health/stats/schema diagnostics. Intentional no-hard-delete design and upsert-by-title document replacement leave only minor gaps (no batch ops, no explicit document edit beyond re-upload).