knowmind

knowmind_unlink

DestructiveIdempotent

End a relation between two memories to fix a wrong link. Removes the edge and its inferred connections, preserving history for time-based recall.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "from_id": "<from_id>",
      "to_id": "<to_id>",
      "rel_type": "<rel_type>"
    },
    "name": "knowmind_unlink"
  }
}

Input Schema

Name	Required	Description
`to_id`	Yes	Memory ID of the target node.
`from_id`	Yes	Memory ID of the source node.
`rel_type`	Yes	Edge type to remove (UPPER_SNAKE_CASE, exactly as created).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.3.7Sep 9, 2026

changedInput schema / properties / from_id / description

Previous value: -"Memory-ID des Quellknotens"New value: +"Memory ID of the source node."

changedInput schema / properties / rel_type / description

Previous value: -"Edge-Typ"New value: +"Edge type to remove (UPPER_SNAKE_CASE, exactly as created)."

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.7/5.0

Behavior5/5

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

Goes well beyond the annotations: inverse and inferred edges are removed along with the edge (cascade), the edge is retained in history and retrievable via knowmind_recall_at_time (soft delete, reversible read path), repetition is a no-op, and write scope is required. Annotations already declare destructive/idempotent; the description adds the consequential detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the deprecation and replacement, then packs functionality, cascade semantics, history behavior, idempotency, and auth into short declarative clauses with no filler.

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?

No output schema, so the description must cover behavior, and it does: lifecycle (deprecated with date), side effects (inverse/inferred edges), durability (history + recall_at_time), idempotency, and permission requirements. Nothing needed to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100% with all three parameters documented (including the UPPER_SNAKE_CASE, 'exactly as created' constraint), so the schema carries the parameter burden. The description adds no parameter-level detail beyond the schema, which is the baseline 3.

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 precise verb+resource: 'End a relation between two memories.' It also names the sibling that supersedes it (knowmind_unlink_entities) and the inverse operation it undoes (knowmind_link), so an agent can place it exactly in the graph-editing family.

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?

Explicitly routes the agent away from this tool to knowmind_unlink_entities, gives the cutoff date (2027-03-31), and states the remaining legitimate use case ('Fixes a wrong knowmind_link'). When-to-use, when-not-to-use, and the alternative are all present.

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