Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

get_material_expressions

Read-onlyIdempotent

List every node in a material graph with its name, class, and description. Inventories material structure and counts expressions when deleting nodes.

Instructions

List every node in a material's graph with its name, class and description -- the census that tells you what a material is built from, and the count oracle when deleting nodes one by one (delete until it reaches 0). Also the way to spot the duplicate parameter nodes a partial bulk-delete leaves behind, which no parameter listing shows because duplicates collapse by name. Nodes only: for the WIRING between them use get_material_graph_info, and note this works on a UMaterial, not a UMaterialFunction (the Python equivalent throws on one).

Returns: { material_path: string, material_name: string, expressions: [{ name, class, class_path, description }], expression_count: int, success: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
material_pathYesFull path to the material (e.g., '/Game/Materials/MyMaterial.MyMaterial')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: parameter listings collapse duplicates by name (so this tool is needed to see them), and the underlying Python call throws on a UMaterialFunction. The throwing constraint is a notable gotcha, though it could have stated the exact error or whether the input path is validated first.

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 delete-count use case are front-loaded, and each sentence carries useful information. Some phrasing is colored ('the census', 'count oracle') and could be tightened, but nothing is redundant filler.

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?

Although there is no output schema, the description inlines the full return shape, and it covers constraints, the sibling for wiring, and the asset-type limitation. An agent has everything needed to call it correctly.

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?

Only one parameter with 100% schema description coverage (full example path format included), so the schema carries parameter meaning. The description adds essentially nothing new about material_path beyond echoing it in the return shape, which is the baseline-3 case for high coverage.

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 (List) and resource (every node/expression in a material's graph) with its returned fields (name, class, description). It explicitly distinguishes itself from the sibling get_material_graph_info (nodes vs wiring), so an agent can select between them without opening schemas.

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 cases (census of what a material is built from, count oracle while deleting nodes until count reaches 0, spotting duplicate parameter nodes left by partial bulk-deletes), names the alternative for wiring (get_material_graph_info), and states the exclusion (UMaterial, not UMaterialFunction).

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