Skip to main content
Glama

add_parent_call_node

Adds a parent-class call node for an overridden function or event, searching the whole ancestor chain to build event, super, and logic in one transaction.

Instructions

Add a "Parent: " node that calls the parent-class implementation of an overridden function/event -- the second half of the child-first shape "Event X -> Parent: X -> our logic" that keeps a vendor base class working while the child adds behaviour. Searches the WHOLE ancestor chain, not just the immediate parent. Does NOT compile, and IS allowed inside build_blueprint_graph, so the event + super + logic can be built in one transaction.

Returns: { node_id, class, title, pins:[execute, then, the parent's params], blueprint_name, graph_name, function_name, parent_class } -- parent_class names the ancestor that actually declares the implementation being called.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoOptional. This command is REFUSED while a Play-in-Editor session is running: it either compiles a Blueprint (the reinstancer can retain a world, and CheckForWorldGCLeaks is Fatal -- it KILLS the editor) or writes to disk (Editor.AllowSavingAssetsDuringPIE=0 makes the engine refuse the write, so it would report success without writing a byte). Stop PIE and retry instead; force=true runs it anyway, at your own risk.
graph_nameNoTarget graph (usually the override's own graph); defaults to the event graph
position_xNoNode X position on the graph canvas (ignored when node_position is set)
position_yNoNode Y position on the graph canvas (ignored when node_position is set)
function_nameYesName of the overridden function/event whose parent implementation to call; must exist on some ancestor or the call errors
node_positionNoNode canvas position as [x, y]; takes precedence over position_x/position_y
blueprint_nameNoBlueprint whose parent function is called
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Adds real behavior beyond the annotations: it searches the WHOLE ancestor chain (not just the immediate parent), does NOT compile, and is permitted inside build_blueprint_graph transactions. Annotations only give the generic safety profile, so this extra context matters. The PIE-refusal mechanics live in the force parameter rather than the description.

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?

Front-loaded with the purpose before the conceptual framing, and the return shape is separated out. Slightly dense and longer than strictly necessary, but every sentence carries information.

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 an 8-param mutation node with no output schema, the description covers shape, ancestor behavior, transactional context, and the returned parent_class. It is nearly complete, missing only more explicit routing to sibling node-builders.

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 coverage is 100%, so the schema already documents all 8 parameters in detail. The description adds only the ancestor-chain resolution nuance for function_name and the return-side parent_class meaning, so the baseline 3 is appropriate.

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?

States a specific verb+resource (add a 'Parent: <Function>' node) and precisely what it does: call the parent-class implementation of an overridden function/event. The 'child-first shape' framing makes it immediately distinguishable from the many generic add_*_node siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear usage context (when overriding a parent function and wanting to keep a vendor base class working) and notes it is allowed inside build_blueprint_graph for a one-transaction build. It does not explicitly name an alternative sibling to prefer or exclude, so it stops short of a 5.

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

Deploy Server

Other Tools