Skip to main content
Glama

audit_widget_style

Read-onlyIdempotent

Sweep Widget Blueprints to find widgets whose style differs from a designated reference, reporting each deviating property path and both values.

Instructions

Sweep Widget Blueprints and report every widget whose style DEVIATES from a reference widget -- the "who is off-theme" question, which is the one that scales badly by hand once there are more than a couple of screens. You designate one widget as the truth (reference_bp_path + reference_widget_name), list the property paths that define the style (dotted paths work: "WidgetStyle.Normal.TintColor"), and this reports, per matching widget, which of those paths differ and what each side holds. Comparison is on the property's exported text, so it is type-agnostic and reports a real difference rather than a formatting one. Pair it with apply_widget_style_preset, which can copy those same paths off that same reference widget to FIX what this finds.

Returns: { reference, property_paths, widget_blueprints_scanned, widgets_compared, deviating_count, matching_count, entries: [{ widget_bp_path, widget_name, widget_class, deviations: [{path, actual, expected}], unresolved_paths: [string], matches: bool }], truncated }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
recursiveNoRecurse into subfolders (default true).
folder_pathNoContent folder to sweep for targets (default /Game).
max_resultsNoMax Widget Blueprints to load (default 500).
target_classNoOnly compare widgets of this class, matched with IsA (defaults to the reference widget's own class, which is almost always what you want).
blueprint_nameNoAlias of `reference_bp_path` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `reference_bp_path`.
property_pathsYesThe paths that define the style, e.g. ["WidgetStyle.Normal.TintColor","WidgetStyle.NormalPadding"]. A path that does not resolve on the REFERENCE is an error (the reference must define the style); one that does not resolve on a target is reported as unresolved, not as a deviation.
include_matchingNoAlso report the widgets that already match (default false).
reference_bp_pathNo/Game path of the Widget Blueprint holding the reference widget (the style source of truth).
reference_widget_nameYesName of the reference widget inside that Widget Blueprint.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already establish a safe read-only, idempotent, non-destructive profile, but the description adds real behavioral context: comparison is on exported text (type-agnostic, avoids false formatting diffs), an unresolvable path on the reference is an error while on a target it is reported as unresolved, and results are truncated. These are non-obvious semantics an agent could not derive from the annotations.

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 routing are front-loaded in the first sentence, and the trailing "Returns" block gives a compact shape of the output. Slightly wordy in the "scales badly by hand" clause, but every part earns its place for a 9-parameter comparison tool.

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 9-param read-only audit with no output schema, the description supplies the return fields inline, the comparison semantics, the reference/source-of-truth model, and the companion fix tool. An agent has enough to call it correctly without opening the schema.

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 schema carries the parameter burden (baseline 3). The description adds conceptual meaning beyond the schema by framing reference_bp_path/reference_widget_name as the "truth" and property_paths as the style definition, plus the dotted-path example, which clarifies how the parameters combine rather than just what each holds.

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 (sweep/report) and resource (Widget Blueprints) with a precise scope: reporting widgets whose style deviates from a designated reference. Names the framing question ("who is off-theme") and clearly distinguishes itself from the other audit_widget_* siblings, which check accessibility and text.

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?

Explains when this is the right tool (scaling poorly by hand past a couple of screens), how to configure the reference of truth, and explicitly routes the agent to apply_widget_style_preset as the fix for what this finds. The alternative tool and its role are named, not left to inference.

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