Skip to main content
Glama

sociahive

delete_node

Remove a single node from a flow. Cascades: the underlying remove drops every edge that referenced the node, so the artifact card re-renders cleanly. Use when the user says "remove the email collection step" / "delete the followup message". Rejects mutations against published flows. NOTE: this is delete_node (one node), not delete_flow (the whole flow) — those are different tools.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
flowIdYes
nodeIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

No annotations exist, so the description carries the burden. It discloses important destructive behavior: cascading removal of all referenced edges and clean re-rendering. It also states that mutations against published flows are rejected. It doesn't mention permissions, reversibility, or error/return behavior, but it covers the most critical operational traits.

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?

Three sentences, each earning its place: the main action, the critical cascade behavior, and the routing/usage guidance. The warning about delete_flow is repeated slightly but remains compact and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (two scalar params, no nested objects, no output schema), the description covers the key context: scope, cascade behavior, restriction on published flows, and sibling differentiation. It could add where nodeId comes from or how failures surface, but it is adequate for correct selection and invocation.

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

Parameters2/5

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

Schema description coverage is 0%, and the description provides no direct explanation of flowId or nodeId, their formats, or how to obtain them. The phrase 'from a flow' and 'single node' only indirectly imply their roles. The parameter names are somewhat self-explanatory, but the description adds almost no semantic detail beyond what the schema already shows.

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?

The description states a specific action ('Remove a single node from a flow') with a clear verb and resource. It also explicitly differentiates from delete_flow, so an agent can distinguish it from a similarly named sibling without opening the 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?

It gives direct trigger examples ('remove the email collection step' / 'delete the followup message'), explicitly contrasts with delete_flow, and warns that published flows reject mutations. This gives an agent both when-to-use and when-not-to-use guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources