Skip to main content
Glama
Schubeler-Consulting

knowmind

by Schubeler-Consulting
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

knowmind_link

Idempotent

Establish a typed relation between two memory nodes by providing source and target IDs along with a valid relation type from the allowed list, enabling graph connections.

Instructions

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. Subject and object classes must match the predicate; 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
to_idYesMemory ID of the target node.
from_idYesMemory ID of the source node (get it via knowmind_recall).
rel_typeYesEdge type in UPPER_SNAKE_CASE from the allowed list. Must fit the subject and object classes.
confidenceNoEdge confidence in [0..1]; 1.0 for a fact stated verbatim, 0.7 for a clear paraphrase. Below that, do not create the edge.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.7
    • changedInput schema / properties / confidence / description
      Previous value: -"Konfidenz der Kante [0..1]; Standard 1.0 für gepflegte Kanten."New value: +"Edge confidence in [0..1]; 1.0 for a fact stated verbatim, 0.7 for a clear paraphrase. Below that, do not create the edge."
    • changedInput schema / properties / from_id / description
      Previous value: -"Memory-ID des Quellknotens"New value: +"Memory ID of the source node (get it via knowmind_recall)."
    • changedInput schema / properties / rel_type / description
      Previous value: -"Edge-Typ in UPPER_SNAKE_CASE (z. B. OWNS, FOR_CLIENT, SUPERSEDES)"New value: +"Edge type in UPPER_SNAKE_CASE from the allowed list. Must fit the subject and object classes."
    • changedInput schema / properties / to_id / description
      Previous value: -"Memory-ID des Zielknotens"New value: +"Memory ID of the target node."
  2. First observedv0.3.1

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations, the description discloses automatic inverse edge materialization, that certain derived edges are server-computed and must not be manually set, and that write scope is required. These behavioral details are not present in the annotations and materially affect how the agent plans its calls.

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 core purpose is front-loaded and the explanatory text is efficient. The long list of allowed rel_type values is necessary and directly actionable; while lengthy, it is the core value offered over the structured schema rather than fluff.

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 nontrivial edge-creation tool, the description covers workflow, prerequisites, allowed values, semantic constraints, derived edges, and scope requirements. No output schema exists, but the tool's return format is not needed to invoke it correctly; the description is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for IDs and confidence, but the rel_type schema only says 'from the allowed list' without listing it. The description compensates with the full list of allowed values and the subject/object class mappings for each relation, which is critical for selecting a valid parameter value.

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: 'Create a typed relation between two memory nodes (a knowledge-graph edge)'. It clearly distinguishes this from recall/list/store operations and explains how it fits into graph construction.

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?

It states when to use the tool ('after storing memories... connect them') and gives explicit prerequisites: get node IDs via knowmind_recall and call knowmind_schema for explanations. It also tells what NOT to do: 'never set derived edges by hand', which removes guesswork.

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