Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

remove_niagara_data_interface

Destructive

Removes a Niagara data interface user-parameter binding by name, recompiles and saves the system; fails if the parameter is missing or not a data interface.

Instructions

Remove a UNiagaraDataInterface user-parameter binding from a Niagara system by name, inside an undo transaction, request a recompile and save the system; success requires the save. A name with no user parameter, or a user parameter that is not a data interface, is an error and nothing is changed.

Returns: { system_path: string, parameter_name: string, data_interface_class: string, removed: bool, saved: bool, save_error?: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
system_pathYesAsset path of the Niagara System.
parameter_nameYesShort name of the user-parameter to remove (no "User." prefix)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedInput schema / required
      Previous value: -[
-  "parameter_name"
-]New value: +[
+  "system_path",
+  "parameter_name"
+]
  2. First observedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true / readOnlyHint=false, but the description adds substantial behavior beyond them: it runs inside an undo transaction, requests a recompile, and requires the save to succeed. It also documents error semantics precisely ('nothing is changed'), which is exactly the kind of side-effect disclosure a destructive tool needs.

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 action and its side effects, followed by a compact Returns block. The core sentence is long and slightly run-on, but every clause carries operational weight, so it is efficient overall.

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?

For a destructive mutation with no output schema, the description covers action, side effects (undo/recompile/save), failure semantics, and an explicit return shape including the optional save_error. Nothing an agent needs to call it correctly is missing.

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% and both parameters are described there (including the 'no User. prefix' note). The description reinforces removal 'by name' and ties the name to the error condition, but adds little syntax or format detail beyond what the schema already provides. 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 (Remove) and resource (a UNiagaraDataInterface user-parameter binding from a Niagara system by name). This is immediately distinguishable from siblings like add_niagara_data_interface, set_niagara_data_interface_array, and get_niagara_data_interfaces. An agent can identify the operation 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 Guidelines4/5

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

Gives clear applicability context: the parameter must exist and must be a data interface, otherwise it errors and nothing changes. However, it does not explicitly name alternatives (e.g., set_niagara_data_interface_* to modify, or add_niagara_data_interface to add), so routing between siblings is left implicit.

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