Skip to main content
Glama

Shaders

shader

Simplify Godot GPU program creation with ready-made templates and compile-check validation. Assign parameters and save materials directly in the editor.

Instructions

Godot shaders (.gdshader): create from ready-made templates (dissolve, outline, hit flash, water, toon, hologram, pixelate, wave, scroll, vignette...) and assign them in one call, compile-check code with the engine's shader compiler (with line numbers and Godot 3 -> 4 migration hints), read/edit, list uniforms, set shader parameters on nodes, and save ShaderMaterials. Godot 4 syntax: 'source_color' (not hint_color), 'uniform sampler2D screen_texture : hint_screen_texture' (not SCREEN_TEXTURE).

Actions:

  • templates: {} templates per shader type.

  • create: {path: 'res://shaders/x.gdshader', type?: canvas_item|spatial|particles|sky|fog (inferred from assign_to / template / scene), template?='blank' (canvas_item: blank|dissolve|outline|flash|water|toon|hologram|pixelate|wave|scroll|vignette; spatial: blank|dissolve|outline|flash|water|toon|hologram|wave|scroll; particles|sky|fog: blank), code? (instead of a template; its shader_type wins, 'shader_type ;' is added if missing), assign_to?: node path (creates a ShaderMaterial on material / material_override / process_material / environment sky; the spatial 'outline' template goes into material_overlay so the object's own materials stay), overlay? (spatial: use material_overlay), next_pass? (spatial: chain after the current material instead), surface?, params?: {uniform: value}, material_path?: also save the ShaderMaterial as .tres, overwrite?} write + compile-check. Returns ok, diagnostics and uniforms.

  • validate: {path | code, type?} compile with Godot's shader compiler (first error with line) + lint (missing shader_type, unbalanced braces, Godot 3 names like hint_color/SCREEN_TEXTURE/WORLD_MATRIX). type is prepended when code lacks shader_type.

  • read: {path: .gdshader | ShaderMaterial .tres | node path} code, shader type and parsed uniforms.

  • edit: {path, edits: [{old, new, replace_all?}] | code} exact replacements (or full replacement) then re-validate; returns diagnostics.

  • uniforms: {path: .gdshader | material .tres | node path} uniforms with type, hint, default, range, group and current value (for materials).

  • set_param: {path: node path | ShaderMaterial .tres, param + value | params: {name: value}, material_index?} set shader parameters (coerced: '#hex' colors, [x,y,z] vectors, 'res://tex.png', {type: 'NoiseTexture2D', noise: {type: 'FastNoiseLite'}}). Undoable on nodes with embedded materials; a node whose ShaderMaterial is a shared .tres file edits and saves that file.

  • material: {path: 'res://materials/x.tres', shader: 'res://x.gdshader', params?: {uniform: value}, props?: {render_priority, next_pass}, assign_to?: node path, surface?, overwrite?} create a ShaderMaterial file, or update an existing one in place (keeps its other params; overwrite=true starts fresh). Optionally assign it to a node.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoShader source code.
pathNores:// .gdshader / .tres path, or node path (read/uniforms/set_param).
typeNoShader type: canvas_item | spatial | particles | sky | fog.
editsNoExact replacements.
paramNoOne uniform name (set_param).
propsNoProperty map. Values are coerced to the property type: numbers, [x,y], 'Vector2(1,2)', '#ff8800', 'res://file', {"type":"RectangleShape2D","size":[32,32]} for new resources, enum names as strings.
sceneNores:// scene to operate on; opened in the editor if needed. Defaults to the currently edited scene.
valueNo
actionYesWhat to do. See the tool description for each action's parameters.
paramsNoShader parameters {uniform: value}.
shaderNores:// .gdshader for a ShaderMaterial.
overlayNoshader.create: assign a spatial shader to the node's material_overlay.
surfaceNoMesh surface index (spatial).
templateNoTemplate name (see 'templates').
assign_toNoNode path to put the new ShaderMaterial on.
next_passNoshader.create: chain a spatial shader as next_pass of the node's current material.
overwriteNoReplace an existing file.
material_pathNoAlso save the created ShaderMaterial to this .tres.
material_indexNoWhich ShaderMaterial on the node when it has several (default: the one with those uniforms).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

The annotations already disclose readOnlyHint=false, destructiveHint=false, and openWorldHint=false, but the description goes well beyond them: it notes that create writes and compile-checks, returns ok/diagnostics/uniforms, set_param is undoable on nodes with embedded materials, a shared .tres material edits and saves that file, and overwrite=true starts fresh. It also discloses validation behavior such as first-error line numbers, lint checks, and Godot 3-to-4 migration hints.

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 it is structured around the eight actions and front-loads the overall purpose before listing action-specific parameters. Most sentences carry actionable detail, though the Godot 4 syntax note and some action descriptions are dense enough that the text could be tightened slightly.

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?

Given eight actions, nineteen parameters, no output schema, and only minimal annotations, the description is complete enough for an agent to invoke the tool correctly. It covers action selection, key parameter interactions, return values such as diagnostics and uniforms, side effects, and Godot-version syntax constraints.

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?

Schema coverage is 95%, so the baseline would be 3, but the description adds substantial action-specific meaning beyond the schema: it documents template names per shader type, type inference from assign_to/template/scene, special handling for spatial outline via material_overlay, overlay and next_pass routing, params coercion examples, and material update semantics. These details help an agent choose and populate the correct parameters rather than relying on generic schema descriptions.

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 a specific verb set and resource: it creates/read/edit/validates Godot .gdshader files, assigns them to nodes, lists uniforms, and saves ShaderMaterials. The opening sentence enumerates the exact scope and includes recognizable Godot-specific artifacts, so an agent can distinguish this from general resource, script, or node tools.

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?

The description gives clear context for each action through the 'Actions:' section, including when to use templates, create, validate, read, edit, uniforms, set_param, and material. It does not explicitly name alternative tools or state when-not-to-use conditions, but the action-level guidance is strong enough to route most invocations correctly.

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