Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

set_meta_sound_node_property

DestructiveIdempotent

Set one field on a MetaSound Source node's Configuration struct by reflection and save the asset. Failed saves keep changes in memory only; verify the saved flag.

Instructions

Write one field of a MetaSound Source node's Configuration struct by reflection, directly in the document (not through the MetaSound builder), then save the asset. Re-applying a value returns value_changed false but still saves. Succeeds only when the asset reaches disk; a failed save leaves the value in memory only (saved false, save_error).

Returns: { metasound_path, node_id, property, set, value_changed, new_value?, saved, save_error? }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYesNew value for the field as JSON, converted by FJsonObjectConverter: a number, bool, string, array or object (for a struct field); numbers and booleans can also be passed as strings ("0.5", "true").
node_idYesNode GUID, as list_meta_sound_nodes returns it in id; a value that is not a GUID is refused.
propertyYesFProperty name on the Configuration struct.
metasound_pathYesMetaSound Source asset path, e.g. "/Game/Audio/MS_Rain"; MetaSound Patches are not accepted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.2.0
    • changedInput schema / properties / metasound_path / description
      Previous value: -"Asset path."New value: +"MetaSound Source asset path, e.g. \"/Game/Audio/MS_Rain\"; MetaSound Patches are not accepted."
    • changedInput schema / properties / node_id / description
      Previous value: -"Node GUID string."New value: +"Node GUID, as list_meta_sound_nodes returns it in id; a value that is not a GUID is refused."
    • addedInput schema / properties / value / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "array"
+  },
+  {
+    "additionalProperties": true,
+    "type": "object"
+  }
+]
    • changedInput schema / properties / value / description
      Previous value: -"JSON value to apply (any FJsonObjectConverter-supported type)."New value: +"New value for the field as JSON, converted by FJsonObjectConverter: a number, bool, string, array or object (for a struct field); numbers and booleans can also be passed as strings (\"0.5\", \"true\")."
    • removedInput schema / properties / value / type
      Removed value: -"string"
    • changedInput schema / required
      Previous value: -[
-  "metasound_path",
-  "node_id",
-  "property"
-]New value: +[
+  "metasound_path",
+  "node_id",
+  "property",
+  "value"
+]
  2. First observedv1.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations (destructive, idempotent, non-read-only) by disclosing that the write is reflection-based and in-document, that a redundant write still triggers a save, and that a failed save leaves the value in memory only with saved=false and save_error. This is exactly the failure-mode detail annotations cannot express.

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 core action and mechanism, followed by save semantics and a compact return signature. Dense but every clause carries information; only the explicit 'Returns:' block verges on enumerating details that could live in an output schema.

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?

With no output schema, the description usefully enumerates the return fields and covers the save/failure contract, which is the key risk for a destructive write. Minor gaps remain around permissions or whether other Configuration fields are preserved, but nothing critical 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 description coverage is 100%, so the schema already documents value conversion, node_id GUID format, property name, and asset path. The description adds only the 'one field at a time' scoping nuance, 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 and resource: writing one field of a MetaSound Source node's Configuration struct. It also distinguishes its mechanism ('directly in the document, not through the MetaSound builder') from sibling write paths like metasound_set_node_input_default.

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 operational context: re-applying a value returns value_changed false but still saves, and success requires the asset to reach disk. It implies the builder-based alternative exists but does not explicitly spell out when a caller should prefer this reflection path over metasound_set_node_input_default.

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