sociahive

update_node

Change one existing node — every in-flow content edit. "change the welcome message to X" / "fix the typo" → text; "update the trigger keyword to B" → keywords; "use this link" → link; anything else ("set the delay to 5 minutes") → data, MERGED into the node so nothing else is lost. FIRST call: flowName names the flow and nodeId takes the node's LABEL from what the user said ("the welcome message", "the delay") — the server resolves both, so never get_flow first. Always include the CHANGE in the same call; if the user has not said the new value, ask them first. Rejects published flows.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`link`	No
`name`	No
`text`	No
`flowId`	No
`nodeId`	Yes
`flowName`	No
`keywords`	No
`position`	No
`removeBlockIds`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 1, 2026

addedInput schema / properties / keywords

Added value: +{
+  "items": {
+    "maxLength": 100,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 50,
+  "type": "array"
+}

addedInput schema / properties / link

Added value: +{
+  "maxLength": 2000,
+  "type": "string"
+}

addedInput schema / properties / removeBlockIds

Added value: +{
+  "items": {
+    "maxLength": 100,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 20,
+  "type": "array"
+}

addedInput schema / properties / text

Added value: +{
+  "maxLength": 4000,
+  "type": "string"
+}

First observedSep 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden well: it discloses that flowName/nodeId labels are server-resolved, that data is merged so nothing else is lost, that a change must be included in the same call, and that published flows are rejected. It does not cover return values, error behavior, or whether text/keywords/link overwrite existing values.

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

Conciseness4/5

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

The description is front-loaded with purpose, then packed with usage mappings and constraints. Most sentences earn their place, though the dense example-driven style could be slightly more skimmable.

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?

For a 10-parameter mutation tool with no annotations or output schema, the description gives substantial workflow context: routing examples, server-resolution behavior, required first-call handling, and the published-flow restriction. It remains incomplete on several parameters and does not clarify flowId vs flowName.

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 0%, so the description must compensate for 10 parameters. It adds useful meaning for text, keywords, link, data, flowName, and nodeId, but leaves name, flowId, position, and removeBlockIds undocumented beyond their schema names and types.

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 verb and resource: 'Change one existing node — every in-flow content edit.' It clearly distinguishes this from siblings like add_node, delete_node, and update_flow by scoping it to editing an existing node's in-flow content.

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 tells the agent exactly when to use this tool versus alternatives, including routing user phrases to specific parameters and explicitly saying never call get_flow first. It also states a key prerequisite: published flows are rejected.

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

All sociahive tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?