Delete links
delete_linksRemove links by ID while keeping nodes intact. One undoable step.
Instructions
Remove links by id (nodes stay). One undoable step.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes |
delete_linksRemove links by ID while keeping nodes intact. One undoable step.
Remove links by id (nodes stay). One undoable step.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false and non-idempotent, so the safety profile is covered. The description adds two traits the annotations do not carry: only links are affected (nodes survive) and the operation is 'one undoable step', which usefully links it to undo_last_change. Return/failure behavior is still undisclosed.
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 clauses, zero filler, and the scope constraint is front-loaded before the undo note. Nothing extraneous to trim.
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 one-parameter destructive tool whose annotations already flag destructiveness, the description covers the essentials (target, side-effect boundary, reversibility). It omits what happens with unknown ids, partial failures, and the return value, so it is adequate but not complete.
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 0% and the single parameter is an ids array. The description says 'by id' in the singular, which is mildly at odds with the batched array (minItems 1, maxItems 500) and adds no detail on batching limits or how invalid ids are handled, so it fails to compensate for the coverage gap.
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 and resource ('Remove links') and immediately scopes it against the obvious sibling by clarifying '(nodes stay)', so an agent can distinguish it from delete_nodes without reading either schema. The subject is unambiguous.
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?
'Remove links by id (nodes stay)' implies the use case and rules out node deletion, but it never states when to prefer this over update_links or when-not to call it. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.