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

The annotations already declare that this is a non-read-only, non-destructive, closed-world mutation. The description adds that the created group is empty but contains Low and High nodes, which is useful behavioral context beyond the annotations. It does not describe side effects, failure cases, or whether an existing bake project 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?

The definition is a single well-formed sentence that front-loads the action and resource. Every phrase contributes information, with no repetition or 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 annotations cover the basic safety profile. However, for a tool with two parameters at 0% schema coverage, the complete absence of parameter semantics leaves an agent unable to reliably populate the required name and optional baker fields.

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 explain the two parameters, but it says nothing about the required 'name' or the optional 'baker' parameter. The ambiguous anyOf type for 'baker' (integer, string, or null) is left completely unexplained, and 'to a bake project' does not clarify which parameter identifies the project.

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 and resource: 'Add an empty bake group.' It also clarifies that the group comes with Low and High nodes and belongs to a bake project, which distinguishes it from generic object creation. It does not explicitly differentiate itself from close siblings such as baker_create, but the purpose is clear.

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 about when to use this tool versus baker_create or other baker tools. The phrase 'to a bake project' implies context, but it does not state prerequisites, alternatives, or when-not-to-use conditions.

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?

Annotations declare readOnlyHint=false and destructiveHint=false, and the description usefully adds the synchronous/blocking trait ('can take minutes'), which is critical operational context an agent cannot get from structured fields. It also discloses where files land. It stops short of saying whether existing files at that path are overwritten or what the output schema 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?

Two short sentences, zero filler, with the output-path convention and the timing caveat both front-loaded. Nothing to trim.

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 means return values need not be described, and the timing behavior is covered. However, a 1-param tool with 0% schema coverage needs the description to carry the 'baker' argument and the outputPath/parameter mismatch, and it does not.

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% for the single 'baker' parameter, and the description never explains it, so an agent cannot tell whether it selects a baker by name/index or defaults to the active one. Worse, it references 'outputPath' as though it were a parameter, but no such parameter exists in the schema, which will mislead an agent trying to control the destination.

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 ('Bake') and resource with concrete output behavior: writes enabled maps next to outputPath using the '<stem>_<suffix>.<ext>' naming convention. This is clear on its own, but it never distinguishes itself from close siblings like baker_bake_to or baker_bake_psd.

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 phrase 'with the project's current settings' implies you should configure baker_set_settings/baker_set_maps first, but that is inference rather than guidance. There is no explicit statement of when to pick this over baker_bake_to, baker_bake_psd, or baker_isolate/baker_set_visible setup steps.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false. The description adds that only *enabled* maps are baked and that output is a single layered file, but it does not say whether an existing file at that path is overwritten, where the output path is configured, or whether baking is long-running.

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. It is efficiently sized, though its brevity is partly under-specification rather than disciplined economy.

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, but for a file-writing bake operation the description leaves critical context unstated: how the output path is supplied, where the 'baker' argument fits, and what happens on overwrite.

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 sole parameter 'baker' is undocumented and unexplained. The description instead mentions 'the output path', which is not a parameter of this tool at all, creating a mismatch between described inputs and actual 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 outcome: bakes all enabled maps into a single layered PSD. It distinguishes itself implicitly from baker_bake and baker_bake_to by the layered-PSD output, but never names those siblings, leaving the agent to infer the distinction.

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 guidance on when to call this versus baker_bake, baker_bake_to, or baker_bake_psd's prerequisites (baker config, enabled maps, output path source). The agent must guess its place in a large baker family.

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?

Annotations already declare readOnlyHint=false with destructiveHint=false, and the description meaningfully supports that: it explains the project's settings and map switches are restored afterwards and that `settings` are temporary extras, which is exactly the non-destructive context an agent needs. It doesn't clarify what happens to the pre-existing target file on disk (overwrite?) or whether the output is registered into the project, which are the remaining behavioral gaps.

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, front-loaded with the action and its output naming behavior, then the restoration guarantee, then the parameter nuance. The path example does real work rather than padding.

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 description is adequate for a 7-parameter bake tool with only one required argument. The main shortfall is the undefined `baker` selector and no statement of failure modes (e.g. invalid path, unknown map name) before a potentially slow bake runs.

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 carries the burden and largely does: it documents `path` (with a worked example), `maps` with its default ['normals'], the size and `samples` intent, and `settings` with an inline example of {'smoothCage': false}. Only `baker` (integer-or-string selector) and the width/height split are left undiscussed.

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: a 'trial bake of selected maps ... into a separate file', with a concrete path-transformation example ('C:/tmp/test.png' → 'C:/tmp/test_normals.png'). It is clear what the tool does, but it never names its nearest sibling (baker_bake) to explain why a caller would pick this over a normal bake, so sibling differentiation is left 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 word 'Trial' and the restoration guarantee imply this is a safe, non-committal way to preview baking before the real baker_bake, but that comparison is never stated explicitly. There are no exclusions, prerequisites, or named alternatives, so an agent must infer usage from the word 'trial'.

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?

Annotations already declare that this is a non-read-only, non-destructive, closed-world operation, so the safety profile is covered. The description adds no behavioral context beyond the bare action: it does not say whether an existing scene is required, what defaults are applied, or what gets created.

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 wasted words. Its brevity is efficient, though it leans toward under-specification rather than informative conciseness.

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 details need not be described. However, for a creation tool surrounded by many baker_* siblings, the description omits prerequisites, the effect of the optional name parameter, and how the new project relates to baker_list/baker_get.

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 schema has 0% description coverage for the single optional "name" parameter, whose default is null. The description does not explain what the name represents, whether it is optional, or what happens when it is omitted, so it fails to compensate 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 states a specific verb and resource: "Create a new bake project." An agent can tell this creates a baker project rather than performing the many bake-related actions in the sibling list. It does not, however, distinguish itself from related lifecycle tools like baker_quick_load or scene_new.

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 instead of alternatives such as baker_quick_load, baker_get, or baker_list. No prerequisites or exclusions are stated.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety behavior is covered. The description adds useful content scope by listing what the full project includes, but does not disclose error behavior or how the baker parameter resolves.

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. It is dense with returned-content terms, but every item is relevant to what 'full' means.

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 read-only annotations and an output schema present, the description need not fully document return values. However, it leaves important gaps around how to identify the baker and what the maps flag controls, so it is only adequately 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 description coverage is 0%, so the description should clarify both parameters. It mentions 'maps with options' as part of the returned project, which weakly hints at the maps flag, but never explains the baker parameter or whether maps=false excludes maps from the response.

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: one bake project retrieved in full, and enumerates the major contents returned (groups, settings, maps, texture sets, UDIM tiles, output files). It implicitly contrasts with baker_list by specifying 'One bake project,' but does not explicitly name sibling 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?

There is no explicit guidance on when to use this tool instead of baker_list or other baker_* tools. The phrase 'One bake project in full' weakly implies detail retrieval, but no conditions, prerequisites, or alternatives are stated.

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?

Annotations only declare readOnlyHint=false, openWorldHint=false and destructiveHint=false, so the description's 'hide all others' adds genuinely useful context: non-listed groups have their visibility changed as a side effect. It still omits whether the hiding is persistent, whether it can be undone, and how the 'baker' target interacts with the group list.

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 zero filler, stating the effect immediately. It is efficient, though the brevity comes at the cost of the missing detail noted elsewhere rather than through deliberate tightening.

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 two undocumented parameters, no crafted output schema explanation needed but no explanation of what is returned either, and a mutation side effect on unlisted groups, the description is too thin. An agent can guess the intent but cannot confidently supply 'baker' or choose between a string and an array for 'groups'.

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 carry the burden of explaining both parameters and does not. It never mentions 'baker' (an integer/string identifier of unclear meaning), nor clarifies that 'groups' accepts either a single string or an array of strings, which is the main ambiguity an agent would hit.

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 on a specific resource: show the listed bake groups and hide every other one, which is exactly what 'isolate' means. It is clear enough to distinguish from a plain visibility toggle, though it never names the adjacent tools (baker_set_visible, baker_set_settings) or explains what a 'bake group' is.

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 choose isolate over baker_set_visible or baker_set_settings, and no prerequisites or caveats are given. The usage is only inferable from the effect statement, and nothing tells the agent what state it must be in beforehand.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds that returned items include groups and output path, but it does not disclose ordering, pagination, or other behavioral traits beyond the annotations and output schema.

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 wasted words. It is perhaps overly terse, but it efficiently conveys the resource and included fields.

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?

Given zero parameters, an output schema, and rich annotations, the description supplies the essential context: it lists all bake projects and mentions groups and output path. It does not need to explain return values because the output schema covers them.

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 has zero parameters, so there is nothing for the description to clarify. Per the rubric, zero parameters establishes a baseline of 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?

The description clearly identifies the resource (bake projects) and scope (all), with additional detail on what is included (groups and output path). It does not explicitly use a verb like 'list', but the meaning is unambiguous and distinguishes it from baker_get, which presumably retrieves one project.

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 such as baker_get, baker_create, or the other baker_* tools. The word 'All' implies enumeration, but no conditions, exclusions, or alternatives are stated.

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?

Annotations already state readOnlyHint=false, destructiveHint=false and openWorldHint=false, so safety is partly covered, but the description does not say that loading a preset overwrites the target baker's current settings or what happens on an unknown name. For a state-mutating call, that behavioral context is missing.

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 short sentence with the action and selector front-loaded. It is efficient, though its brevity comes at the cost of the missing details above rather than being maximally informative.

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 for a mutation tool with 0% parameter documentation and no annotation detail about side effects, the description leaves the agent guessing about the 'baker' argument and what state changes occur.

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 description only clarifies that 'name' identifies the preset. The 'baker' parameter (which baker the preset is applied to) is undocumented in both schema and description, leaving a real ambiguity for an optional parameter.

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?

Names a specific verb and resource ('Load a saved baker preset'), which is enough to distinguish it from baker_save_preset and baker_bake. It does not explicitly contrast with baker_quick_load, whose name implies a similar loading action, so sibling differentiation is only 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?

There is no guidance on when to use this instead of baker_quick_load or baker_list/baker_get, and no prerequisites stated (e.g., whether a preset must exist or whether baker_list should be called first). The agent must infer usage from the name alone.

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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds that the lookup is keyed on display name and can be scoped by texture set or UDIM tile, but does not say whether the returned path exists on disk, whether it requires an existing bake, or whether it is absolute.

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 identifies the tool's function before the optional scoping details. The parenthetical example list is dense but earns its place by illustrating valid map names.

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, the return value needn't be described, and read-only annotations cover safety. However, for a 3-parameter tool at 0% schema coverage, the description leaves the 'baker' selector and a mismatched 'texture set' concept unresolved, so it is not fully self-sufficient.

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 carry the params. It explains map_name well with concrete examples and gestures at the UDIM tile ('1001'), but 'texture set name' does not correspond to any parameter in the schema, and the 'baker' parameter is never mentioned at all — leaving the agent guessing which baker instance is targeted.

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 and output: the Toolbag-internal output path for a given map display name, with example values ('Normals', 'Ambient Occlusion', 'Height'). An agent can distinguish this from baker_get/baker_list, though the verb ('returns/computes') is only implied by 'output path'.

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 phrase 'Toolbag's own output path' implies this should be used instead of hand-constructing a path, which is useful implied guidance. But there is no explicit when-to-use, no prerequisite (e.g. must the baker be configured or baked first), and no mention of any 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?

Annotations already declare readOnlyHint=false / destructiveHint=false, and the description adds genuine non-obvious behavior: an unmatched stem produces a group missing a High entry and an empty bake. That is exactly the kind of failure mode an agent needs to know, and 'check the returned groups' tells it how to detect it. It does not mention what happens to pre-existing objects or whether the operation is reversible.

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, zero filler, with the pairing rule front-loaded ahead of the failure caveat. Every clause carries information.

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 explaining return values is not required, and the annotations cover the safety profile. But for a two-parameter tool with 0% schema coverage, the description leaves the agent guessing what 'path' points at and what 'baker' selects — a meaningful gap before it can actually call the 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%, so the description must carry the parameter burden and it does not: 'path' is never explained (model file? directory of low/high pairs?) and 'baker' (integer|string|null) is never mentioned at all. Two undocumented parameters with no compensating prose.

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 (load), resource (a model), and the mechanism (Quick Loader with <stem>_low / <stem>_high pairing into one group per stem). That is more informative than the name alone, though it does not explicitly distinguish itself from the similar scene_import_model sibling.

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 naming convention acts as a clear precondition for correct use, and the description tells the agent to verify the returned groups afterward. It stops short of naming an alternative (e.g. scene_import_model) or saying when not to use Quick Loader.

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 annotations already declaring readOnlyHint=false and destructiveHint=false, the description adds real context: the operation is a wholesale geometry swap that brings new UVs and fixed topology while preserving group, cage and material, and it warns that stored cage directions may be unreliable afterward. It stops short of describing failure modes (e.g. group with zero or multiple low meshes) or undo behavior.

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, zero filler, with the core operation front-loaded and the caution about cage directions placed after it. Nothing repeats structured 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 explained, but for a mutation tool the description omits the meaning of the 'baker' parameter and the constraints implied by 'single low mesh' (what happens if the group has none or several). Adequate, not 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 description coverage is 0%, so the description carries the burden. It gives meaning to 'group' (the group whose single low mesh is replaced) and 'path' (a model file containing the replacement mesh), but the third parameter 'baker' is never mentioned anywhere, leaving it completely ambiguous.

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 precise verb and resource: swap the low mesh of a group with a mesh from a model file, preserving group, cage and material. That is specific enough to separate it from siblings like scene_import_model or baker_quick_load, though it does not explicitly name a competing tool.

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 by the framing (replace geometry without losing group/cage/material setup) and there is a helpful precondition ('save the scene first if you rely on stored cage directions'). However, it never states when to prefer this over alternatives such as re-importing the model or baker_quick_load, nor what preconditions the group must satisfy.

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?

Annotations already declare that this is a non-read-only, non-destructive, closed-world mutation. The description adds that it saves the bake project's configuration as a named preset, but omits important behavior such as whether an existing preset with the same name is overwritten.

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. It is appropriately sized for a simple 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 and annotations reduce what the description must cover. However, for a mutation tool with a completely undocumented 'baker' parameter and no overwrite semantics, the description leaves meaningful gaps.

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 needs to carry parameter meaning. It signals that 'name' is the preset name, but the second parameter 'baker' (integer/string/null) is completely unexplained, leaving ambiguity about whether it selects a baker or specifies a bake context.

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?

It uses a specific verb-resource pair: save the bake project's configuration as a named preset. The operation is clear, though it does not explicitly distinguish itself from baker_load_preset or baker_set_settings.

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 versus baker_load_preset, baker_set_settings, or baker_create. The name implies saving a preset, but the description provides no conditional context or exclusions.

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?

Annotations already declare this is a non-read-only, non-destructive, closed-world mutation. The description adds the useful behavioral rule that `estimate` lets Toolbag compute first and that explicit min/max override it, but says nothing about persistence, undo, or what happens to groups not named.

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 short sentences, front-loaded with the resource and scope, with no filler. It is compact rather than padded, though the terse phrasing is borderline cryptic.

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 7-parameter mutation tool with zero schema descriptions, the definition leaves most parameters and the mutation's effect underspecified. The presence of an output schema excuses it from explaining return values, but not from covering parameter meaning.

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% across 7 parameters, so the description must carry the burden. It explains only `groups` (omitted means all) and the estimate/min_offset/max_offset interplay; `baker`, `cage_alpha`, and `exclude_when_ignoring_groups` are entirely undocumented anywhere.

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 (cage offsets per bake group) and the operating scope, but the verb is implicit and the tool's relationship to sibling setters like baker_set_settings or baker_set_maps is never stated. An agent can infer it configures bake cage offsets, but not precisely what state it changes.

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?

Only guidance given is '(all groups when omitted)', which is scope, not when-to-use. No indication of when to prefer estimate versus explicit min/max, no prerequisites, and no mention of alternatives such as baker_set_settings.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds that the call returns the enabled maps and that maps are addressed by suffix, but does not say what disabling does to existing per-map options, whether options for disabled maps are retained, or what happens if the target baker is omitted.

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 front-loads the action, followed by the suffix list and a compact literal example that resolves the otherwise opaque options object. Dense but every element earns its place, and the return-value note sits at the end where it belongs.

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 covers the return value, and the annotations cover safety, so the remaining gap is behavioral: default baker selection, list-vs-single suffix handling, and the fate of options on disabled maps are all unstated for a 4-parameter mutation tool with zero schema documentation.

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 carry the burden, and it partially does: the 'suffix' vocabulary explains what values enable/disable accept and the JSON example documents the shape of the free-form 'options' object. However it never mentions the 'baker' selector parameter or that enable/disable are lists, leaving half the parameters undocumented anywhere.

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?

Names a specific verb pair ('switch maps on or off') and resource ('maps'), plus a secondary capability ('set map options'), with a concrete suffix vocabulary ('normals', 'ao', 'height', etc.). It is clearly distinct from setters like baker_set_visible or baker_set_settings, though it never explicitly contrasts itself with them.

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 by the operation (call to toggle maps and configure their options) but there is no explicit when-to-use/when-not guidance and no pointer to the sibling tools that handle adjacent concerns (baker_set_settings, baker_set_texture_set, baker_map_path). An agent must infer the boundary from the name.

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?

Annotations already declare a non-read-only, non-destructive, closed-world write operation. The description adds scope by listing the exact settings affected and their allowed enum values, but it does not explain whether settings are merged or replaced, whether omitted settings are preserved, or how the change affects subsequent bakes.

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 dense sentence that front-loads the purpose before enumerating settings. It contains little waste, though the long comma-separated list is less scannable than it could be.

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?

Given the complex, free-form nested `settings` object and 0% schema description coverage, the enumeration of settings keys is helpful. Still, the description omits the `baker` parameter and does not clarify partial-update versus replacement semantics, leaving meaningful ambiguity for an agent invoking the 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%, so the description must carry parameter meaning. It does a reasonable job enumerating many keys inside the free-form `settings` object and clarifying enum values for outputBits, edgePadding, tileMode, and geometryMode. However, it never mentions the `baker` parameter, leaving one of the two top-level 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 clearly states a specific verb and resource: 'Set bake project settings.' It also enumerates many of the configurable fields, making the tool's scope concrete. However, it does not distinguish this tool from nearby siblings such as baker_set_maps, baker_set_cage, or baker_save_preset.

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 explicit guidance on when to use this tool versus alternatives, nor does it state prerequisites or ordering relative to baking. Usage is only implied by the tool name and the list of settings.

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?

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, giving the agent a safety profile. The description adds the useful constraint that it operates on exactly one texture set, but does not disclose side effects on already-enabled sets or what the response contains.

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 front-loaded sentence with no filler. The parenthetical adds ambiguity rather than clarity, which keeps it from a 5.

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?

A mutation tool with 5 parameters at 0% schema coverage and no output description in the text; the 'baker' target and the meaning of tileMode remain unexplained. An output schema exists, but the input-side gaps are substantial for a state-changing 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%, so the description must compensate. It hints that index accepts either a numeric index or a name, and that width/height control sizing while enabled toggles state, which maps to several params. However, the 'baker' parameter is never explained and 'tileMode 1' is unexplained jargon.

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: 'Enable and size one texture set'. Distinguishes it from siblings like baker_set_maps or baker_set_settings. The '(tileMode 1)' parenthetical is opaque, but the core action is legible.

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 guidance on when to use this versus baker_set_maps or baker_set_settings, no prerequisites, and no mention of what happens if the referenced texture set does not exist. The agent must infer usage from the name alone.

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?

Annotations declare this is a non-read-only, non-destructive, closed-world mutation, so safety context is already provided. The description adds that it targets one tile by index/name and references tileMode 2, but it does not describe side effects, permissions, or what happens to tile state when enabled/sized.

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 front-loaded sentence with no wasted text. The essential action and identifier syntax are packed efficiently into one line.

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 and annotations exist, so return format and safety context are partly covered elsewhere. However, for a 5-parameter baker mutation tool, the description omits the baker parameter, optional-field semantics, and when this should be used instead of other baker configuration tools.

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 carry the explainer burden. It usefully clarifies that index can be a name like '1001', that width/height are sizing inputs, and that enabled controls tile activation, but it leaves the baker parameter unmentioned and does not document optional/null behavior.

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 action and resource: enabling and sizing one UDIM tile, with index/name as the identifier. It is clear what the tool does, though it does not explicitly differentiate itself from nearby baker_set_* tools such as baker_set_texture_set.

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 a syntax example ('1001') and notes tileMode 2, but does not explain when to use this tool versus related baker tools. There are no prerequisites, exclusions, or alternative-selection 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?

Annotations already declare readOnlyHint=false with destructiveHint=false, and "safe way to toggle" is consistent with that profile rather than contradicting it. The description adds that Low and High nodes can be targeted separately, but says nothing about what happens when visible is omitted or how low/high interact with 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?

Two short sentences, front-loaded with the action and scope. The second sentence is slightly promotional but still carries the safety signal, so nothing 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 not be described, but for a five-parameter mutation tool with zero schema coverage the description is too thin. An agent cannot tell from the text alone which parameters are required, what null means, or how the node-level flags combine.

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 five parameters, so the description must carry the load. It loosely maps to groups, low, and high, but leaves visible and baker completely undefined and does not explain the precedence between visible and the low/high booleans.

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 (show/hide) and resource (bake groups, plus their Low and High nodes), which is more precise than the name alone. It does not name the sibling it overlaps with, object_set_visible, so the distinction from scene-object visibility is left 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 safe way to toggle meshes in a bake scene" hints at when this is preferred over the generic object_set_visible, but never states the condition or names the alternative. There are no explicit exclusions or prerequisites.

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?

Goes well beyond the annotations: explains the workaround (Python API can't set skew masks, so the scene is saved to a new file, masks written there, Toolbag loads it), that `path` is never overwritten, the default `<scene>_skew.tbscene` naming, and that the original scene file stays untouched. These are exactly the side effects and prerequisites an agent needs before invoking a mutating tool, and they are consistent with destructiveHint=false.

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-loads purpose in the first clause and keeps the file-lifecycle explanation tight at four sentences. The workaround detail is long but load-bearing for correct invocation; only mild redundancy between 'saved as a new file' and 'original scene file stays untouched'.

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 values needn't be described, and the description covers the side effects, file naming, and prerequisite that matter for this mutation. The gap is the eight undocumented tuning parameters, which are only reachable via a cross-reference to another tool's definition.

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 9 parameters, so the description must compensate. It fully explains `path` (what it is, default, never overwritten) and delegates the remaining edge-rule parameters to baker_skew_preview, but bend_px, hard_px, seam_px, soft_px, bend_deg, mask_size, baker and groups get no meaning, units, or ranges anywhere.

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: write skew masks by edge rule into the bake groups. It also names the sibling it complements (baker_skew_preview, same parameters), so an agent can distinguish apply-from-preview without opening either 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?

The parenthetical pointer to baker_skew_preview with 'same parameters' routes the agent to the preview counterpart for inspection, and the default-path note states the prerequisite that the current scene must have been saved once. It stops short of an explicit 'use preview first, then apply' instruction or any when-not 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?

Annotations declare readOnlyHint=false and destructiveHint=false, so the description only needs to explain the state change. It does say the low materials regain their albedo map and colour, which is genuinely useful side-effect information, but it doesn't clarify whether the skew mask is discarded or merely hidden, nor whether any other preview state is reset.

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 effect second; nothing is wasted and nothing is buried.

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 no parameters and an output schema present, little is required, but the description doesn't tie the call to its preview counterpart (baker_skew_preview) or mention whether it must follow a preview. The pairing context would make correct sequencing obvious.

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 to disambiguate and the baseline of 4 applies. The description correctly implies no arguments 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?

States a specific verb and resource ('End the skew mask preview') and immediately names the effect on low materials' albedo and colour. It is distinguishable from siblings baker_skew_preview and baker_skew_apply, though the distinction is implicit rather than spelled out.

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 word 'End' implies this is the teardown counterpart to a preview, but it never states when to call it (e.g. after baker_skew_preview) or how it differs from baker_skew_apply. Usage is inferable but not directed.

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?

Goes beyond the annotations (readOnlyHint=false, destructiveHint=false) by clarifying that 'nothing is written into the scene' even though low materials are visibly repainted, and by naming the restoration tool. It stops short of saying whether the preview persists across scene operations or how mask_size affects cost, so not a full 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?

Front-loaded with the operation and its visual result, then the rule details, then the workflow. Dense but each clause carries information; the parenthetical 'black = averaged cage, white = corrected' is the only line whose payoff for tool selection is unclear.

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 an 8-parameter, zero-coverage tool with an output schema, the description covers behavior, side effects, and the surrounding workflow well enough to call it correctly. The gap is the unexplained baker/groups scoping parameters — an agent cannot tell from this text which bakers or groups the preview applies to.

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?

With 0% schema description coverage, the description carries the burden and mostly does: it defines seam_px/hard_px/bend_px as band widths in bake pixels, explains that 0 disables a band, gives bend_deg its threshold meaning, and describes soft_px as a falloff. It leaves baker, groups, and mask_size completely unexplained, which holds it below 5.

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?

Names a specific operation (compute skew masks by edge rule) and its visible effect (base colour on the low materials), so the agent knows exactly what happens. It also distinguishes itself from the two closest siblings by naming baker_skew_apply and baker_skew_clear_preview as the follow-up and undo paths.

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?

States the workflow explicitly: 'check the look, adjust, then baker_skew_apply', and gives the exit path via baker_skew_clear_preview. The condition selecting this tool over the apply variant (non-destructive preview) is spelled out rather than implied.

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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds one genuinely useful behavioral fact beyond them — that activate makes the camera both viewport and render camera, i.e. it changes global application state — but says nothing about defaults applied when position/rotation are omitted or how the new camera relates to existing ones.

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 action and appends the only notable side effect; nothing is redundant or padded.

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 five-parameter create tool with zero schema descriptions, the entry point and main side effect are covered, though the name parameter and array/attribute shapes remain undocumented.

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 cover four of five parameters loosely (transform = position/rotation, attributes, activate) but never mentions name and gives no format detail for the position/rotation arrays or the accepted keys in attributes.

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 and resource ("Create a camera") and names the optional payload (transform and attributes), so an agent knows exactly what the tool produces. It does not explicitly distinguish itself from camera_set, camera_set_active, or camera_get, but the create semantics are unambiguous.

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 from the verb: create a new camera. There is no statement of when to use this versus camera_set_active or camera_set, and no note that activate also switches the viewport/render camera, which is the main decision an agent faces when calling 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the agent knows this is a non-destructive mutation within the scene. The description adds that the operation targets 'the current camera', which is real behavioral context, but says nothing about whether it moves the camera transform, whether it persists or is view-only, or what happens if no camera is active.

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 sentence, front-loaded with the primary action, and the conditional detail about `ref` is folded in without padding. Nothing to cut.

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 single-optional-parameter tool with an output schema and safety annotations in place, the description covers the essential behavior. The only meaningful gap is the type ambiguity of `ref` and whether the framing result is transient or persisted.

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 carry the parameter meaning, and it does explain the key semantic: presence of `ref` frames one object, absence frames the scene. However, it does not clarify the anyOf(integer | string) union — whether an integer is an object ID or index and a string is a name — leaving a real ambiguity the schema cannot resolve.

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 ('Frame') and its two targeting modes (one object, or the whole scene), scoped to 'the current camera'. That is enough to separate it from siblings like camera_set, camera_set_active, and camera_get, though the differentiation is implied by the word 'frame' rather than stated 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?

It gives one concrete usage rule — omit `ref` to frame the whole scene instead of a single object — which is genuinely useful routing information. It never says when to prefer this over camera_set or camera_get, and doesn't mention prerequisites such as needing an active camera.

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?

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds something annotations do not: that omitting the ref falls back to the active camera, which resolves the schema's bare 'default: null'. It stops short of describing failure modes (e.g., no camera exists) but the output schema carries the return shape.

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 with the resource and default scope front-loaded, then a compact field list. The parenthetical enumerations are dense but every item earns its place by telling the agent what data it will receive.

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 read-only getter with an output schema, the description is mostly complete: it says what comes back and what happens with no argument. The remaining gap is ref format semantics, which is exactly what an agent needs to call it with a non-default camera.

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 the single 'ref' parameter, which accepts integer, string, or null with no documentation. The description explains only the null case ('active one by default') and leaves the agent guessing whether an integer is an index and a string is a name or UUID — the most consequential ambiguity in the whole definition.

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 and scope: a single camera retrieved 'in full', followed by an enumeration of exactly which property groups come back (transform, lens, postEffect, etc.). This implicitly separates it from the sibling camera_list (many cameras) and camera_set (mutation), though no sibling is named 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?

The parenthetical 'the active one by default' tells the agent how to call it with no argument, which is genuine usage guidance. But it never states when to prefer this over camera_list or camera_set, nor what happens if there is no active camera.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered structurally. The description adds the returned field set (mode, FOV, focal length, active flag), which is modest extra value, though an output schema exists and may already document 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?

A single front-loaded clause with no filler. It is a sentence fragment without an explicit verb, which is terse but not confusing.

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 zero-param read tool with full annotation coverage and an output schema, the description supplies enough to call it correctly and interpret the result. Nothing critical is missing, though noting that camera_get retrieves a single camera would complete the picture.

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 there is nothing for the description to disambiguate; the baseline for a no-arg tool applies. It correctly implies no filtering or paging arguments.

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?

Names the resource and the exact scope (all cameras) plus the attributes surfaced, so an agent knows it is an enumeration rather than a single-item fetch. It never names camera_get, but 'All cameras' does the disambiguating work implicitly.

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 word 'All' — an agent can infer this is the listing counterpart to camera_get, but the description never states when to prefer one over the other or any prerequisite.

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?

Annotations already declare non-read-only, non-destructive, closed-world behavior, so the safety bar is lower. The description contributes the mode-switch semantic (same tool mutates in one branch, reads in the other), but says nothing about whether loading overwrites the current effect stack, what file format/encoding path expects, or what errors surface.

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 operation first and the mode flag second; nothing is wasted. The compactness is borderline under-specified rather than bloated, but structurally sound.

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 two modes are covered. Missing pieces are material for a file I/O tool: the meaning of 'ref', whether the current preset is replaced on load, and the expected path format — enough gaps to rate only minimum-viable.

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 carries the full burden: it explains only 'save' and implies 'path' ('from a file'). The 'ref' parameter — an anyOf integer/string/null, presumably the camera selector — is never mentioned, so an agent has no idea how to target a specific camera versus the active one.

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?

Names a specific resource (camera post effect preset) and two concrete operations (load from file / save current), so an agent can tell it apart from camera_set or sky_load/sky_save. It stops short of any explicit sibling differentiation, but the verb+resource pair is unambiguous.

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 parenthetical '(save=true)' gives the one branch condition needed to pick load vs save, which is real guidance. There is no statement about prerequisites, what happens when the file does not exist, or when to prefer this over camera_set / another preset mechanism.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the description only needs to add context beyond that. It usefully notes the default target (active camera) and implies nested/json-or-object attribute payloads, but leaves open whether omitted fields are preserved or reset — a key question for a non-destructive mutation 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?

The key action and default target are front-loaded, and the attribute list plus inline JSON examples add signal without padding. The raw JSON snippets make the sentence less clean to read than prose, but every element is informative, so structure is only slightly penalized.

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. However, for a nested free-form mutation tool with 0% schema coverage, key gaps remain: ref is undocumented, the full set of settable attributes is only partially enumerated (mode and limits are vague or truncated), and merge-vs-replace semantics for omitted fields are unstated. Adequate but not sufficient 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?

Schema description coverage is 0%, and the attributes object is free-form with additionalProperties=true, so the description carries the main burden of documenting shape. It does this well for the attributes parameter by naming concrete keys (fov, focalLength, mode) and showing exact nested JSON for lens, postEffect, and limits. It earns a 4 but not a 5 because the ref parameter is never 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?

The first clause "Set camera attributes (the active camera by default)" names a specific verb and resource and states the default target, so an agent knows it mutates a camera rather than reading it (camera_get) or managing cameras (camera_list, camera_create, camera_set_active). It does not explicitly note when to prefer a sibling such as camera_set_active, keeping it 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 parenthetical "the active camera by default" implies you may target a specific camera via ref, but there is no explicit when-to-use versus camera_set_active, camera_frame, or object_set_transform. Usage is implied rather than spelled out, and no exclusions or prerequisites 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing that the call changes two separate pieces of state (viewport and render camera), which an agent would otherwise not know. It does not say whether the change persists in the scene file, whether it is undoable, or whether the render-camera change is global across scenes.

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 tidy sentence with the outcome front-loaded and no filler. Nothing in it 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 not be explained, and annotations cover the safety profile. However, for a one-parameter mutation tool with zero schema description coverage, the omitted semantics of 'ref' and the lack of any persistence/undo note leave the definition only narrowly sufficient.

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 sole parameter 'ref' accepts either an integer or a string, yet the description only says 'a camera' without indicating whether that means an index, a name, or a path. This is the one thing an agent most needs and it is absent from 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?

States a specific verb ('Make ... active') and the two concrete effects: viewport camera and render camera. It is unambiguous what the tool does, but it offers no differentiation from nearby siblings such as camera_set or render_set_cameras, which an agent must choose between.

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 versus camera_set, camera_frame, or render_set_cameras, nor on prerequisites (does the camera need to exist first?). At best the usage is implied by the outcome it describes.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds one genuine behavioral fact — the contents vary by Toolbag version — but says nothing about size, structure, or how to consume the result (though an output schema exists, so return shape is documented elsewhere).

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 with no filler; the enumeration scope comes first and the purpose clause second. Slightly awkward phrasing ('Everything the running Toolbag exposes in `mset` plus...') but nothing 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?

With no inputs, an output schema documenting return values, and annotations covering safety, the description only needs to convey scope and purpose — which it does. The one gap is leaving `mset` unexplained for an agent that may not know the domain.

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, and the schema is an empty object; there is nothing for the description to explain. Baseline 4 applies.

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 a specific resource: everything the running Toolbag exposes in `mset` plus the plugin's action list, i.e. a capability/introspection enumeration. It is clear enough to distinguish from action siblings like scene_info or preferences_get, though the term `mset` is undefined jargon and there is no verb to pin the operation down.

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 clause 'for version differences between Toolbag builds' implies the intended use case — checking what a given Toolbag build supports before calling other tools. It never states explicitly when to call this versus status, nor any exclusion or prerequisite, leaving the agent to infer 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?

Beyond annotations, it discloses that the namespace persists between calls, that assigning `result` returns a value, and that `print()` output is returned as `log`. These are meaningful execution semantics not captured by the structured fields.

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-loaded with the core action. Every clause adds useful information about permissions, state persistence, or return behavior.

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 an arbitrary code execution tool with annotations covering destructiveness and an output schema covering return values, the description is largely complete. The main gap is the unexplained `timeout` 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?

It explains the required `code` parameter well by describing the Python environment and return conventions. With 0% schema description coverage, however, it omits any explanation of the `timeout` parameter and its units or behavior.

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: run Python inside Toolbag. It also identifies the execution context (`mset` imported) and distinguishes this as the generic code-execution tool among otherwise domain-specific siblings.

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 an important prerequisite: the user must have enabled 'Allow Python execution'. However, it does not explain when to prefer this over the many specific sibling tools, nor when not to use 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a useful behavioral detail — that it returns exists: false when no fog is present — which tells the agent how to detect absence. It does not add further behavioral context beyond that.

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 wasted words. It is terse but appropriately sized for a simple getter, though the terseness contributes to the missing parameter 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 detailed return-value explanation is not required, and the exists:false note covers the key edge case. However, the lone 'ref' parameter's meaning is left entirely undocumented, which is a real completeness gap for an agent trying to invoke this 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% and there is one parameter, 'ref', whose type (integer|string|null) and purpose are entirely unexplained in both schema and description. The description does not compensate for this gap, leaving the agent unsure what 'ref' refers to or whether to supply it.

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 (the scene's fog) and states it returns its attributes, which distinguishes it from the sibling fog_set mutation. It is clear about what is retrieved, though it could explicitly name fog_set as its counterpart.

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 call this versus fog_set or other scene-inspection tools like scene_info. The read-only nature is only implied by the word 'get' and the shape of the response, not stated as usage 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior — implicit creation when no fog object exists — but leaves open whether supplied attributes merge with or replace existing fog settings, and how this interacts with the separate 'create' parameter (default true).

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 verb and resource come first and the creation fallback is attached compactly. The dense parenthetical list is efficient though slightly compressed for an eight-key attribute bag.

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 annotations cover the safety profile. For a mutation tool with a free-form nested object and a 'ref' selector, the description is still missing merge-vs-replace semantics and how 'ref' interacts with the auto-creation behavior.

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 carry the parameter burden; it does so for the required 'attributes' bag by naming eight accepted keys and the volumeType enum values, which is real value since the schema declares only additionalProperties:true. It does not explain 'ref' (which fog object to target when several exist) or 'create', so 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 verb (Set) plus the resource (fog) and enumerates the exact attributes it controls, including the accepted volumeType values. The name/description pairing makes it immediately distinguishable from the sibling fog_get without opening either 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?

Usage is only implied: an agent can infer this is the write counterpart to fog_get. The one conditional given ('creates the fog object when the scene has none') describes behavior rather than when to choose this tool over alternatives such as sky_set or object_set_attributes; there are no explicit exclusions or preconditions.

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?

Annotations already cover the safety profile (readOnly=false, destructive=false, openWorld=false). The description adds genuinely useful behavioral context — attribute availability varies by build, and 5.02 lacks shape/physical units — but says nothing about defaults, failure modes, or scene requirements for a mutation 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?

One dense sentence, front-loaded with the core action and types, with supporting detail in a trailing parenthetical. Efficient, though the parenthetical packs several distinct ideas (attribute list, attribute discovery, version limits) into one clause without separation.

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 annotations cover the safety profile. Given the version-sensitivity of light attributes and the opaque attributes object, the description provides the necessary pointers; only the lack of any scene/prerequisite context 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?

Schema description coverage is 0%, so the description must compensate, and it does for the key gaps: it names the valid light_type values (the schema has no enum) and lists concrete keys for the opaque attributes object (brightness, color [r, g, b], castShadows, width, lengthX, lengthY, spotAngle, useTemperature, temperature). It says nothing about name/position/rotation semantics, but those are largely self-evident.

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 opens with a specific verb and resource ('Create a light') and immediately enumerates the valid light types ('omni', 'spot' or 'directional'), so an agent knows exactly what the tool produces. The create verb inherently separates it from siblings like light_list or object_create.

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 by the verb, and the parenthetical points the agent at object_attributes to discover which attributes a given Toolbag build supports, plus a version caveat for 5.02. However, it never states when to prefer this over object_create/object_duplicate or what prerequisites (e.g. active scene) are needed.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile needs no restating. The description's one genuinely additive claim is the scope note that sky child lights are included, which is not derivable from structured fields; beyond that it mostly re-lists return fields already present in the output schema.

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 with zero filler, front-loading the scope ('All lights') and then the returned attributes. Every clause carries information.

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 parameterless read with a full output schema and complete annotation coverage, the description is sufficient — the agent knows what it gets and that sky child lights are in scope. A minor gap remains around whether the result is scene-wide or selection-scoped and whether any ordering applies.

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. Baseline 4 applies; the description correctly avoids inventing filter or scope parameters.

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 (all lights) and enumerates the attributes returned (type, brightness, colour, shadows, shape, transform), making the read intent unambiguous. It does not explicitly contrast with light_create or otherwise differentiate from siblings, but the verb-less 'All lights …' framing reads clearly as a listing operation.

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: an agent can infer this is the read path for lights, with light_create as the obvious write counterpart. There is no explicit when-to-use statement, no note on whether it spans the whole scene or the current selection, and no named 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?

Annotations already declare this is a non-read-only, non-destructive, closed-world operation. The description adds the useful default behavior of including children, but does not disclose whether existing assignments are overwritten or whether the material must already 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?

A single front-loaded sentence with no wasted words. It is appropriately terse, though slightly undersized given the complete absence of schema parameter descriptions.

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. However, for a mutation tool with three undocumented parameters and an existing sibling set of material-setting tools, it does not fully cover overwrite behavior or parameter intent.

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 hints that refs are objects and that include_children defaults to true, but does not clarify that name is the material name or explain accepted ref formats; the default it mentions is already in 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 and resource: assigning a material to objects. This is clear enough to distinguish it from siblings like material_create or material_set_field, though it does not explicitly name 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?

Implied usage is clear from the verb, but there is no explicit guidance on when to use this versus material_set_group, material_set_subroutine, or material_set_field. No prerequisites or exclusion conditions are mentioned.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the mutation and safety profile is covered. The description adds one useful behavioral fact — the new material comes pre-populated with default shaders rather than being empty — but says nothing about whether the material is auto-selected, assigned to any object, or how name collisions are handled.

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 verb and resource lead immediately. It is arguably too terse rather than too long, which is under-specification rather than a structural flaw.

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 one-parameter creation tool with annotations and an output schema, the description covers the basic action and the initial state of the material, but leaves open the post-creation side effects (selection, assignment, naming rules) that an agent would want before calling it.

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 sole parameter, 'name', appears with only its title. The description does not clarify whether the name must be unique, whether it can be omitted or auto-generated, or what naming constraints exist, 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?

States a specific verb and resource ('Create a material') and adds the distinguishing detail that the material is initialized with Toolbag's default shaders. It does not explicitly contrast with siblings like material_duplicate or material_import, which is why it falls 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?

No guidance on when to use this versus material_duplicate (copy an existing material) or material_import (bring in an external material), both of which are viable alternatives for getting a material into the scene. The agent must infer the choice from the sibling names alone.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's real value is the disclosed side effect: objects using the material fall back to the default material. That is meaningful consequence information beyond structured fields. It stops short of stating irreversibility or whether the deletion is blocked when the material is in use.

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 sentence, front-loaded with the action, with the side-effect consequence appended. No wasted text.

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 destructive annotation is complemented by the fallback disclosure. However, for a destructive one-parameter tool with zero schema coverage, the definition should at least identify what 'name' refers to.

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 parameter 'name' is undocumented in both schema and description. The description does not clarify whether 'name' is a material name, path, or ID, leaving the one required parameter ambiguous.

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: 'Delete a material'. The resource distinguishes it from object_delete and the other material_* siblings, though it does not explicitly name an alternative tool. Clear and unambiguous purpose.

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 guidance on when to delete versus reassign via material_assign, nor any prerequisites or warnings. The usage context is only implied by the verb 'Delete'.

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?

Annotations already declare a non-destructive write (readOnlyHint=false, destructiveHint=false), so the safety profile is covered. The description adds only that the copy can be named, but says nothing about whether textures/settings are copied, whether the duplicate is added to the scene, or how the default empty new_name behaves.

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 single sentence is front-loaded and wastes no words. It is perhaps too telegraphic, but the structure is 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?

With an output schema present, return values need not be described, but the definition still omits the meaning of the required 'name' and any side effects of duplication. For a mutation tool with no schema descriptions, this leaves the agent guessing at invocation details.

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, but it only clarifies the optional new_name ('optional name for the copy'). The required 'name' parameter is never explained—an agent cannot tell whether it is the source material's name, a path, or a target name. This is a significant ambiguity for a 2-parameter 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?

The description states a clear verb and resource ('Duplicate a material'), which distinguishes it from material_create and material_import. It does not explicitly contrast with siblings, but the operation is unambiguous.

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 instead of material_create, material_import, or object_duplicate, and no mention of prerequisites such as the material existing or being selected. The agent must infer everything from the name.

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?

Annotations already disclose readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the target file format, but omits whether an existing file at 'path' is overwritten and whether a file must pre-exist for import/export symmetry.

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 waste. Brevity is appropriate for a simple two-parameter tool, though it tips into under-specification.

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 file-writing tool with 0% schema coverage, the missing overwrite/error behavior and parameter meanings leave an agent guessing on edge cases.

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 carries the full burden. 'Export a material to a .tbmat file' loosely implies name=material and path=destination, but neither parameter is named or explained, and no format/path convention is 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?

Specific verb (export) and resource (material) plus the output format (.tbmat), so an agent can distinguish it from material_import or scene_export. It stops short of explicitly naming a sibling alternative, but the purpose is unambiguous.

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 statement of when to use this versus material_import or scene_export, no prerequisites, and no exclusions. An agent must infer usage purely from the verb.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds scope information (which slots, how textures are represented, that assignment objects are included), but says nothing about behavior when the name is unknown or how expensive a full dump is.

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 'One material in full' and then enumerates slot, texture, and assignment data. Dense but every clause carries information; 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 shape need not be described, and the annotations cover safety. The remaining gap is the undocumented 'fields' toggle and the absence of any failure mode, which for a two-parameter lookup leaves the agent guessing about a supported option.

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%: 'name' has no documented format (material name vs. path vs. case sensitivity) and 'fields' (boolean, default true) is never explained. The phrase 'with shader and field values' faintly hints that 'fields' controls that output, but the description never states the flag's effect or that it is optional.

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 precisely what is returned: a single material with per-slot shader/field values, textures as path plus sRGB flag, and assignments. The phrase 'One material in full' implicitly contrasts with the sibling material_list, though it never names that alternative or uses an explicit verb.

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: an agent can infer this is the tool for inspecting one material's full contents, but there is no statement of when to prefer it over material_list or material_export, and no preconditions (e.g., material must already exist).

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?

Annotations already indicate the tool is not read-only, not destructive, and not open-world, so the safety profile is known. The description adds accepted file formats, but does not clarify whether import creates a new material, updates an existing one, or how duplicates are handled.

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 wasted words. It efficiently names the action, resource, and accepted formats.

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 simple two-parameter import tool with an output schema, the description still leaves key context missing: the role of the optional name parameter and the side-effect semantics of importing a material. It is under-specified for correct invocation beyond a basic file path.

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 the required 'path' is a file path via the import/file wording and format list, but it does not document the optional 'name' parameter at all.

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 ('Import') and resource ('material file'), and lists supported formats (.tbmat, MTL, named texture files). It does not explicitly distinguish itself from siblings like material_create or scene_import_model, but the action and resource are clear.

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 the tool is used when a material file exists, but gives no explicit when-to-use guidance, no prerequisites, and no alternatives such as material_create or material_duplicate. In a large sibling set, the agent must infer the routing decision.

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?

Annotations already declare the safety profile: read-only, idempotent, non-destructive, and closed-world. The description adds some result context by stating which material attributes are included, but it does not clarify how the optional name filter changes the result set or mention ordering/limits.

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 fragment with no filler, so it is efficient and easy to scan. However, it is clipped enough that it omits important usage and filter details, which belongs in other dimensions rather than conciseness.

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 simple read-only list tool with an output schema and safety annotations, the description is adequate about what is returned. It remains incomplete because it omits the optional name filter and does not distinguish material_list from material_get or other material-listing alternatives.

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 optional name_contains parameter has 0% schema description coverage and is not mentioned in the description at all. The phrase 'All materials' may even imply no filtering, so the agent must infer the filter behavior solely from the property name.

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 clear list operation on materials and names the returned fields: group, assigned object count, and shader per slot. It is clearly distinguishable from mutation siblings, but it does not explicitly differentiate itself from material_get or other material read tools.

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 guidance, no alternatives named, and no explanation of when to use material_list versus material_get. The only implied usage is that it lists 'All materials' rather than retrieving one material.

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?

Annotations establish that this is a non-destructive, non-read-only mutation. The description adds useful behavioral detail beyond annotations: it sets the transparency slot to Cutout, disables Use Albedo Alpha, assigns the channel and Alpha Map, and re-reads from disk. It stops short of explaining broader side effects or whether existing material settings are preserved.

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 dense sentence with little wasted text, and it front-loads the core purpose before listing the configured settings. The telegraphic phrasing is efficient, though some clauses like 're-read from disk' could be clearer.

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 and annotations cover safety, so the description need not explain return values. However, for a six-parameter mutation tool with 0% schema coverage, the description leaves important parameter semantics and usage alternatives underspecified.

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 six undocumented parameters. It explains channel (0 = R), alpha_map as the mask, and use_albedo_alpha being off, but it omits name, srgb, and especially threshold, which are important for correct invocation.

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 operation: configuring alpha-tested transparency from a mask image, including switching the transparency slot to Cutout and assigning the mask as Alpha Map. It is clearer than a mere restatement of the name, though it does not explicitly contrast itself with sibling material_set_texture or material_set_field tools.

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 phrase 'Alpha-tested transparency from a mask image' implies the intended use case, but there is no explicit guidance on when to choose this tool over material_set_texture, material_set_field, or other material tools. No prerequisites or exclusions are stated.

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?

Annotations already declare false for readOnly, destructive and openWorld, so the agent knows this is a non-destructive mutation within the open scene. The description adds the accepted value type space (number/boolean/enum/color), which is useful, but says nothing about overwrite behavior, prerequisites (material must exist), or reversibility. With annotations carrying the safety profile, a 3 fits.

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 short sentences, no filler, with the routing rule front-loaded right after the capability statement. Every clause earns its place by either defining scope or directing to a sibling.

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 annotations cover the safety profile. Given that, the description plus schema is sufficient to call the tool correctly except for the minor name/slot ambiguity, which the sibling tools' naming conventions resolve.

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 required parameters, so the description must compensate and only partially does: it clarifies that 'field' takes a name from material_get and that 'value' is a number, boolean, enum or color. It says nothing about 'name' or 'slot', which are left ambiguous (material name vs. slot identifier/index).

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 (set) and resource (a field of a material slot) and enumerates the exact field types it handles: number, boolean, enum, color. It explicitly disambiguates from the sibling material_set_texture in the same breath, so an agent can pick between them without opening either 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?

Explicitly routes texture fields to material_set_texture and tells the agent to obtain field names from material_get, which is real when/where guidance. It does not mention material_set_cutout or material_set_subroutine as alternatives, so the routing picture is incomplete rather than fully closed.

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?

Annotations already declare destructiveHint=false, readOnlyHint=false, and closed-world scope, so the safety profile is covered. The description adds one genuinely useful behavioral detail — passing '' removes the material from any group — but says nothing about failure modes (unknown material name, nonexistent group, case sensitivity).

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 and the sentinel-value caveat in parentheses. Nothing is wasted, though the parenthetical is terse enough to be slightly cryptic.

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 annotations cover the mutation profile. Still, for a two-parameter tool with zero schema documentation, the description leaves the identity of `name` unclear and omits what happens when the group doesn't exist.

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 carry parameter meaning, and it only partly does. It explains the empty-string sentinel for `group`, but never states that `name` is the material to move (vs. the group name), leaving the most important parameter implicit.

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 ("Move") and resource ("a material into a material group"), which is far clearer than a name restatement. It doesn't explicitly differentiate itself from adjacent siblings like material_set_field or material_assign, but the group-targeting purpose is unambiguous.

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 versus material_assign or the other material_set_* tools, and no prerequisites are stated. It also doesn't say whether the target group must already exist or will be created on the fly.

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?

Annotations already indicate this is a non-read-only but non-destructive mutation with openWorldHint=false. The description adds little beyond that: it does not describe permissions, side effects, reversibility, or rate limits, and its return-value note is redundant because an output schema exists.

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 purpose is front-loaded and the slot list earns its place given the undocumented schema. The final sentence about return values is somewhat redundant because an output schema is present, but overall the structure is 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?

The description covers the slot parameter well and gives useful examples for shader, and the output schema can carry return details. However, it leaves the 'name' parameter unexplained and gives no sibling routing, which are meaningful gaps for a mutation tool with three required parameters.

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 so partially by listing valid slot names and giving slot/shader examples, but it never explains the 'name' parameter and does not exhaustively define valid shader values for each slot.

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: 'Set the shader of a material slot,' with examples that clarify the operation. It is clear what the tool does, but it does not distinguish this from sibling tools such as material_set_field, material_set_texture, or material_set_cutout.

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-tool guidance is provided. The examples illustrate parameter values rather than selection between this tool and closely related 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?

Annotations already declare this is a non-readonly, non-destructive, closed-world mutation. The description adds real behavioral context beyond that: the field is cleared before writing so a changed file is re-read, `srgb`/`mipmaps` inherit the previous texture's settings, and an empty path clears the field. It does not cover failure modes (missing file, invalid slot) or what wrapping/filtering default to.

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 tightly packed sentences: what it does first, then concrete slot/field examples, then the behavioral caveats. No filler, and the clear-then-re-read note is separate from the empty-path-clears note rather than redundant.

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 mutation semantics are covered for the main path. The remaining shortfall is the unexplained `wrapping`/`filtering` options and no note on what happens when the path is invalid or the target material is absent.

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 carry parameter meaning. It explains `slot` and `field` by example, `path` (empty clears), and the fallback semantics of `srgb` and `mipmaps`, but leaves `wrapping`, `filtering`, and `name` (the target material) completely unexplained — a third of the parameters remain opaque.

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: putting an image file into a texture field, with concrete slot/field examples ('albedo'/'Albedo Map', 'surface'/'Normal Map'). It is distinguishable from generic siblings like material_set_field by being texture-specific, though it never explicitly says so.

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 implicit usage guidance via the empty-`path` clearing case and the slot/field examples, so an agent knows how to target a texture slot. However, it never says when to use this instead of material_set_field, material_set_cutout, or material_import, nor what preconditions (existing material, file on disk) are required.

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?

Annotations already declare it non-destructive/non-read-only, and the description adds genuinely new behavioral context: the effect is per-object and non-persistent ('lost on re-import'). That transient-state caveat is exactly the kind of information annotations cannot convey.

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 compact sentence plus a short trailing caveat, with the action and scope front-loaded. Nothing is padded, though the parenthetical and shader analogy are slightly redundant with each other.

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 and annotations present, the description covers the essentials of a small two-parameter tool. It still omits the meaning of toggling show off and the accepted ref forms, which an agent must guess before calling 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%, so the burden falls on the description; it partially compensates by explaining that refs absent means 'all meshes' and provided means 'the given ones'. However, the accepted reference forms (int index vs. string name) and the semantics of show=false (restore culling) are left 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 ('Show back faces (cull back faces off) on all meshes or the given ones') with a concrete scope of all vs. selected objects. No sibling in the list deals with backface culling, so there is little risk of confusion, though it does not explicitly contrast with e.g. object_set_visible.

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?

'on all meshes or the given ones' implies the targeting rule (omit refs = whole scene), and 'lost on re-import' hints that this is a viewport/display-only setting rather than a saved material change. There is no explicit statement of when an agent should choose this over material-related tools or whether it applies to selection.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds useful scope information (only 'plain' attributes, values are type-specific and some are expanded, e.g. camera lens/limits/postEffect) but says nothing about failure behavior, unresolvable refs, or whether unset/derived attributes are omitted.

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 short sentences, front-loaded with the resource and then the sibling relationship. The type list is compact and earns its place; only the parenthetical 'lens, limits, postEffect expanded' is slightly cryptic in phrasing.

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 need not be explained, and the type enumeration covers what comes back. However, with a required but entirely undocumented `ref` and no guidance on interplay with the many sibling getters, the definition is adequate but leaves the main invocation risk unresolved.

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 `ref` parameter is documented only by its title, accepting either integer or string. The description never explains whether ref is an object name, a path, or an index, which is the one thing an agent must get right to call this tool — a real gap that the description should have closed.

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 (an object's plain attributes with current values) and scopes it by object type (light, camera, sky, fog, shadow catcher, backdrop, mesh). The read verb is only implicit ('Every plain attribute of an object...'), but the closing sentence ties it explicitly to the write counterpart object_set_attributes, which distinguishes it from object_get and the setter.

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 line 'These are the names object_set_attributes takes' strongly implies the intended workflow (read here, write there), but it never states when to call this versus object_get, scene_info, or the type-specific getters like camera_get/sky_get/fog_get that also appear as siblings. Usage is inferable rather than stated.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value by saying name/transform/parent/attributes are applied 'right away' at creation (one round trip instead of two), but stays silent on collision behavior for duplicate names, error conditions, or undo.

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 sentence, front-loaded with the verb and the class enumeration, with the optional-field behavior appended. The class list is long but every item is functional information rather than 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?

Return values need not be described because an output schema exists. Given that annotations cover the safety profile and the description covers creation semantics and accepted classes, what remains missing is mostly parameter formatting already implied by the schema's array/object types.

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 carries the full burden and only partially delivers: it maps position/rotation to a 'transform' and names parent and attributes, but gives no formats (array length for position, Euler vs quaternion for rotation) and never explains that parent accepts either an integer or a string handle despite that ambiguity in 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 and resource (create a scene object) and enumerates the exact class values accepted, which lets an agent distinguish it from material_create or baker_create. It does not, however, distinguish itself from the sibling light_create and camera_create tools even though LightObject and CameraObject are listed as valid classes here.

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 or when-not-to-use guidance is given. The most important routing question an agent faces — should I call object_create with 'LightObject' or call light_create? — is left completely unresolved, and nothing states whether this is preferred over create-then-object_set_transform.

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?

The annotations already declare destructiveHint=true and readOnlyHint=false, and the description merely repeats that it deletes objects. It does not add useful behavioral context such as irreversibility, undo behavior, dependency handling, or what happens to child objects. There is no contradiction with the annotations.

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

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

The description is a single front-loaded sentence with no wasted words. It is structurally clean, though extremely terse for a destructive operation.

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?