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

With no annotations, the description carries the full burden. It does disclose useful behavioral facts: the two accepted input formats, the default slot (on top), and that indexing happens immediately. It omits failure modes, duplicate-layer behavior, persistence, and whether a subsequent operation is required.

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

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

Two compact sentences, front-loaded with the core action and followed by the positional nuance. Nothing is padded, though the position detail could be folded in more cleanly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. For a mutating, annotation-free, three-parameter tool with zero schema descriptions, the definition covers the essentials but leaves gaps around failure behavior and the unexplained 'name' parameter.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It partially does so by explaining 'position' (1-based slot, defaults to top) and by describing what 'path' may point to, but 'name' is left entirely unexplained and no format examples are given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Register a mod layer') and immediately clarifies the accepted inputs (unpacked folder with Public/ and Mods/, or a .pak file). This is clearly distinguishable from sibling tools like bg3_remove_mod_layer and bg3_layers.

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

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

The description never says when to reach for this tool versus alternatives, nor does it state prerequisites (e.g. whether a refresh/deploy is needed afterward, or what happens on order conflicts). Usage is only inferable from the name and siblings.

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

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

No annotations, so the description carries the full burden and does well: it discloses the game-running refusal, that the previous pak is backed up, that enabling happens after dependencies in modsettings.lsx, and that it re-runs after load-order rewrites. It omits permission/auth requirements and any return-value detail, but the output schema covers returns.

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

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

Dense and front-loaded: the core action leads, followed by constraints and caveats in a parenthetical. Every clause earns its place, though the single long sentence is slightly run-on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-step deploy operation with an output schema present, the description covers the essential mechanics, side effects, and preconditions. The main gap is under-specification of the two parameters, particularly the 'enable' flag.

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

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

Schema description coverage is 0%, so the description must compensate. It implies 'layer' corresponds to a folder under Mods/ and Public/ (Mods/<folder> + Public/<folder>), which helps. However, the 'enable' boolean (default true) is only obliquely implied by 'enable it in the active profile's modsettings.lsx' and is never explicitly explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific verbs and resource: pack a mod layer via Divine, deploy the pak to the user Mods folder, and enable it in modsettings.lsx. This is clearly distinguishable from siblings like bg3_add_mod_layer (which adds a layer rather than packaging/deploying one) and bg3_remove_mod_layer.

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

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

Gives clear when-to-use context: 'Works for any mod; no per-mod scripts' and 'Re-run after a mod manager rewrites the load order.' The refusal condition (game running) is stated. It stops short of explicitly naming alternative siblings or when-not-to-use beyond that condition.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state whether the tool is read-only, what output format to expect, how layers are resolved, or any error/side-effect behavior beyond the basic diff concept.

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

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

The description is a single front-loaded sentence with no filler, using backticks to call out key inputs. Its brevity is appropriate structurally, though the terseness leaves important details unstated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is not strictly needed, but with no annotations and 0% parameter coverage the description should do more. It omits usage context and parameter meaning, making it incomplete for a three-parameter diff tool.

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

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

Schema description coverage is 0% and there are three parameters, but the description only loosely indicates that `layer` and NAME are involved. It does not explain the optional `layers` parameter or clarify accepted layer/name formats, leaving most parameter semantics undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific operation: showing what a given `layer` changes about a stats entry NAME relative to lower layers. It is clear enough to distinguish from direct retrieval tools like bg3_get_entry, though it does not explicitly name any sibling alternative.

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

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

The description gives no guidance on when to use this tool versus alternatives such as bg3_get_entry, bg3_layers, or other inspection tools. Usage is only loosely implied by the diff wording.

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

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

No annotations exist, so the description carries the full behavioral burden. It clarifies the return shape (MultiEffectInfo with names, bones, duration, looping, .lsfx) and notes it lists using stats entries, but says nothing about whether it is read-only, what happens on an unknown GUID, error behavior, or the purpose of 'layers'.

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

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

Two sentences with no filler, front-loaded with the verb and resource. Dense but organized; the only minor cost is that the return-shape enumeration makes it slightly list-heavy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be described, and the description does add provenance (stats entries that use it). However, with zero schema coverage and no annotations, the undefined 'layers' parameter and absent behavioral/error detail leave real gaps for a two-parameter resolver.

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

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

Schema description coverage is 0% for two parameters, so the description must compensate. It explains what a GUID resolves to but never defines the 'layers' parameter or the expected GUID format (none/guid/lsfx), leaving a required and an optional parameter effectively undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Resolve) and resource (an effect GUID, spanning MultiEffectInfo or a single effect resource), and enumerates the returned component fields. It is clear what the tool does, though it doesn't name the sibling bg3_search_effects (which searches rather than resolves), leaving sibling differentiation implicit.

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

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

No when-to-use, when-not-to-use, or alternative routing is provided. An agent seeing both bg3_effect and bg3_search_effects gets no guidance on which to pick; the role of the 'layers' parameter is also unexplained.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implicitly communicates a read-only inspection (it says 'what this machine looks like,' not that it changes anything), and it discloses the breadth of discovery (Steam/GOG/configured install, mod managers, layer deploy states). However, it never confirms it is side-effect-free and says nothing about refresh/caching or rate behavior, which matters for a discovery tool.

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

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

It is a single sentence, but it is a very long one with a sprawling list separated by commas and a dangling 'and what they mean for hand-deployed paks.' The core purpose is not front-loaded; an agent must read to the end to infer that this is a discovery/environment report.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail needn't be restated, and the description lists the major facets covered. But for a zero-param discovery tool with no annotations and 45+ siblings, the description gives no signal about when to reach for it versus bg3_layers, bg3_toolkit_status, or bg3_se_status, leaving a real selection gap.

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

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

There are zero parameters, so per the rubric the baseline is 4. The description correctly contains no parameter discussion because none are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource ('this machine' as seen by bg3-data) and enumerates the specific environment facets it reports (OS, game install, exe paths, mod managers, mod layer states). It is clear what the tool does, but the phrasing 'What this machine looks like to bg3-data' is somewhat literary rather than an action verb, and it doesn't explicitly differentiate itself from the many sibling introspection tools (bg3_layers, bg3_toolkit_status, bg3_se_status).

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

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

There is no when-to-use guidance at all: no statement that this should be called to discover paths before deploying mods, no exclusion of when another tool (e.g., bg3_layers) is more appropriate. The list of contents implies a discovery role but never states it.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that the game is killed, that unsaved progress is lost, the exact relaunch mechanisms (Steam -applaunch vs game exe for GOG), that --skip-launcher -continueGame loads the NEWEST save, and that it blocks until a host character is loaded.

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

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

A single dense sentence, front-loaded with the kill/deploy/relaunch sequence. The parenthetical clauses (deploy fallback, Steam vs GOG, launcher flags) all earn their place, though the nested parentheses reduce immediate readability slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, side-effect-heavy tool with an output schema present, the description covers the important behavioral facts (data loss, blocking wait, launch variants). It is complete enough to call correctly; only the absence of explicit when-to-use guidance keeps it from a 5.

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

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

Schema description coverage is 0%, but the description supplies real meaning for both parameters: 'launch' maps to the relaunch step and 'deploy_layer' to the optional mod layer selection. It stops short of stating parameter names or the null/default semantics, so it only partially compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb sequence (kill, deploy, relaunch, wait) on a specific resource (the BG3 game process), and explicitly routes the mod-layer step to either a layers.json deploy command or the built-in bg3_deploy sibling. An agent can distinguish it from bg3_deploy or bg3_refresh without opening any schema.

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

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

It says what happens on each step and that deployment is optional, and it names the alternative deploy mechanism. However, it never states when an agent should call this full restart vs just bg3_deploy or bg3_add_mod_layer, so the usage decision is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool resolves through inheritance, shows the `using` chain, and reports which layer/source set each field, which is useful. However, it does not state read-only safety, side effects, or any constraints, leaving gaps for an operation with no annotations.

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

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

The description is two tightly written sentences with no wasted words. It front-loads the core purpose and then adds the output behavior, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained here. With three parameters at 0% schema coverage and no annotations, the description is only partially complete: it implies layer and provenance behavior but omits parameter specifications, defaults, and any usage prerequisites. It is adequate at a high level but leaves actionable gaps for correct invocation.

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

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

Schema description coverage is 0% for all three parameters. The description only vaguely alludes to `layers` ("selected layers") and `provenance` ("per field, the layer/source that set it"), but does not define any parameter explicitly, explain defaults, or clarify the `name` input format. It fails to compensate for the complete lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (Resolve) and resource (stats entry), with examples of entry types. It also explains the key behavior (inheritance via layers, showing the `using` chain and source per field), which helps distinguish it from less specialized siblings. However, it does not explicitly name or contrast against alternative tools like bg3_search or bg3_static, so sibling differentiation remains implicit.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or excluded scenarios. While its purpose suggests it is for resolving entries with inheritance, there is no explicit context for selection among the many bg3_* siblings.

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

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

No annotations exist, so the description carries the full behavioral burden. It usefully explains that the engine silently drops invalid values, which is the reason the check matters, and the framing implies a read-only comparison requiring a running game. However, it does not state mutability, required game/runtime state, or error behavior when a layer is absent.

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

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

Two tightly written sentences with the core comparison front-loaded and the silent-drop rationale and the `layers` default appended where they belong. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, so return values need not be described, and the comparison purpose is conveyed. But with a required parameter undocumented and no behavioral safety context, the definition is only adequate for a two-parameter diagnostic tool.

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

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

Schema coverage is 0% and there are two parameters. The description clarifies only `layers` ('what's deployed, default: all'). The required `layer` parameter is left entirely undefined, and the meaning of the singular/plural pair is not disambiguated, so the description only partially compensates for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: compare every stats entry a mod layer defines against what the running game actually loaded. This is clearly distinct from sibling lint/static tools. It does not explicitly name the alternative (e.g., bg3_lint_stats), so it stops short of full sibling differentiation.

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

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

Usage is implied rather than stated: the parenthetical that the engine drops invalid values silently signals this is a post-deploy diagnostic, but there is no explicit when-to-use, when-not-to-use, or comparison to bg3_lint_stats or bg3_toolkit_check. An agent must infer the context.

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

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

No annotations are provided, so the description carries the disclosure burden. It does convey what the listing contains (load order, timestamps, entry counts), which implies a read-only inspection operation, but it says nothing about permissions, cost, or ordering guarantees beyond 'load order'.

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

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

A single front-loaded sentence with no filler; the resource and its salient output attributes are stated immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and zero input parameters, the description does not need to explain return values or inputs, and it supplies a useful one-line summary of the result shape. Only the missing usage routing against sibling tools keeps it from being fully complete.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is no parameter semantics to add and the description does not waste words on nonexistent inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Uses a specific verb+resource ('List data layers') and adds scope detail (load order, source timestamps, entry counts). It is clearly distinguishable from the mutation siblings bg3_add_mod_layer / bg3_remove_mod_layer, though it never names them explicitly.

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

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

There is no when-to-use guidance, no prerequisites, and no reference to any alternative tool. The agent must infer from the name alone that this is the read-side counterpart to the add/remove layer tools.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses what is inspected (added/removed passives, AddSpells with source, ActionResource boosts, level choices), but never states that the operation is read-only, whether it mutates anything, or what permissions/state it requires.

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

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

One dense sentence that front-loads the core comparison and then lists the checked categories. No filler, though the enumeration is packed tightly enough that it reads more like a spec fragment than guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be explained, and the description does cover the compared categories. However, the unexplained 'layers' parameter and the absence of any when-to-use framing leave real gaps for a verification tool with many overlapping siblings.

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

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

The single 'layers' parameter has 0% schema description coverage and is not mentioned anywhere in the description, so an agent gets no guidance on what a layer is or how it affects the comparison. With low coverage the description should compensate, and it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Compare') and resource ('host with its class/subclass progressions up to its current level') and enumerates the checked categories (passives, AddSpells, ActionResource boosts, choices). It is distinguishable from nearby siblings like bg3_progression or bg3_level_up, though the domain term 'host' is left unexplained.

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

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

There is no statement of when to use this tool versus alternatives such as bg3_progression, bg3_ingame_check, or bg3_level_up. Usage is only inferable from the verb 'compare', and no prerequisites or exclusions are given.

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

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

With no annotations, the description carries the full burden and does well: it discloses that this grants XP rather than setting levels directly, that the user then levels up in the UI so features/spells are class-sourced, and the intended follow-up. It omits permissions, save-state impact, and failure behavior, keeping it short of a 5.

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

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

Two tight sentences, front-loaded with the action, then the important nuance and follow-up step. No filler; every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. For a 2-param tool with no annotations, the description covers the action, mechanism, and follow-up well, though it leaves the layers parameter's semantics and edge cases thin.

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

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

Schema coverage is 0%, so the description must compensate. It gives meaning to `levels` (number of levels to gain) and implies `layers` is the source of XPData, but never explains layers=null behavior or the defaults, leaving real gaps for a 0%-coverage schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: grant the host exactly enough XP to reach `levels` more levels. It also clarifies the mechanism (XP grant sourced from layers' XPData) and names the follow-up sibling bg3_level_check, which differentiates its role from a check tool. Clear, though not a full contrast against alternatives.

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

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

Provides sequencing guidance ('follow with bg3_level_check') and implies usage when you want to grant levels, but gives no when-not conditions or explicit comparison against sibling tools. Usage is implied rather than spelled out.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds meaningful context about game behavior that the schema cannot express: 'the game silently drops those nodes' and 'both load, so their choices/feats stack.' However, it doesn't state whether this is read-only (it is a lint tool, so read-only is implied but unstated), what output looks like, or any rate-limit/performance considerations. For a lint tool the behavior description is adequate but not rich.

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

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

A single dense sentence with clear enumeration of the checks performed. Front-loaded with the purpose. No waste, but the density makes it slightly hard to parse; it's efficient though.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains what the tool checks and includes useful game-mechanics context, but with 0% schema coverage and no annotations, the description leaves parameter semantics and output format unaddressed. An output schema exists, so return values needn't be described. For a 2-param lint tool with a focused purpose, this is minimally adequate but incomplete given the schema coverage gap.

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

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

Schema description coverage is 0%, but there are only 2 parameters and the description doesn't describe them at all. The names 'layer' (required) and 'layers' (optional, array, default null) have unknown semantics – does 'layer' identify the primary mod layer? Does 'layers' restrict the check to a subset? The description provides no parameter guidance, which is a gap given the 0% coverage. Baseline for 2 params is 4, but with 0% schema coverage the description must compensate, and it doesn't – so 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('static progression checks') and enumerates exactly what is checked: invalid node UUIDs, selectors referencing undefined lists, and same table+level node collisions. It distinguishes itself from siblings by the 'static progression checks' framing, though the name itself ('lint') already implies much of this. The detail on what is checked is the strongest element.

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

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

No explicit when-to-use or when-not-to-use guidance. It doesn't clarify how this differs from related tools like bg3_static, bg3_progression, or bg3_lint_stats, all of which could plausibly overlap. The description explains what it checks but not when an agent should invoke it versus alternatives.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose meaningful behavior: the check is static, the engine 'silently drops what it doesn't know' (explaining why the lint matters), and it lists the validation categories. It does not state whether the tool is read-only, whether it can mutate layer files, how findings are reported (errors vs warnings), or any cost/latency characteristics.

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

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

A single dense sentence that front-loads the purpose ('Static stats lint for a mod layer') before the parenthetical detail. Every clause adds a distinct validation category, so little is wasted, though the parenthetical enumerations are heavy enough to slow reading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The existence of an output schema relieves the description of explaining return values, and the enumerated check categories are a genuinely complete account of what is validated. The gap is on the input side: with 0% schema coverage, 3 undocumented parameters, and no annotations, the description leaves the agent without enough to call the tool confidently (e.g., layer vs layers semantics).

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

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

Schema description coverage is 0% across 3 parameters, so the description must compensate and does not. 'For a mod layer' loosely gestures at the required 'layer' argument, but the relationship between 'layer' and the optional 'layers' array, and the meaning/effect of 'limit' (default 200), are entirely unexplained in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Static stats lint for a mod layer') and enumerates exactly what classes of problems it catches (enum values, unused functor/condition/boost names, missing referenced entries, unknown action resources). It is clearly distinguishable in spirit from the sibling bg3_lint_progressions, though it never names that sibling to make the boundary explicit.

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

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

Timing guidance is implied but useful: 'before the game ever loads it' tells the agent this is a pre-load check rather than a runtime test. However, there is no explicit when-to-use/when-not-to-use statement and no routing to bg3_lint_progressions or the bg3_test_* tools, so the agent must infer the alternative.

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

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

No annotations are provided, so the description carries the full burden. It never states that this is a read-only operation, what the layers parameter filters, pagination/limit behavior, or what scope of localization data is searched. For a search tool with zero annotation coverage this is a notable gap.

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

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

A single well-formed sentence with no filler, and the core purpose is front-loaded. However, given 3 undocumented parameters and two distinct operating modes, this level of brevity leaves the definition under-specified rather than genuinely concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. Still, the description omits any mention of the layers filter, the limit default, or how handle-lookup and text-search modes differ — all of which an agent needs to call this tool correctly.

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

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

Schema description coverage is 0% across 3 parameters. The description explains only the 'query' parameter's handle form; 'layers' and 'limit' are left entirely undocumented in both schema and description. It adds a little meaning for query but does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: looking up a localization handle, or searching localized text. The example handle format helps an agent recognize the input type. It does not distinguish itself from the general-purpose sibling bg3_search, which leaves some ambiguity.

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

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

The description offers two modes ('look up a handle' or 'search localized text') but never says when to pick one over the other, and gives no routing against siblings like bg3_search or bg3_get_entry. Nothing tells the agent prerequisites or the difference between handle lookup and free-text search.

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

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

With no annotations, the description must carry the full behavioral burden. It adds useful merge semantics (higher layer's node replaces lower one's) and notes that the key may be a Name or TableUUID, but does not state whether the operation is read-only, what permissions are required, or what side effects exist.

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

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

The description is one concise sentence with no filler, and the core resource and merge behavior are front-loaded. Every phrase contributes to understanding the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. However, for a three-parameter tool with no annotations and no schema descriptions, the description omits level and layers semantics and any usage context, leaving it substantially incomplete.

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

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

Schema description coverage is 0%, so the description must document parameters. It explains the key parameter accepts a Name like 'Soulknife' or a TableUUID, but gives no meaning for the level or layers parameters, leaving two of three parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States the resource (progression nodes for a class/subclass) but gives no explicit verb, so the agent must infer whether the tool retrieves, builds, or merges progression data. It also does not differentiate itself from siblings such as bg3_lint_progressions.

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

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

The description provides no when-to-use guidance, prerequisites, or alternatives despite many sibling tools. The agent has no routing signal for choosing this tool over related progression or level tools.

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

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

No annotations are provided, so the description carries the full burden. It does not state whether the operation is read-only (implied but unstated), how the limit parameter behaves, what layers restrict the search, or anything about ordering or pagination of results.

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

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

A single tight sentence with the scope front-loaded and no padding. It is efficient, though the parenthetical enumeration slightly crowds the core claim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. However, for a 3-parameter tool with zero schema coverage and no annotations, the description is too thin — the behavior of `limit` and `layers` is left entirely to inference.

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

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

Schema coverage is 0%, so the description must compensate. It hints that the token can match entry name, status, passive, or GUID, which adds real meaning to the required `token` param, but says nothing about `limit` or `layers`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys the result set well: anything mentioning the token across stats, templates, progressions, and lists. But it never names the operation (find/search/reference-lookup) and does nothing to distinguish itself from siblings like bg3_search or bg3_get_entry among 43 peers.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as bg3_search, which plausibly overlaps. The agent must infer this is a reverse-lookup tool purely from the wording.

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

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

No annotations, so the description carries full burden. It usefully discloses the default incremental behavior versus force rebuilding regardless of changes, but omits side effects, cost/time, whether the operation is reversible, or any permission requirement.

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

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

Two tight sentences with the primary behavior front-loaded and the parameter detail second. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and the single optional parameter is fully covered. The remaining gap is that a mutation-like operation with no annotations gives no safety, cost, or prerequisite context.

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

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

Schema coverage is 0% and the schema only shows an undifferentiated string/null type, so the description is the sole source of meaning. It correctly explains that force takes a layer name or the literal 'all' to bypass change detection, which is material information absent from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (re-index) and resource (layers) with a scoping condition (sources changed). Clear enough to distinguish from read-only siblings like bg3_layers, but it never names an alternative or contrasts with related tools such as bg3_add_mod_layer.

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

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

Implied usage only: the default handles changed sources and force handles everything else, which hints at when each mode applies. There is no explicit when-to-use statement, no prerequisite (e.g. mod layers must be loaded first), and no routing to siblings.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses one meaningful trait (base layers are immutable), but omits what removal actually does to dependent layers/mods, whether the action is reversible, and any permission or side-effect context.

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

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

A single front-loaded sentence with the action first and the constraint in a parenthetical. No filler; the only critique is that brevity here borders on under-specification, which is scored elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the tool's complexity is low (one param). Still, with zero annotation coverage and an undocumented parameter, the description leaves gaps an agent would need for confident invocation.

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

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

The single 'name' parameter has 0% schema description coverage, so the description must compensate and does not. It never explains what form the name takes (layer name vs identifier) or any constraints on it, leaving the parameter effectively undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (unregister) and resource (mod layer), making the inverse relationship with the sibling bg3_add_mod_layer obvious. The parenthetical clarifies scope, though it does not explicitly name the sibling it complements.

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

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

The constraint 'base cannot be removed' functions as a partial when-not rule, informing the agent of one illegal case. However, it never states prerequisites (the layer must already be registered) or points to the natural alternative bg3_add_mod_layer.

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

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

No annotations are provided, so the description carries the full burden. It does disclose real behavior beyond the schema: matching is 'name or any field contains text', and defined_in restricts to entries the layer itself defines or overrides. It stops short of stating read-only nature, result-limit behavior, or performance considerations, so it is adequate but incomplete for a zero-annotation tool.

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

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

Terse, front-loaded, and every clause maps to a parameter or matching rule. The key:value shorthand is efficient, though slightly cryptic for the defined_in example.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation. However, with six parameters at 0% schema coverage, undocumented limit/layers plus absent usage and sibling-routing guidance leave the definition minimally viable rather than complete.

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

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

Schema coverage is 0%, so the description must compensate. It meaningfully explains type (with concrete value examples like SpellData, StatusData, Weapon), field, and defined_in, but leaves limit and layers completely undocumented. Four of six parameters get some treatment, two get none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with matching semantics: 'Find stats entries whose name or any field contains `text`.' That is enough to distinguish the tool from generic siblings, but it never differentiates itself from close siblings like bg3_search_effects, bg3_get_entry, or bg3_spell_list, so an agent cannot tell which search to pick from the name alone.

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

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

No when-to-use guidance, no prerequisites, and no alternatives named. The description reads as parameter notes rather than usage instructions, so the agent must infer when this is the right search tool versus bg3_search_effects or bg3_get_entry.

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

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

With no annotations, the description carries the full burden. It usefully discloses the matching algorithm (name or any component effect's name) and the shape of what's returned, but says nothing about read-only nature, case sensitivity, pagination behavior via limit, or what 'layers' scopes. Partial behavioral coverage.

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

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

Single dense sentence with the core purpose front-loaded and examples inline; every clause adds value. Slightly awkward line wrapping but no wasted content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter search tool with an output schema, the essential input semantics ('text') and return shape are covered. However, limit and layers remain unexplained anywhere, so an agent cannot use them correctly without guessing.

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

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

Schema description coverage is 0%, so the description must compensate, and it only explains the 'text' parameter's matching semantics. Neither 'limit' (default 20) nor 'layers' is explained in the schema or the description, leaving two of three parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Find/search) and resource (effects), and clarifies the matching rule: the MultiEffectInfos name OR any component effect's name. Concrete examples ('Necrotic', 'Impact_BodyFX') and the downstream use (GUID for a stats *Effect field) make it clearly distinguishable from siblings like bg3_search, bg3_effect, and bg3_spell_visuals.

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

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

Usage is implied through the stated purpose: find an effect GUID to place in a stats *Effect field. That gives real context for why an agent would reach for this tool, but it names no alternatives and provides no when-not guidance (e.g., versus bg3_search or bg3_effect).

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose useful context: the command goes to the running game, log lines are captured for `wait` seconds, and the cap is 60. It says nothing about side effects of arbitrary commands, whether the game must be running, or what happens on timeout.

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

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

A single front-loaded sentence with the core action first, then the return behavior, then the wait cap. Tight and waste-free, though the parenthetical example slightly interrupts the flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the return-value description need not be exhaustive. However, with no annotations, 0% schema coverage, and an unmentioned `context` parameter, the definition is only minimally complete for a command-execution tool that can have real in-game side effects.

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

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

Schema coverage is 0%, so the description must compensate. It gives the `line` semantics via an example and explains `wait` as seconds with a max of 60, which adds real value, but the `context` parameter (default 'server') is never mentioned, leaving one of three parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Send one Script Extender console line to the running game', and the inline example ('!apofeature Barbarian_PersistentRage') makes the action concrete. It does not explicitly differentiate from nearby siblings like bg3_se_eval, so an agent must infer that this is a raw console line rather than a Lua evaluation.

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

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

Usage is only implied by the example and the 'running game' qualifier; there is no stated when-to-use vs bg3_se_eval or the other se_* tools, and no mention of prerequisites like the game being live. Adequate for a console-send tool but leaves routing to inference.

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

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

With no annotations, the description carries the full burden and does flag the critical trait: 'This executes code in the user's live game session', warning of real side effects. It also explains the delay's behavioral intent. It omits error/failure behavior and whether state persists, which matters for arbitrary live code.

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

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

Tight and front-loaded: the core action leads, then per-parameter notes, then a closing safety caveat. Every clause carries information; only the bare 'context:'/'delay:' fragments make it feel slightly terse rather than polished.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is fairly covered. But this is an arbitrary-code-execution tool with zero annotations and no output-side safety framing; missing timeout semantics and failure modes leave the agent under-informed for a high-risk live-session operation.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it defines the two contexts with parenthetical api hints, explains delay with a concrete rationale, and names the BG3T harness global. Only 'timeout' goes unexplained, which is the one clear gap against a 4-param tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: run Lua inside the running game via Script Extender, and returns printed output plus return value. An agent can tell this is a live-code-execution tool. However, it does not distinguish itself from near siblings like bg3_se_command or bg3_test_script, leaving the agent to infer the boundary.

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

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

It gives useful in-tool guidance (choose 'server' for game logic, 'client' for UI/visuals; set delay to let a cast or boost resolve) but never says when to reach for this tool versus bg3_se_command, bg3_se_live_entry, or bg3_test_script. Usage is implied rather than routed.

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

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

No annotations provided, so the description carries the full burden. It usefully discloses that 'Entries already hot-loaded stay in the running session until restart' — a non-obvious behavioral trait. It does not cover safety/reversibility or required game state, but the session-persistence detail is valuable.

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

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

Two tight sentences, no waste. The scope (path pattern) is front-loaded and the behavioral caveat follows.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists so return values needn't be explained. For a zero-param cleanup tool, the description covers what it removes and the session-persistence caveat. Missing: whether the operation is safe/idempotent and any precondition (e.g., game closed).

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

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

Zero parameters, so baseline is 4. The description correctly implies no arguments are needed beyond the fixed path pattern it targets.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: 'Remove the loose hot-load folders (Data/Public/BG3DataHot_*) from the game install.' Names the exact path pattern being cleaned. Distinguishable from siblings like bg3_se_hot_load and bg3_test_cleanup by the specific target.

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

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

Implied context — this is a cleanup tool, use it to remove hot-load folders. But no explicit when-to-use or when-not, and no reference to alternatives like bg3_se_reset_lua. The sibling name bg3_se_hot_load suggests a pair, but the description doesn't state the relationship.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that entries are written as loose files under a specific path, loaded with overwrite semantics ('overwriting existing entries'), synced to the client, and optionally pushes English strings. It also warns that saving the game while relying on hot-loaded entries is unsafe.

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

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

The key action and scope are front-loaded, and every clause carries useful technical detail about the load mechanism and constraints. It reads as one dense run-on paragraph, but given the complexity of the operation little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation. Combined with the explicit limitations (what cannot be hot-loaded), the save-safety caveat, and the cleanup pointer, the description is complete enough for an agent to call it correctly.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: it clarifies files (only stats files, e.g. ['Passive.txt']), loca (loc=True pushes English strings), and layer (the mod layer being mirrored). Minor gaps remain — no detail on layer naming or what happens if files is null beyond defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('HOT-LOAD a mod layer into the RUNNING game without restarting') and contrasts it with the restart-with-pak path, which cleanly separates it from siblings like bg3_add_mod_layer. An agent can identify the operation and its scope without opening the schema.

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

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

Provides explicit when-to-use (a running game, no restart), when-not (progressions/lists/templates cannot be hot-loaded — restart with a pak), and an alternative route. It also routes cleanup to the named sibling bg3_se_hot_clean and flags the test-only constraint.

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

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

With no annotations, the description carries the burden but only partially. It usefully discloses output behavior (each field shown as MATCH or DIFF) and implies a read-only comparison, but says nothing about permissions, side effects, or whether it touches the running game state.

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

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

Three short, front-loaded sentences with no filler; the core comparison is stated first. The domain jargon ('SE', 'index') is dense but the structure itself is tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value format need not be explained. However, for a 3-parameter tool with 0% schema coverage and no annotations, the description omits what `name` and `fields` mean and what 'the index' refers to, leaving an agent unable to fully invoke it from the description alone.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the `layers` parameter meaningfully ('the index's resolution for layers', 'pick layers matching what's deployed') but leaves `name` and `fields` entirely unexplained, leaving most parameters undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: it compares a stats entry as the running game loaded it against the index's resolution. 'Ground truth' frames it as a verification/diagnostic tool. It does not explicitly differentiate from close siblings like bg3_get_entry, bg3_diff, or bg3_ingame_check, so it stops short of a 5.

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

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

The only usage-like sentence, 'Pick layers matching what's deployed,' is guidance about the layers argument, not about when to choose this tool over alternatives. There is no when/when-not framing and no named alternative among the many siblings.

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

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

With no annotations, the description carries the full behavioral burden. It adds useful scoping ('current game run's' log) but never confirms this is a non-mutating read, does not mention whether the log is truncated, buffered, or where it lives, and gives no pagination or refresh semantics.

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

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

A single tight sentence that front-loads the operation and then the optional refinement. No wasted words, though the parenthetical examples could be folded in more economically.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shape needn't be described. However, with zero annotations and 0% schema coverage on a log-tailing tool, the description omits key operational facts such as the `lines` behavior and whether the read is safe/repeatable.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It explains the `filter` argument well (with concrete examples), but the `lines` parameter is never mentioned at all, leaving half the input surface undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (Tail) and resource (the current game run's Script Extender runtime log), which is precise enough for an agent to understand the operation. It does not, however, distinguish itself from sibling SE tools like bg3_se_status or bg3_se_command.

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

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

It gives implied usage through the filter examples ('[Apotheosis]', 'error', 'FAILED'), which suggests debugging/diagnostic intent, but it never states when to prefer this tool over the sibling bg3_se_status or bg3_se_live_entry tools.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: it re-runs Bootstrap scripts and is scoped to mods loaded at game start. But it omits the practical consequences of a reset (e.g., loss of runtime Lua state, whether it is disruptive or reversible) that an agent would want before invoking it.

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

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

A single front-loaded sentence that names the operation, its mechanism, and its scope limitation without a wasted word.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and with zero parameters the remaining burden is behavioral. It covers the mechanism and scope well but leaves the action's side effects and its routing relative to sibling reload tools unstated.

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

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

The tool takes zero parameters, so there are no parameter semantics to explain; the baseline for a zero-parameter tool is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Reload Script Extender Lua', clarifying that it 're-runs every loaded mod's Bootstrap scripts from its pak/loose files'. This is more precise than a generic 'reset', though it doesn't explicitly distinguish itself from potentially similar siblings like bg3_se_hot_load or bg3_refresh.

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

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

The console-`reset` framing and the constraint 'Only affects mods that were loaded at game start' imply when this applies, and hint that newer/hot-loaded mods may be outside its scope. However, it never explicitly states when to use this versus alternatives such as bg3_se_hot_load, so usage is left to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses what is inspected (running process, per-run SE log, game state), which signals a read-only diagnostic, but omits any note on side effects, cost, or failure behavior. Adequate but thin for a no-annotation tool.

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

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

A single sentence that front-loads the primary question (is the game running) and then lists the two secondary outputs. No filler, though the list-of-three construction is slightly dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation in the description, and a zero-parameter status tool is inherently simple. The remaining gap is usage context against sibling status/log tools, which keeps it short of a 5.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly does not pad with parameter talk that does not exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names three concrete things the tool answers: whether the game is running, which Script Extender log belongs to the current run, and the latest game state. That is a specific verb-less but resource-specific purpose an agent can act on. It does not, however, distinguish itself from siblings like bg3_se_log or bg3_toolkit_status, which an agent could easily confuse it with.

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

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

The description implies a diagnostic/status-check usage but never states when to reach for this versus bg3_se_log (log retrieval) or bg3_toolkit_status (toolkit status). No exclusions or alternatives are given, leaving the agent to infer the correct routing.

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

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

No annotations are provided, so the description carries the full burden. It says the results come 'with their visual kits', which hints at the return, but says nothing about permission needs, result volume, or how filters combine (AND vs OR) for a 7-param tool.

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

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

A single dense sentence with the resource and filter facets front-loaded and no filler. The keyword-parenthetical for spell types slightly interrupts the flow but earns its place by clarifying an otherwise opaque parameter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return structure needn't be explained. But with 0% param coverage and no annotations, the description should account for all filters; it silently skips 'layers' and 'limit', leaving those two parameters unexplained anywhere.

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

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

Schema coverage is 0%, so the description is doing the documenting: it maps damage type, school, spell type, level and keyword to real parameters and even samples spell_type values (Target, Projectile, Shout, Zone). It omits 'layers' and 'limit' entirely, so the compensation is partial rather than complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (spells) and enumerates the matching facets — damage type, school, spell type, level, name keyword — plus the payoff of attaching visual kits. It reads as a filtered search that differs from bg3_spell_list, but that sibling is never named to make the distinction explicit.

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

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

"to borrow effects and animations for new spells" conveys the intended use case, which is better than nothing. However, it gives no when-not guidance and never names alternatives like bg3_spell_list or bg3_spell_visuals, leaving the agent to infer the boundary.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the 'highest layer wins' resolution behavior, which is useful, but omits whether the operation is read-only, what permissions are required, and any return/pagination behavior beyond what the output schema covers.

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

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

The description is a single efficient sentence with no wasted words, and the core lookup detail is front-loaded. It is appropriately compact, though its brevity contributes to the gaps noted in other dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema, so return values need not be explained, but the description still leaves key context missing. It does not explain the 'layers' parameter or provide usage guidance, which is insufficient for a tool with no annotations and 0% parameter description coverage.

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

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

Schema description coverage is 0%, so the description must compensate. It partially clarifies the required 'key' parameter as accepting UUID or Name, but the optional 'layers' parameter is completely unexplained in both the schema and the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource (spell/passive/skill list) and lookup key (UUID or Name), but it does not use a clear action verb such as 'retrieve' or 'return'. It also does not differentiate this tool from siblings like bg3_spell_visuals or bg3_similar_spells, leaving the agent to infer what makes this list distinct.

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

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

There is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only states what the tool is, not the context in which it should be selected.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state whether this is a read-only lookup, what happens for an unknown spell name, whether layers must pre-exist, or any side effects. Only the conceptual contents of the result are hinted at.

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

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

A single compact sentence that front-loads the resource and lists components efficiently. It is well-sized for the amount of information conveyed, though it omits actionable detail rather than being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. But for a tool with a required name parameter, an undocumented layers parameter, and no annotations, the description leaves too much unspecified for an agent to invoke it confidently.

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

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

Schema description coverage is 0% for both parameters. The description implies 'name' is a spell name, which adds slight meaning, but the optional 'layers' parameter is never mentioned, so the agent gets no guidance on what layers are or how filtering by them behaves.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (a spell's visual/audio kit) and enumerates its components (effects, animations, sounds, icon), which is informative. However, it is a noun phrase with no verb, so the agent cannot tell whether this retrieves, lists, or generates visuals. It also does not distinguish itself from sibling bg3_spell_list or bg3_effect.

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

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

The trailing phrase 'for reusing vanilla VFX' gestures at a use case but gives no explicit when-to-use, when-not-to-use, or alternative. With siblings like bg3_spell_list, bg3_effect, and bg3_search_effects present, an agent has no routing guidance.

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

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

With no annotations, the description carries the full disclosure burden, and it does add two genuinely non-obvious behaviors: layer precedence ('highest layer wins') and that a partial key returns a match list rather than a single record. However, it says nothing about error behavior when a key misses, permissions, or the effect of the optional 'layers' parameter on resolution, which is precisely where an agent would need guidance.

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

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

Dense but front-loaded: the lookup mechanism comes first, followed by the kind taxonomy. The parenthetical annotations (ProgressionTableUUID, MaxValue/ReplenishType) are compact and earn their place. No filler sentences, though the run-on parenthetical style is slightly hard to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value documentation is not required, and the description supplies the domain taxonomy plus layer and partial-match semantics needed to call the tool correctly. The remaining gap is routing: nothing tells the agent how this tool relates to the other 40-odd bg3_* lookups it sits among.

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

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

Schema description coverage is 0%, so the description must compensate, and it does substantially: 'kind' is effectively enumerated with the four accepted domain values, 'key' is documented as accepting UUID or partial Name with list semantics, and 'layers' is indirectly explained by 'highest layer wins'. This is meaningful added meaning over three bare-string parameters, though the 'layers' parameter's own format and defaults are only inferable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (static game data) and its lookup keys (UUID or Name), then enumerates the four domains (ClassDescription, LevelMapSeries, ActionResourceDefinition, Feat) an agent can request. This is far more concrete than a tautology, but it never contrasts itself with the many sibling lookup tools such as bg3_search or bg3_get_entry, so the agent cannot tell from the description alone which one to reach for.

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

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

There is no explicit when-to-use or when-not-to-use statement, and no alternative tool is named despite a crowded sibling list containing bg3_search, bg3_get_entry, bg3_references, and bg3_progression. Usage is only weakly implied by the enumerated kind values.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses only that resolution walks the ParentTemplateId chain; it says nothing about whether this is a pure read, whether unresolvable keys fail or return null, or what happens if the chain is broken.

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

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

A single tight sentence with the verb and mechanism front-loaded and no filler. It is efficient, though arguably terse to the point of omitting needed detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, but with two params at 0% schema coverage, no annotations, and a non-trivial inheritance-resolution behavior, the one-line description is insufficient for an agent to invoke this confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully clarifies that 'key' accepts a MapKey GUID or Name, but the second parameter 'layers' is never mentioned at all, leaving half the interface semantically undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (Resolve), a specific resource (root template), and the mechanism (ParentTemplateId chain), plus the accepted key formats (MapKey GUID or Name). It is clear what the tool does, though it does not differentiate itself from potentially overlapping siblings such as bg3_get_entry or bg3_static.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent must infer its place among ~40 sibling tools entirely on its own.

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

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

With no annotations, the description carries the full burden, and it does disclose the destructive scope: every test spawn, every BG3Test boost, all applied statuses, and that recording stops. It does not state whether the removal is reversible, whether it requires a running session, or what happens to non-test content, so the behavioral picture is partial.

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

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

A single front-loaded sentence with the verb first and the affected entities enumerated. Every clause earns its place and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the zero-parameter schema needs no elaboration. The remaining gap is the absence of any annotation-substitute guidance on safety, timing, or preconditions for a destructive teardown call.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level meaning is missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Remove') with concrete resources: test spawns, boosts tagged BG3Test, applied statuses, plus 'stop recording.' That is far more than a restatement of the name and tells the agent exactly what the tool operates on. It stops short of distinguishing itself from similarly themed siblings such as bg3_se_hot_clean or bg3_se_reset_lua.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative. The agent can infer it belongs in a test teardown flow, but the description never says to call it after tests, before redeploying, or in preference to other cleanup tools.

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

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

No annotations are provided, so the description carries the full burden, yet it only mentions that results are validated against the index. It says nothing about read-only behavior, error handling when a layer has no tests, or what validation failures look like.

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

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

A single front-loaded sentence with no filler. The parenthetical path detail is dense but earns its place by identifying the source of the data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, which lifts this above the floor. Still, three of four parameters and all usage guidance are undocumented, leaving the definition thin for a 4-parameter tool.

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

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

Schema description coverage is 0% across 4 parameters. The description hints at 'layer' via 'mod layer' but leaves 'level', 'layers', and 'class_name' entirely unexplained in both schema and prose, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (test cases a mod layer defines) and its source locations (TOML under <mod>/tests/bg3 or layers.json `tests`), which is more than a tautology. However, it never states the verb explicitly and does not distinguish itself from sibling test tools like bg3_test_plan, bg3_test_verify, or bg3_test_run, so an agent must infer the listing behavior from the name alone.

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

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

There is no statement of when to use this tool, when not to, or how it differs from the many sibling bg3_test_* tools. A reader gets the data source but no routing guidance.

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

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

With no annotations, the description carries the full disclosure burden. It helpfully reveals a side effect — it writes a markdown file to <mod>/docs/test-scripts/plan-<build>.md — and the derivation rule (spells must be learnable by their test level). It does not disclose error behavior, whether it overwrites an existing plan, or what inputs (layer vs layers) affect the result.

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

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

Two dense sentences with the purpose front-loaded and no filler; the parenthetical spelling out the choice types and the output path are both load-bearing. Slightly overpacked but efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. But for a generative, file-writing tool with no annotations and three undocumented parameters, the description leaves key operational questions open — notably the layer/layers distinction and whether prerequisite test staging or an existing plan matters.

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

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

Schema description coverage is 0% for 3 parameters, so the description must compensate and largely does not. It clarifies that 'build' refers to a [[build]] entry in the suite TOML, but 'layer' and 'layers' (including the required-vs-optional relationship and why both exist) are never explained, leaving the most confusing parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the resource precisely — a step-by-step level-up plan for a test build, including subclass/spell/feat choices and the tests that run at each level — which is clearly distinct from sibling tools like bg3_test_script or bg3_progression. However, the verb is implicit ('The step-by-step plan'), so it is ambiguous whether the tool generates, reads, or refreshes the plan; the trailing 'Written to <path>' hints at generation but does not say so outright.

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

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

There is no statement of when to use this tool versus alternatives such as bg3_test_script, bg3_test_list, or bg3_progression, and no prerequisites (e.g., must the build's tests already be staged via bg3_test_stage?). Usage must be inferred entirely from the description of output.

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

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

With no annotations, the description carries the burden and delivers substantial behavioral detail: real combat with host acting first, scripted casting, verification, cleanup, effects sourced from recorded events, and costs checked against the spell's loaded UseCosts without charging them. It still omits permissions, side effects, and output behavior, but the execution semantics are unusually transparent.

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

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

The description is compact and front-loads the main action and pipeline before adding caveats about effects, costs, and player-mode cases. It avoids repetition and wastes little space, though the dense semicolon structure slightly reduces readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a test-runner tool with no annotations, four undocumented parameters, and many siblings, the description covers the high-level process and one important alternative path. It does not explain what layer, layers, or wait mean, leaving a meaningful gap for correct invocation. Output schema exists, so return-value explanation is not required.

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

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

Schema description coverage is 0% across four parameters, so the description must compensate for layer, layers, wait, and case_id. It only obliquely implies case_id by referring to one auto/script case, and says nothing about layer, layers, or wait. Most parameter meaning remains undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: running one auto/script case end to end, with stage, scripted cast, verify, and cleanup. It also distinguishes this from player-mode cases, which need bg3_test_stage plus a hotbar cast instead. However, it does not explicitly contrast with sibling tools like bg3_test_script or bg3_test_run_level.

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

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

It gives clear context for using this tool on auto/script cases and explicitly names an alternative path for player-mode cases: bg3_test_stage plus a hotbar cast. It does not cover when to choose this over bg3_test_script or bg3_test_run_level, so guidance is strong but not exhaustive.

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

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

No annotations, so the description carries full burden. It discloses that cases run one after another (sequential execution), that output is a summary, and that player-mode cases need a hotbar cast, which hints at in-game side effects. It omits execution timing, permissions, rollback/cleanup behavior, and failure handling for a mutation-leaning test runner.

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

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

Two front-loaded sentences with a clear primary action followed by selection qualifiers and a secondary note. No filler, though the second sentence's purpose (a warning/list output) is somewhat loosely attached.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return format need not be explained, but with 6 parameters at 0% coverage and no annotations, the description leaves too much unspecified (layer/layers relationship, wait semantics) for a sequentially-executing test runner. It is not adequate for the tool's complexity.

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

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

Schema coverage is 0% and there are 6 parameters, so the description must compensate. It clarifies `build`, `class_name`, and implies `level`, but leaves `layer` vs `layers`, the `wait` timeout, and their interrelation entirely undocumented. Over half the parameters carry no meaning beyond the bare schema names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: run every automated case for a level sequentially and summarize. It also scopes selection to `build`-assigned cases or a `class_name`'s cases. It does not explicitly contrast itself with the sibling bg3_test_run, so it is clear but not fully sibling-differentiated.

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

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

Gives the condition for which cases are selected (build-assigned via bg3_test_plan, or all of class_name's at that level), and cross-references bg3_test_plan. However it offers no when-not guidance and does not say why an agent should pick this over bg3_test_run or bg3_test_verify.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the key side effect (writes to <mod>/docs/test-scripts/) and that the script is returned, which is meaningful. It says nothing about overwriting existing scripts, required preconditions, or permissions, so the disclosure is partial.

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

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

A single front-loaded sentence that leads with the action and artifact, then the destination. No filler, though the parenthetical makes it slightly dense rather than crisp.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The existence of an output schema excuses explaining the return value, but with 4 undocumented parameters and no annotations, the description is too thin for the complexity. An agent cannot reliably construct a correct call from this text alone.

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

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

Schema description coverage is 0% across 4 parameters, with only 'layer' required. The phrase 'per level and case' hints at the level parameter, but there is no explanation of what 'layer' means, why a separate 'layers' array exists, or what class_name does, so the description fails to compensate for the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (write) and resource (human test script), and even defines the artifact as a step-by-step reading script per level and case, plus the destination path. It does not name or distinguish itself from near siblings such as bg3_test_plan or bg3_test_stage, so it stops short of a 5.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative routing. In a sibling set packed with test tools (bg3_test_plan, bg3_test_stage, bg3_test_run, bg3_test_verify), an agent gets no signal about where this fits in the workflow.

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

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

With no annotations, the description carries the full burden. It does disclose real behavioral traits — that script cases are cast immediately, that initiative is host-first, and that a safety watch and event recorder run. It says nothing about side effects on game state, permission requirements, or failure behavior, so it is only partially transparent for a mutating setup tool.

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

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

Two compact sentences, front-loaded with the core action and the setup checklist. Dense domain jargon but no wasted filler; the trailing pointer to bg3_test_verify earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description sketches the staging workflow adequately. But for a complex mutation tool with three undocumented parameters and an unexplained 'layer'/'layers' distinction, the description leaves an agent unable to call it confidently.

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

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

Schema description coverage is 0% and all three parameters (layer, layers, case_id) are bare titles. The description never explains what 'layer'/'layers' select or how case_id maps to a case, and the only parameter-like reference (mode) is not in the schema at all. It fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Set up one test case in the running game' — and enumerates the setup facets (preconditions, spawns, HP/status, initiative, recorder). It partially routes to a sibling by naming bg3_test_verify as the follow-up, but does not distinguish itself from near-neighbours like bg3_test_run, bg3_test_plan, or bg3_test_script.

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

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

Gives a workflow: stage the case, the user acts, then finish with bg3_test_verify. That is useful sequencing. However, it offers no when-not guidance versus the many other bg3_test_* tools and references mode="script", a concept absent from the input schema, which muddies rather than clarifies usage.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose the key destructive behavior: it removes every spawn, test boost and applied status. That is exactly the side effect an agent must know before calling it. It stops short of stating permission requirements, reversibility, or whether cleanup happens even on failure.

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

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

Everything is packed into a single front-loaded sentence that leads with the core action and ends with the side effect. It is dense but each clause carries real information, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the destructive cleanup is covered. However, for a mutation tool with zero annotations and zero parameter documentation, an agent still lacks guidance on wait/layers semantics and on when this tool should be chosen over its cleanup and run siblings.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters, but it does not. 'Remove every spawn, test boost and applied status' loosely maps to the cleanup flag, while wait and layers are never explained in the description or the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names specific verbs (evaluate, report, remove) and a specific resource (the staged case's expectations, including before/after snapshots and recorded events). It clearly reads as the verification step of a stage→run→verify workflow. It does not, however, explicitly distinguish itself from siblings like bg3_test_cleanup or bg3_test_plan, so it falls just short of a 5.

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

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

Usage is only implied: 'the staged case' signals this runs after bg3_test_stage and produces PASS/FAIL results. There is no explicit when-to-use statement and no named alternative such as bg3_test_cleanup for cleanup-only or bg3_test_run for execution.

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

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

With no annotations, the description carries the full burden. It implies a read-only comparison and explains the success signal ("0 problems = both copies say the same"), which is useful. But it never states explicitly that nothing is modified, nor that a prior export must exist for the comparison to be meaningful, nor any cost/limit behavior for the `limit` parameter.

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

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

Two tight sentences, front-loaded with the comparison target and ending with the interpretation rule. High information density with little waste; the parenthetical path glosses are justified given the 0% schema coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is not required, and the description covers the comparison's meaning well. The gaps are the unexplained required `layer` parameter and the unstated read-only nature of the operation — enough to leave the definition short of complete for a tool an agent must invoke confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It does partially: it explains the two `dest` values with concrete paths ('toolkit': <game>/Data/Editor/Mods/<mod>; 'repo': <mod>/Editor/Mods/<mod>). But `layer` — the sole required parameter — and `limit` are never mentioned, leaving the caller to guess what a layer is and what limiting does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb (compare/check) against a precisely named resource: the mod's Toolkit editor copy vs. an export of its game-ready files, and it spells out the comparison dimensions (missing/extra objects, differing fields per file). It is not tautological. It does not, however, distinguish itself from near-siblings like bg3_diff or bg3_ingame_check, which an agent must infer.

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

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

"Run before publishing" gives a clear trigger context, which is more than most entries provide. However, it names no alternatives and no exclusions — it never says what to use instead when the toolkit copy is missing, or how this relates to bg3_toolkit_export/bg3_ingame_check which plausibly overlap.

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

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

With no annotations, the description carries the full burden well: it discloses that existing editor UUIDs are preserved (non-destructive to them), that the destination can be 'toolkit' or 'repo', and that the operation overwrites open files so the Toolkit must be closed. These are exactly the behavioral traits an agent needs before invoking a write operation.

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

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

Front-loaded with purpose, then semantics, then the critical warning about closing the Toolkit. Dense and information-rich with no filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be detailed, and the description describes what the dry run reports. It is nearly complete but omits any explanation of the required 'layer' argument, which an agent needs to supply.

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

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

Schema description coverage is 0%, so the description must compensate. It explains write (dry run vs actual) and dest ('toolkit' or 'repo'), adding real meaning beyond the bare schema, but the required 'layer' parameter is never described, leaving a key input unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Generate the Toolkit editor copy') and enumerates the output formats (.stats, .tbl) tied to their source content types. It does not explicitly contrast itself with any sibling tool, but the operation is distinctive enough that an agent can identify it.

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

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

Gives clear operating context: write=False is a dry run listing files/object counts/warnings, write=True performs the write, and it warns to close the Toolkit first. It stops short of stating when a dry run is mandatory before writing, and names no alternative tool.

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

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

No annotations are provided, so the description carries the burden. It discloses scope (which directories are inspected) and the kinds of facts returned (link status, file counts, meta.lsx version), which implies a read-only diagnostic. However, it never states that it is non-mutating or whether it has any side effects.

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

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

A single dense sentence that front-loads the tool's scope and enumerates its outputs, with no filler. The parenthetical placement is slightly awkward but does not impede comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The presence of an output schema means return values need not be explained, and the description does outline what is reported. The gaps are the completely undocumented required 'layer' parameter and the absence of any guidance distinguishing this from bg3_toolkit_check/bg3_toolkit_export.

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

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

Schema description coverage is 0% and the single required parameter 'layer' is never named or explained. The parenthetical directory list (Data/Projects, Mods, Public, Editor/Mods) may allude to possible layer values, but the description does not connect it to the parameter or define accepted values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool reports: presence/missing status of the mod in the expected Larian Toolkit directories, whether it is linked to the repo or a separate copy, file counts, and the meta.lsx version. It reads as a specific status/inspection tool, though it does not explicitly differentiate itself from the close sibling bg3_toolkit_check.

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

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

There is no guidance on when to use this tool versus alternatives. The sibling set contains bg3_toolkit_check, bg3_toolkit_export, and bg3_deploy, which plausibly overlap, yet the description offers no selection criteria, preconditions, or exclusions.

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