Skip to main content
Glama

Material Manage

material_manage

Create, edit, and assign Godot materials, shaders, and VisualShader graphs with validated parameter and preset operations.

Instructions

Material authoring (StandardMaterial3D, ORMMaterial3D, ShaderMaterial, CanvasItemMaterial), raw shader source (.gdshader / .gdshaderinc), and VisualShader graph authoring/editing. Albedo, metallic/roughness, emission, transparency, shader uniforms, render modes.

Resource forms: godot://materials (all materials), godot://shader/{path} (raw source + metadata), godot://visual_shader/{path} (VisualShader graph).

Ops: • visual_shader_create_graph(resource_path, stages, shader_type="spatial", overwrite=False, varyings=None) Create/save a VisualShader .tres only (not undoable). Each stages entry is {stage, nodes: [{id, type, position?, params?}], connections: [{from_node, from_port, to_node, to_port}]}. Explicit stages must match spatial/canvas_item (vertex/fragment/light), particles (start/process/collide/start_custom/process_custom), sky (sky), or fog (fog). IDs are stage-local integers >=2 or nonempty strings; output is "output"/0. Limits: 256 nodes, 1024 connections total. Existing destination directory required. Returns id_map by stage as [{id, node_id}] in request order. varyings: [{name, mode: "vertex_to_frag_light"|"frag_to_light", type: "float"|"int"|"uint"|"vector2"|"vector3"|"vector4"|"boolean"|"transform"}] (spatial/canvas_item only). The generated source is parsed through the engine's shader compiler before saving; a graph it rejects (for example a parameter named after a shader keyword) is not written. Renderers that cannot compile a shader type fall back to validating the generated declarations, so the advertised modes stay accepted. Use create(type="shader", shader_path=<saved .tres>) then assign separately. • visual_shader_get(path) Inspect a VisualShader .tres: shader_type, per-stage nodes (id, type, position, params), connections, and varyings. Use before visual_shader_edit. • visual_shader_node_catalog(filter="", offset=0, limit=100) List instantiable VisualShaderNode classes with the properties this tool accepts, plus legacy aliases. Discover valid node types and params before authoring a graph. • visual_shader_edit(resource_path, operations) Apply a validated operation list to an existing VisualShader .tres: add_node / remove_node / replace_node / set_node_params / set_node_position / connect / disconnect / add_varying / remove_varying. Operations run in order; string node ids added by the call are returned in added and can be referenced by later operations. The whole result is validated in memory, then saved atomically; not undoable. • create(path, type="standard", shader_path="", overwrite=False) Create + save a material .tres at a res:// path. type: "standard" | "orm" | "canvas_item" | "shader". For "shader", shader_path points to a .gdshader or VisualShader .tres. • set_param(path, param, value) Set a built-in property on a .tres material. Enum-valued params accept names ("alpha" -> TRANSPARENCY_ALPHA). Color/Vector dicts. Texture properties accept res:// paths. • set_shader_param(path, param, value) Set a shader uniform on a ShaderMaterial. • get(path) Inspect a material (type, params, uniforms, current values). • list(root="res://", type="") List materials under root, optional type filter. • assign(node_path, resource_path="", slot="override", create_if_missing=False, type="standard") Assign a material to a node slot. Slots: "override" | "surface_" | "canvas" | "process". When create_if_missing=True and no resource_path, makes an inline material of type. • apply_to_node(node_path, type="standard", params=None, slot="override", save_to="", overwrite=False) High-level: build + set params + assign in one undo. save_to optionally persists to disk; errors if the file already exists unless overwrite=True. • apply_preset(preset, path="", node_path="", overrides=None) Curated looks: metal, glass, emissive, unlit, matte, ceramic. path saves to disk; node_path assigns to a node; overrides merge. • shader_create(resource_path, code, overwrite=False, shader_type="spatial") Create/replace a raw .gdshader (or .gdshaderinc include) from source text. The code is parsed through Godot's shader compiler for the declared shader type before anything is written: parse errors reject the write with diagnostics and leave any existing file untouched. This is parse/type validation, not a guarantee that every renderer variant compiles. Returns shader_type, uniforms (type, hint, hint_string, default), and cleanup hints. Not undoable. • shader_get(path) Read a .gdshader/.gdshaderinc: full source, shader_type, uniforms, render modes, and #include list. • shader_validate(code, kind="shader", shader_type="spatial", base_dir="") Parse/type-check shader source without writing a file. Returns valid plus errors/warnings. Pass base_dir (a res:// directory) to validate relative #include resolution against where the shader will live. Renderer-specific variant compilation is out of scope. • shader_patch(path, old_text, new_text, replace_all=False) Anchor-based edit of a shader file: exact substring match, result revalidated before the file is replaced. Not undoable.

Canonical call shape: {"op": "<verb>", "params": {...}}. Flat op parameters are accepted as a compatibility alias when the client transmits them; op and session_id remain top-level.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opYes
paramsNo
session_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.2.1
    • changedInput schema / properties / op / enum
      Previous value: -[
      -  "apply_preset",
      -  "apply_to_node",
      -  "assign",
      -  "create",
      -  "get",
      -  "list",
      -  "set_param",
      -  "set_shader_param"
      -]New value: +[
      +  "apply_preset",
      +  "apply_to_node",
      +  "assign",
      +  "create",
      +  "get",
      +  "list",
      +  "set_param",
      +  "set_shader_param",
      +  "shader_create",
      +  "shader_get",
      +  "shader_patch",
      +  "shader_validate",
      +  "visual_shader_create_graph",
      +  "visual_shader_edit",
      +  "visual_shader_get",
      +  "visual_shader_node_catalog"
      +]
  2. Addedv3.1.4
  3. Removedv3.0.7
  4. First observedv2.9.1

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it is exceptionally transparent. It repeatedly discloses side effects and constraints: 'not undoable' for several ops, 'generated source is parsed through the engine's shader compiler before saving', 'parse errors reject the write with diagnostics and leave any existing file untouched', 'Result is validated in memory, then saved atomically', 'Existing destination directory required', and precise limits ('256 nodes, 1024 connections total'). These behavioral details go far beyond a basic mutation warning.

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?

The description is long but well-structured: a scope overview, resource forms, then a bulleted list of ops with code-style signatures and explanatory notes. It is appropriately detailed for the tool's complexity (16 ops), and the information is front-loaded with the core purpose. Some repetition exists (e.g., 'not undoable' appears multiple times), but the overall organization makes it navigable and information-dense.

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 tool with 16 operations, no annotations, and 0% schema coverage, the description covers essentially everything an agent needs: each op's behavior, return values (e.g., shader_get returns 'full source, shader_type, uniforms, render modes, #include list'; shader_validate returns 'valid plus errors/warnings'), prerequisites, failure modes, and the canonical call shape. It also notes the fallback validation behavior across renderers, which is a subtle edge case. There is no significant missing context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate entirely. It does so comprehensively: each op is shown with full signatures, parameter meanings, defaults, constraints, and even structural details (e.g., stages entries, varyings fields, slot values, type enums). For example, visual_shader_create_graph explains the structure of stages, node IDs, port names, and limits. The description fully compensates for the schema's lack of parameter documentation.

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?

The description states the tool's scope with specific resource types: 'Material authoring (StandardMaterial3D, ORMMaterial3D, ShaderMaterial, CanvasItemMaterial), raw shader source (.gdshader / .gdshaderinc), and VisualShader graph authoring/editing.' It names the exact resources and verbs (create, edit, inspect, assign, etc.), and the title is generic but the description fully disambiguates it from sibling tools like resource_manage or script_manage.

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

Usage Guidelines3/5

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

The description provides clear intra-tool sequencing guidance (e.g., 'Use before visual_shader_edit', 'Use create(type="shader", ...) then assign separately'), but it never compares this tool to alternative sibling tools. There is no explicit statement about when to use material_manage versus resource_manage or script_manage, so the usage is implied by scope rather than explicitly differentiated.

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