knowmind

knowmind_link

Idempotent

Creates a typed, evidence-backed relation between two memory nodes to build a knowledge graph, validating edges against the ontology.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`to_id`	Yes	Memory ID of the target node.
`from_id`	Yes	Memory ID of the source node (get it via knowmind_recall).
`evidence`	Yes	Memory ID of the entry that states this relation (often from_id or a note found via knowmind_recall). Required: an edge without evidence is rejected.
`rel_type`	Yes	Edge type in UPPER_SNAKE_CASE from the allowed list. Must fit the subject and object classes.
`confidence`	No	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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.4.5Oct 17, 2026

addedInput schema / properties / evidence

Added value: +{
+  "description": "Memory ID of the entry that states this relation (often from_id or a note found via knowmind_recall). Required: an edge without evidence is rejected.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "from_id",
-  "to_id",
-  "rel_type"
-]New value: +[
+  "from_id",
+  "to_id",
+  "rel_type",
+  "evidence"
+]

Changed4 schema fields changedv0.3.7Sep 9, 2026

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

First observedv0.3.1Jul 21, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare idempotentHint=true, destructiveHint=false, readOnlyHint=false and openWorldHint=false; the description adds substantially beyond that: ontology shape validation before write, warn-only behavior for classless entries, the evidence-required rule, the fact that rejects return the violated rule, automatic inverse-edge materialization, and the 'Requires write scope' auth note. This is exactly the behavioral context annotations cannot carry.

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 deprecation notice and replacement name are correctly front-loaded, and the workflow/procedure sentences earn their place. The trailing enumeration of ~49 relation types is long but necessary because no enum exists in the schema; the only real cost is that this bulk sits at the end rather than being summarized earlier. Slightly over-long but not wasteful.

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?

With no output schema, the description still covers the return path for failures ('A rejected edge returns the violated rule') and the automatic inverse/derived edge behavior. Combined with write-scope, evidence, and validation rules, an agent has everything needed to call this correctly or to choose the successor tool instead.

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%, which sets a baseline of 3, but the description materially exceeds it: it enumerates all allowed rel_type values with their subject→object class domains (a list the schema only references as 'from the allowed list' with no enum), and reinforces the evidence and confidence requirements. The rel_type catalogue is the single most important piece of parameter meaning and the schema does not contain 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?

States a specific verb and resource ('Create a typed relation between two memory nodes (a knowledge-graph edge)') and frames the tool's role in graph construction, not just its mechanics. It immediately distinguishes itself from sibling knowmind_link_entities by declaring the deprecation and the replacement name, so an agent can route without opening either schema.

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 ('after storing memories, connect them'), when-not ('derived edges ... never set them by hand'), the replacement tool for new work (knowmind_link_entities), and the prerequisite workflow (get both node IDs via knowmind_recall first, call knowmind_schema for the catalogue). Alternatives and prerequisites are spelled out rather than implied.

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

knowmind_link

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools