Delete a node from a graph. If the node has connected edges and cascade is not enabled, deletion is rejected to prevent dangling edges.
노드를 삭제한다.
연결된 엣지가 있는데 cascade=False 면 삭제를 거부하고 { ok: false, error: "has_edges", edge_count } 를 돌려준다 — 끊어진 엣지는 허용되지 않는다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| cascade | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the refusal behavior with a specific error payload and the policy that dangling edges are not allowed. This goes beyond the destructiveHint annotation by explaining the exact failure mode and the reasoning behind it, which is valuable for an agent deciding whether to set cascade.
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 concise sentences with no filler. The main action is front-loaded, and the edge-case condition and response format are given in the second sentence. Every sentence earns its place.
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?
The description covers the primary behavior and the critical edge case, but it omits details on the exact effect when cascade=True (does it delete edges or fail?), and any other side effects or prerequisites. Given an output schema exists, the return structure is partially known, but the semantics of the cascade flag could be clearer. Adequate but not exhaustive.
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?
With schema description coverage at 0%, the description is the only source of parameter meaning. It explains that cascade=False causes a refusal when edges exist, implying the opposite for cascade=True, but does not explicitly state that cascade=True deletes connected edges. The id parameter is left obvious from the schema/name. Partial compensation for the lack of schema descriptions.
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?
The description clearly states the action: deleting a node, and includes a specific behavioral condition (refusal when edges exist and cascade is false). This distinguishes it from other graph mutation tools like delete_edge or clear_all. The verb+resource pair 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?
No explicit guidance on when to use this tool versus alternatives such as delete_edge, clear_layer, or clear_all. The description focuses on the cascade condition but does not mention any contextual selection criteria, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.