Delete a directed relationship edge between source and target entities in a collection, optionally by relation label, with immediate invalidation.
Delete an explicit directed relationship edge with zero-lag invalidation. Parameters: collection, source_id, target_id, optional relation.
| Name | Required | Description | Default |
|---|---|---|---|
| relation | No | Relation label | OWNS |
| source_id | Yes | Source entity ID | |
| target_id | Yes | Target entity ID | |
| collection | Yes | Collection name |
Changes observed during successful MCP inspections.
v4.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and mostly fails it. 'Zero-lag invalidation' hints at immediate cache/index effects but is never explained, and there is no statement on reversibility, idempotency, permission requirements, or whether deleting an edge affects the linked entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action. The trailing parameter list is redundant with a fully documented schema, but it costs little.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with zero annotation coverage and no output schema, the description is too thin. An agent cannot tell whether the call errors on a missing edge, whether it is idempotent, or what the side effects of 'zero-lag invalidation' actually are.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in structured form. The description merely enumerates the same names and adds no semantics, such as the default relation label 'OWNS' or what happens when 'relation' is omitted. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Delete an explicit directed relationship edge'), which is unmistakable and clearly the inverse of the sibling hyperspace_link. It does not explicitly name that sibling, so differentiation is inferable rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus hyperspace_link_batch, hyperspace_induce_edges, or hyperspace_delete_points. There are no prerequisites, no exclusions, and no mention of what happens if the edge does not exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.