Coating Lab

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

With no annotations, the description carries the full burden. It usefully discloses that the operation is non-destructive (bakes into a 'copy'), the output formats, and an approximate duration (~1 minute), but says nothing about prerequisites, what the spec must contain, or where the result is written.

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 duration and format details are useful rather than redundant. Slightly compressed parentheses cost a point but the sentence earns its place.

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

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

For a tool with a nested spec object, no annotations, no output schema, and 0% parameter coverage, this description is too thin. It omits what spec must contain, whether the spec should come from spec_for_modellab/validate_spec, and where the baked copy lands.

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 never mentions either parameter. A single reference to 'wear masks' weakly implies the spec configures wear, but the nested spec object and the optional name parameter remain completely unexplained.

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

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

The description gives a specific verb ('bakes') and resource (wear masks into a copy of the model), plus concrete output formats (.blend/FBX). It does not distinguish itself explicitly from siblings like render_variants or validate_spec, leaving the agent to infer where it fits in the pipeline.

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

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

There is no explicit when-to-use or when-not guidance, and no named alternative. The parenthetical 'FBX for an engine, .blend for renders' hints at output choice but does not tell the agent when to call bake versus render_variants or validate_spec first.

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

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

No annotations are provided, so the description carries the full burden, and it discloses nothing behavioral: no read-only vs mutation signal, no error/failure semantics, no side effects. 'wear kept out of corners, every finish physical' conveys no actionable 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?

It is short, but the brevity is under-specification rather than economy: a single cryptic sentence with no front-loaded statement of purpose. Being concise does not earn credit when the content is non-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?

For a tool with a required undocumented parameter, no annotations, and no output schema, the description provides essentially none of the information needed to invoke it correctly. Nothing compensates for the structured-data 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?

The single required parameter bake_folder has 0% schema description coverage and is never mentioned in the description. The agent has no idea what a 'bake folder' is, whether it is a path, an ID, or a template reference.

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 phrase 'Each variant against its wear level's band' hints at validating variants against wear-level bands, but there is no clear verb+resource statement and 'wear kept out of corners, every finish physical' is opaque. An agent cannot confidently tell what check_coating does versus check_finish or validate_spec.

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 is mentioned, despite many plausible siblings (check_finish, check_library, validate_spec, list_wear_levels). The agent must guess whether this is a pre-bake check, a spec validation, or something else.

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

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

With no annotations, the description carries the full burden and does not state that this is a non-mutating validation, what the verdict looks like (pass/fail vs. list of rule violations), or whether anything is persisted. The presence of a finish_id defaulting to "candidate" suggests state may be stored, and the description does nothing to clarify that ambiguity.

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 broken sentence is not conciseness but under-specification; the dangling modifier makes the sentence hard to parse. It is front-loaded in the sense that there is only one clause, but that clause does not communicate the action.

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 tool with a nested object parameter, no annotations, no output schema, and 50% schema coverage, the description is far too thin. An agent cannot tell what rules are enforced, what a failure returns, or how finish_id affects the call.

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

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

Schema coverage is only 50%, and the description adds no parameter information at all. The nested finish object is partially documented in the schema, but finish_id — which has a default of "candidate" and an unexplained role — is undocumented in both the schema and the description.

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

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

The fragment implies validating a user-supplied finish definition against rules before it is added, which is a real verb+resource pairing, but the sentence is grammatically broken ("A finish of your own against the rules") and the verb never appears in the text. Nothing distinguishes it from sibling validators such as validate_spec, check_library, or check_coating.

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?

"before you add it" is an implied trigger condition: run this prior to registering a custom finish. However, no alternatives are named and there is no guidance on what to do with a failing result or whether this is a prerequisite for a write tool elsewhere in the set.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose useful result semantics: violations are returned with reasons, and an empty result means everything passes. However, it does not state that the operation is read-only, whether it has side effects, or what permissions are needed.

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 short and contains no obvious filler, with the result semantics front-loaded in the parenthetical. But the sentence is an awkward fragment ('The library against the physical rules') that reads more like a note than a structured definition.

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-parameter, no-output-schema, no-annotation tool, the description is the only source of truth. It gives a hint about output shape but leaves critical context undefined: what 'physical rules' are, what the library contains, and why an agent should choose this over check_finish or validate_spec.

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 parameter semantics are moot and the baseline is 4. The description does not need to explain any inputs.

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

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

The description gestures at an audit of a library against 'physical rules' and says it returns finishes that break a rule and why. That is more than a restatement of the name, but the phrasing is fragmentary and never states a clear verb or what the 'library' or 'physical rules' are. An agent can infer it is a validation/check tool, but the scope and object remain vague.

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 siblings like check_finish, check_coating, or validate_spec. The parenthetical '(empty: all hold)' clarifies the result semantics but not the usage conditions, prerequisites, 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only inspection operation and identifies the returned content (meshes and material slots), but never states that it is non-destructive, how the FBX is supplied, or what happens with invalid/missing files.

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 no filler, and the resource/return content is front-loaded. The grammar is slightly compressed, but the description remains 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?

For a simple one-parameter inspection tool with no output schema, the description gives the essential purpose and the shape of the result. It still leaves the input format and read-only behavior underspecified, which matters because neither annotations nor schema fill those 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 coverage is 0% and the sole 'fbx' parameter has no schema description. The parenthetical '(an FBX)' only hints at the input type; it does not clarify whether 'fbx' is a path, file handle, upload, or asset identifier.

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 gives a specific verb and resource: describing a model's meshes and material slots. The phrase 'for a model Model Lab did not make' clearly separates it from spec_for_modellab, the likely sibling for Model Lab-created assets.

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 states a clear usage context: preparing a coating spec for a model that Model Lab did not make. It does not explicitly name spec_for_modellab as the alternative or spell out when not to use this tool.

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

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

No annotations exist, so the description carries the full behavioral burden, and it says nothing about whether this reads or mutates state, what permissions it needs, or what shape the response takes. The only added signal is the 'shared wear formula' reference, which implies consistency with other tools but is unexplained.

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 short, but the brevity comes from under-specification rather than efficiency: a single sentence fragment that omits the verb and the return semantics. There is nothing to trim, but nothing is front-loaded either because the core action is never stated.

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 annotations, no output schema, and an untyped nested object parameter, the description must do all the work and does none of it. An agent cannot determine what this tool returns or how to populate 'spec' from this text alone.

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

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

Schema coverage is 0% for two required parameters, one of which ('spec') is a free-form nested object with additionalProperties=true and no documented keys at all. The description mentions 'variant' and 'slot' but never clarifies what belongs in 'spec', leaving the most complex parameter completely 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?

The description is a noun phrase with no verb, so it never states what the tool actually does (retrieve? compute? list?). It names a resource ('a variant's values by slot for an engine material') but gives no contrast against siblings such as read_finish or check_finish, so an agent cannot tell which tool to reach for.

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

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

There is no when-to-use, when-not-to-use, or alternative named anywhere. The phrase 'follows the shared wear formula' hints at a domain constraint but does not tell the agent under what conditions this tool applies versus the twelve sibling tools.

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

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

With no annotations, the description carries the full burden, and it does disclose the shape of what comes back (name, process, sRGB hex, metallic, roughness, wear target, measured vs estimated). It does not say whether the catalog is static or mutable, how large it is, or whether measured/estimated is a flag per record — gaps that matter for a zero-annotation tool.

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

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

A single front-loaded sentence that earns its place by listing the returned attributes. Minor deduction for jargon like 'what it wears to', which is opaque without domain context, and for the missing verb.

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?

No output schema exists, so the description must explain the return shape, and it does by naming each field including the sRGB hex format and the measured/estimated distinction. It omits ordering, total count and whether results are paginated, which keeps it short of complete.

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

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

The tool takes no parameters, so there is nothing to document; the baseline of 4 applies. The description correctly adds no param noise.

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 phrase 'Every finish' plus the enumerated field list makes clear this returns the full finish catalog, and the singular sibling read_finish is implicitly distinguished by 'every'. It stops short of an explicit verb ('list'/'return'), so the purpose is clear but slightly inferred.

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

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

There is no statement of when to call this versus read_finish, check_finish or check_library, and no mention of prerequisites or when a targeted lookup is preferable. The only hint is the word 'Every', which merely implies a full-catalog use case.

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

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

No annotations are provided, so the description carries full behavioral burden, yet it says nothing about whether this is a read-only enumeration, how results are ordered, whether names or IDs are returned, or how the list relates to the per-template reads. Only the content category (ready variant sets) is disclosed.

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?

Extremely short with no wasted words, but it is a sentence fragment rather than a front-loaded statement of action, so the structure is under-specified rather than 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?

For a trivial zero-param listing tool with no output schema, the description should at least state that it returns the available template names and perhaps how they map to render_variants arguments. The concrete example list partially covers this, leaving a modest gap.

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

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

The tool takes zero parameters, so per the baseline no parameter documentation is required. The description's example values are illustrative naming conventions, not parameter behavior, but nothing is missing on this dimension.

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 name says list_templates, but the description is a noun fragment ('The ready variant sets') that never states the tool enumerates them. The parenthetical examples of ar15 variant set names do convey what a 'template' is, which is genuinely useful, but the verb/resource pairing comes from the name alone.

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

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

No guidance on when to call this versus siblings like list_finishes, list_wear_levels, or render_variants, nor any prerequisite or ordering hint. The agent must infer that it is the discovery step before rendering.

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

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

With no annotations supplied, the description carries the full burden; it does disclose the payload — per-mask thresholds and a description of how each level looks — which is the main behavioral fact for a static lookup. It does not state that the call is a side-effect-free read, nor anything about ordering or return shape, leaving a gap that annotations would normally cover.

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, front-loaded with the resource name and immediately followed by the level enumeration. The trailing clause 'what the level looks like' is slightly vague but does add real information 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?

For a parameterless reference lookup with no output schema, the description conveys enough: what the records are, the four level values, and that each carries a threshold plus a description. Missing only the return format and whether thresholds are global or per-model, which are minor for a static list.

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 parenthetical level names do not map to any input, only to output content.

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

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

The description identifies the resource (wear levels) and goes further by enumerating the four level names and stating that each carries a threshold and a visual description. It is not verb-led ('list' comes only from the name) and never explicitly says it returns anything, but the resource is unambiguous and clearly distinct from siblings like list_finishes or list_templates.

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

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

There is no statement of when to call this versus the other lookup tools (check_finish, list_finishes, read_finish), no prerequisites, and no exclusions. An agent must infer usage purely from the tool name and the word 'levels'.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does reveal that the response includes notes and sources, but says nothing about read-only semantics, error behavior when the finish does not exist, permission requirements, or the size/shape of the payload.

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

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

A single tight sentence with the resource front-loaded and no wasted words. It is arguably too terse for the gaps it leaves, but structurally it is efficient and readable.

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?

There is no output schema and no annotations, and the one required parameter is undocumented, so the description must do more than it does. Knowing the result includes notes and sources is helpful, but the identifier format and failure behavior an agent needs before calling are missing.

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 required parameter "finish" has 0% schema description coverage — the schema only supplies the title "Finish". The description never clarifies whether this is a name, slug, or opaque identifier, nor any format or matching rules, 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?

"One finish in full, with its notes and sources" states a specific resource (a single finish) and scope (full detail including notes and sources), which implicitly contrasts with the sibling list_finishes. It does not explicitly name that sibling or check_finish, but the singular-and-complete framing is enough for an agent to tell it apart.

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: "one finish" versus a list tool suggests this is the detail-retrieval path, and "in full" suggests it is the heavier read. There is no explicit when-to-use or when-not-to-use guidance, and no mention of how it differs from check_finish or check_coating.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that outputs are look-dev renders plus a sheet and are not game views, but says nothing about file writes, output location, side effects, or whether rendering is expensive or requires a prior bake.

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, which is efficient. Its terseness, though, leaves key concepts and parameters under-specified rather than making every word earn interpretive value.

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 annotations, no output schema, and only partial schema coverage across three parameters, the definition is too thin for a tool that likely produces files. An agent lacks the input/output and side-effect information needed to invoke it reliably.

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 only 33%, so the description should compensate, but it explains neither the required 'bake_folder' nor the 'variants' parameter. The schema's 'views' description ('right, left, close') is not elaborated on, leaving required-parameter meaning and accepted variant values unclear.

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 action ('renders') and object ('the variants'), and adds that it produces 'a sheet of them' in a look-dev context. However, 'variants' is never defined, and the tool is not differentiated from related siblings like bake or read_finish, so an agent cannot confidently tell when this render step applies.

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 bake, read_finish, or other sibling tools, nor any prerequisites or exclusions. The only usage clue is the parenthetical 'not a game's view', which hints at intent but does not route the agent among alternatives.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It hints at the spec contents (variants and wear zones) but does not state whether the operation is read-only, what permissions are needed, what errors may occur, or what side effects exist.

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

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

The description is a single compact sentence, so it is not verbose. However, it is front-loaded with a noun phrase and contains undefined domain terms such as 'slots' and 'marks,' making it concise but opaque rather than efficiently structured.

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

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

The tool has three parameters, low schema coverage, no annotations, and no output schema, so the description needs to carry substantial context. It does not cover prerequisites, return behavior, parameter meanings, or how the tool relates to siblings like validate_spec or render_variants.

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 only 33%, with only the build parameter documented. The description does not explain the build, template, or variants parameters clearly; 'template's variants' and 'wear zones from its marks' are too cryptic to compensate for the undocumented 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 identifies the resource as a coating spec for a Model Lab build, but it is a noun phrase rather than a clear action verb, so it does not say whether the tool generates, retrieves, or computes the spec. It also does not distinguish the tool from siblings such as validate_spec or describe_model.

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, when not to use it, or which sibling tool is the alternative. The only implied context is that it relates to a Model Lab build, leaving the agent to infer the workflow.

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

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

With no annotations, the description carries the full burden: it never states that this is a read-only, non-mutating operation, what the result looks like (list of problems, severities, empty-vs-clean signal), or whether validation is shallow or deep. It does reveal the kind of rules applied (finish presence, material compatibility), which is real behavioral content, but the coverage is partial.

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

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

One front-loaded sentence with zero filler. Its brevity is a strength for scanning, though it tips into under-specification rather than crispness.

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?

No annotations and no output schema, so the description must explain return semantics and safety on its own; it does neither. For a tool whose whole value is a structured problem report, silence on the report's form leaves the agent unable to plan around the result.

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 single 'spec' parameter is an untyped object with additionalProperties=true, so the schema provides essentially no semantics. The description hints at internal structure (slots, finishes, materials) but never explains the expected shape, required keys, or units, leaving the only required argument effectively undocumented.

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

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

The description names a specific resource (a coating spec) and implicitly the action (surface every problem in it), and the two examples ('a slot without a finish', 'a finish that does not go on its material') make the purpose concrete. It falls short of a 5 because there is no explicit verb and no differentiation from near-siblings such as check_coating or check_finish, which an agent could easily confuse it with.

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

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

There is no when-to-use statement, no prerequisite, and no named alternative among the many check_*/list_* siblings. The agent must infer that this is the whole-spec sweep versus per-object checks purely from the word 'spec'.

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