Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

remove_component_from_blueprint

DestructiveIdempotent

Remove one or more component nodes from a Blueprint's SCS in one batch, reporting descendants and unexpected losses so collateral deletions are not hidden.

Instructions

Remove one or more component nodes from a Blueprint's SCS, with a DOUBLE CENSUS (flat AllNodes vs a walk of RootNodes) so collateral losses are reported instead of hidden: also_removed names descendants that went with their parent and unexpected_losses names nodes left in AllNodes but unreachable from any root. Batch-capable and that is the point -- chaining SINGLE-node calls on the same Blueprint is exactly the pattern that deletes components nobody asked for, so pass component_names and take ONE compile for the lot. A re-added component comes back with its CLASS defaults: per-instance overrides are gone and do not come back on save. "Nothing matched" is an ERROR here; remove_blueprint_component_node is the idempotent twin that reports already_removed instead.

Returns: { success, error?, data: { blueprint_name, removed_component, requested[], removed_components[], also_removed[], unexpected_losses[], not_found[], still_present[], node_count_before, node_count_after, reachable_before, reachable_after, orphans_before[], orphans_after[], root_nodes_before[], root_nodes_after[], root_nodes_changed, promote_children, compiled, compile_count, success, verification } }

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.
blueprint_nameNoName/path of the blueprint
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
component_nameNoName of the component to remove (single form; matches the variable name or the _GEN_VARIABLE internal name)
component_namesNoOptional array of component names removed as ONE batch with a SINGLE compile. Chaining single-node calls is the pattern that causes collateral deletions. Merged with component_name when both are given.
promote_childrenNoOptional bool, default true: keep descendants by re-parenting them (RemoveNodeAndPromoteChildren). Pass false for plain RemoveNode, which orphans the whole subtree.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the annotations: it discloses the DOUBLE CENSUS verification, that collateral losses surface as also_removed/unexpected_losses, that a re-added component comes back with class defaults and loses per-instance overrides, that 'nothing matched' is an ERROR, and that PIE causes compile refusal. The destructiveHint and non-readOnly annotations are consistent with this; the idempotentHint=true is in mild tension with the 'idempotent twin' framing, but the state outcome of a repeat call is still unchanged, so this is not a hard contradiction.

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?

Purpose and the batch rationale are front-loaded in the first sentence, and every claim is load-bearing (census, override loss, PIE refusal, sibling routing). It is dense and emphatic, and the long inline return-field dump is verbose, though justified by the absence of an output schema.

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

Completeness5/5

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

No output schema exists, so enumerating the returned fields (also_removed, unexpected_losses, orphans_before/after, compile_count, verification) is necessary and it does so. Combined with the PIE caveat, the error-on-no-match rule, and the batch guidance, an agent has everything needed to call this destructive batch tool safely.

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 100% and the schema itself already documents force's PIE rationale, the blueprint_path alias, the component_name/component_names merge, and promote_children's RemoveNodeAndPromoteChildren behavior. The description restates the batch intent ('ONE compile') but adds little syntax or semantics the schema does not already carry, so the baseline 3 applies.

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 and resource ('Remove one or more component nodes from a Blueprint's SCS') and immediately distinguishes itself from the sibling remove_blueprint_component_node by calling it 'the idempotent twin that reports already_removed instead.' An agent can pick this tool over its near-name twin without opening either 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?

Gives explicit when-to-use guidance ('Batch-capable and that is the point... pass component_names and take ONE compile for the lot') and names the alternative with the condition that selects it (idempotent twin for already-removed cases). It also states the PIE precondition and the force override path, so the calling conditions are fully specified.

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