Skip to main content
Glama

Review and compile shaders

godot_shader
Idempotent

Checks Godot shader files and unsaved code for Godot 4.7 naming, type, and compile errors, then optionally draws them on the Compatibility renderer to catch GPU driver issues.

Instructions

Check every shader (.gdshader, .gdshaderinc, Shader resources in scenes) two ways: a static review against Godot 4.7's own shader tables (Godot 3 names such as hint_albedo, SCREEN_TEXTURE or WORLD_MATRIX; built-ins in the wrong shader_type or function; read-only built-ins written, such as COLOR in a spatial fragment(); unknown render modes; missing includes; colour uniforms without source_color; performance hints), then a headless compile by real Godot when it is installed (no GPU needed) that adds Godot's own errors (headless Godot runs the full shader compiler). gpu: true also draws the shaders on the Compatibility renderer (needs a display, or xvfb-run on Linux; slower) for what only the GPU driver rejects: a uniform block that is too big, a sampler array indexed by a variable, a driver compile or link error. Every line is res://file:line: severity [rule] message; [godot] marks the compiler's, [gpu] the driver's. Pass code + file to check a shader before you save it (the GPU pass draws the file on disk), files for some shaders (an include also compiles the shaders that use it), compile: false to skip Godot. godot_check shaders: true runs the GPU pass over the whole project. godot_migrate rewrites the Godot 3 names; godot_api shader:spatial.fragment lists built-ins.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "godot_shader"
  }
}

Input Schema

NameRequiredDescriptionDefault
gpuNoalso draw them on the Compatibility renderer, for GPU driver errors (needs a display or xvfb-run)
codeNounsaved shader code, checked in place of the file on disk
fileNores:// path the code belongs to (required with code)
pathNoproject folder, or a file or folder inside it (relative to the server's folder; default: the current project)
filesNoonly these res:// shaders, includes or scenes
detailNobrief (capped lists) or full (everything); default full
compileNocompile with Godot (default: when Godot is found; true fails without it)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A4.6/5.0
Behavior4/5

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

Rich beyond the annotations: it discloses prerequisites (real Godot must be installed; the GPU pass needs a display or xvfb-run and is slower), what each pass uniquely catches (driver-only failures such as oversized uniform blocks or variable-indexed sampler arrays), and the exact output line format with [godot]/[gpu] provenance tags. The one unresolved point is side effects: readOnlyHint=false implies possible writes (temp files, caches, process spawning), yet the description only says 'check'/'review' and contrasts itself with godot_migrate's rewriting, leaving the annotation's meaning unexplained.

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 purpose and the two-mode structure, then mode-specific guidance; every clause is load-bearing, including the parenthetical list of static rules, which tells the agent what class of findings to expect. It is dense and runs long with nested parentheses, but there is no filler to cut.

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?

Seven optional parameters and no output schema, yet the description supplies the missing return contract ('Every line is res://file:line: severity [rule] message' with [godot]/[gpu] tags) plus environment prerequisites and per-mode costs. An agent can decide which mode to invoke and interpret the result without further context.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema does not carry: `code` requires `file` as its res:// identity and the GPU pass draws the on-disk file, `files` accepts includes and scenes and pulls in dependent shaders, and `compile` has a conditional default (when Godot is found; true fails without it). Only `path` and `detail` get no elaboration beyond the schema.

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 ('Check every shader (.gdshader, .gdshaderinc, Shader resources in scenes)') and names the two mechanisms (static review against Godot 4.7 tables, headless compile). It goes further by naming sibling tools and how they differ: godot_migrate rewrites Godot 3 names, godot_api lists built-ins, godot_check shaders:true runs the project-wide GPU pass.

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?

Explicit routing for every mode: 'Pass `code` + `file` to check a shader before you save it', '`files` for some shaders (an include also compiles the shaders that use it)', '`compile: false` to skip Godot', and `gpu: true` only when a display or xvfb-run is available. It also tells the agent when to use the alternatives instead, which is exactly the when/when-not/alternative guidance this dimension rewards.

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