Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
KNOWMIND_TOKENNoAPI token; optional, needed only for tools/call
KNOWMIND_API_URLNoAPI 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

CapabilityDetails
tools
{}
prompts
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 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.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 22 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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).

Maintenance

ActivityActive
ResponsivenessNo issues