Skip to main content
Glama

scene_check_client

Read-only

Checks client Lua scripts against a save to catch silently mismatched names in API calls, controls, signals, and variables, reporting each issue with script, line, and nearest match.

Instructions

Check what the client scripts (Lua) of a save name against what there is, in a moment and without the game. On this platform a name that does not match is not an error: the control is not found, the signal is not heard, the variable reads nil, and nothing says so. This parses every script and looks up each name it writes as a literal: its syntax; the functions of game, the methods of script and every Enum value (the official API page); the controls it asks for (GetChild, FindChild) among the controls under the ones that carry it; the signals it sends and hears, among the signals of the save and the graphs that hear and send them, and the values it adds to a signal before sending it (AddInt, AddString ...) against what the signal carries, in order; the custom variables it reads, on the player and character templates; its own variables (GetParam); templates by index, pictures and sounds by id. Each problem comes with script, line, what is wrong and the nearest name there is. An error will not work; a warning may be on purpose (a signal no graph sends yet). scene_set_client_script, scene_add_client_ui and playtest_start run the same check on what they are given and report it; call this after the graphs are written, when everything is in the save. Read-only. It sees only literals: a name put together while the script runs is not checked, and neither is what the script does (the playtest is for that).

Input Schema

NameRequiredDescriptionDefault
mapPathNo
scriptsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint=false, and the description reinforces 'Read-only.' It adds genuinely non-obvious context: a missing name is not an error on this platform (silent nil/no-op), problems come back with script, line, issue and nearest-name suggestion, and errors vs warnings are distinguished (a signal no graph sends yet may be intentional). The one gap is that it never says what happens with the scripts parameter or how many results to expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the 'what it checks' enumeration are front-loaded, which is good, but the middle is a long comma-chained catalogue and the opening clause ('Check what the client scripts (Lua) of a save name against what there is') is grammatically tangled. Most sentences earn their place, but the prose could be tightened considerably.

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?

No output schema exists, and the description compensates by explaining the shape of each reported problem and the error/warning distinction, plus the literal-only limitation. For a read-only diagnostic tool this is close to complete; the missing piece is parameter behavior (mapPath vs scripts scoping).

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

Parameters2/5

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

Schema description coverage is 0% and the two parameters (mapPath, scripts array up to 40 entries) are never explained in the description. 'the client scripts (Lua) of a save name' gestures vaguely at the target but does not say what mapPath is or what restricting via scripts does versus checking all scripts in the save.

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: statically checking a save's client Lua scripts against actual API names (syntax, game/script functions, Enum values, controls, signals, templates, assets). It also distinguishes itself from siblings that perform the same check on partial input (scene_set_client_script, scene_add_client_ui, playtest_start) and from playtest_start which covers runtime behavior.

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 sequencing guidance: 'call this after the graphs are written, when everything is in the save.' It names the sibling tools that already run the same check on partial input, and states the exclusion clearly: only literals are checked, runtime composition and behavior are the playtest's job.

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