Model Lab

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

With no annotations, the description carries the full burden and does well: it discloses runtime (15-30 s), the extra cost of motion (~1 minute), the artifacts written to disk, and the shape of the return (failed checks, size, files). It stops short of saying where files land or whether an existing build 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?

Front-loads the verb and resource, which is good, but the second clause is a dense, semicolon-punctuated inventory of outputs and the closing sentence about returns is grammatically tangled. Information density is high but readability suffers.

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, so the description rightly explains what comes back (failed checks, size, files) and the artifact set. For a tool with 0 required parameters it leaves open what happens when name/platform/preset are all omitted, a minor gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description confirms role of motion (GIFs), preset and platform, but adds no syntax or interaction rules beyond what the schema already states.

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 ('Builds a gun in Blender') and enumerates exactly what is produced (rig FBX, magazine FBX, attachment FBX, .blend, facts.json, dev views). This is clearly distinguishable from siblings like build_gun_clips, list_builds, or read_build.

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 alternatives such as build_gun_clips, list_presets, or list_platforms, and no mention that a preset must be discovered first. The only implicit cue is the preset/platform distinction inside the parameter schema, not the description.

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 usefully discloses the output artifacts and the FBX filename convention (A_<name>_<clip>.fbx), but says nothing about whether it overwrites existing files, what permissions or build state are required, how long rendering takes, or what happens on a missing/invalid clip.

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 content is relevant but delivered as one long, heavily punctuated run-on sentence, so the key action is not front-loaded and the reader must parse a dense parenthetical. It avoids filler, but structure and scannability suffer.

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, but the description compensates by naming the exported FBX and GIF artifacts. With the required build parameter and clip/render options fully covered in the schema, the main remaining gap is behavioral: no mention of failure modes or build-state preconditions.

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 100%: build, clips, and render are all documented in the schema, including the full clip list and the 'leave out for all' default. The description adds no parameter syntax or format detail beyond echoing the measured clip elements, so the baseline 3 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 states a specific verb and resource: it measures gun parts on a rig and exports animation clips as FBX plus a GIF. The measured elements (bolt stroke, cover timing, magazine seating, bolt catch) make the resource concrete. It stops short of explicitly distinguishing itself from sibling build_gun, so it lands at a clear-but-undifferentiated 4.

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

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

Usage is only implied: the description explains the source of the clips ('from real beats and timings at 60 frames a second') and the schema notes clips can be omitted for all, which hints at the workflow. There is no explicit when-to-use or when-not-to-use, and no sibling such as build_gun or compare_to_reference is named as an 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?

With no annotations and no output schema, the description carries the burden and does it well: it discloses the alignment approach, the exact 0.4 cm difference threshold, the returned structure (stretches, implicated parts, zone of gun vs rail attachment) and the overlay image. It stops short of saying whether it is read-only or writes any artifacts to disk.

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 long but information-dense sentence with a front-loaded label and a parenthetical clarifying the overlay colors; nearly every clause conveys computation or output detail. It is slightly overloaded and the colloquial opener carries less signal than a plain verb-resource statement would.

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 two-parameter, no-annotation, no-output-schema tool, the description covers the mechanism, the threshold, and the return contents in enough detail to call it correctly. Remaining gaps are side effects and whether the reference must pre-exist, both minor.

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 100% and both parameters carry their own descriptions in the schema, including the default reference id and the omit-build fallback. The description adds the measurement context but no parameter-level detail beyond what the schema already provides, so baseline 3 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?

Names a precise operation (draws the build's side outline at the reference photo's scale, measures both outlines column by column) with a concrete threshold (>0.4 cm) and output. No sibling tool does anything comparable, so an agent can distinguish it immediately from list_references or build_gun.

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 framing 'the real-gun check' implies a verification-after-build use case, and the schema notes that omitting build falls back to the reference's own configuration, but the description never states when to reach for this versus list_references or build_gun, nor any 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?

With no annotations, the description carries the full behavioral burden. It discloses the shape of the returned content (type, range/choices, unit, meaning, and number sources), which is useful, but says nothing about read-only nature, permissions, or whether the platform argument must exist first.

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 tight sentence with no filler or redundancy. However, it opens as a noun phrase rather than leading with the action, which slightly weakens front-loading.

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 single-parameter lookup with no output schema, the description adequately conveys what comes back (metadata plus number sources). It remains incomplete on usage context and behavioral characteristics, but the tool's low complexity limits how much more is needed.

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 100% for the single optional 'platform' parameter (default ar15), so the schema already documents it. The phrase 'A platform's parameters' reinforces the per-platform scoping but adds no syntax or format detail beyond the schema.

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

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

The description names the resource (a platform's parameters) and enumerates the content returned (type, range/choices, unit, meaning, sources), but it is a noun phrase with no action verb, so the agent must infer that it retrieves/describes parameter metadata. It does not distinguish itself from siblings such as list_references or list_platforms.

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

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

There is no when-to-use guidance, no stated prerequisites, and no reference to alternative sibling tools that might supply related platform information. The agent is left to infer when this lookup is appropriate.

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 present, so the description carries the full behavioral burden, and it does disclose the shape of each entry ('what each is, the rails it fits, its states and moving parts'). However, it says nothing about the read-only/static nature of the data, ordering, size, or pagination for a reference listing.

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 identifies the resource first, with the example list and usage note following economically. The parenthetical examples are dense but each one earns its place by concretizing the attachment types.

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 output schema, the description partially compensates by sketching the returned structure (identity, compatible rails, states, moving parts) and by naming the consuming tool. Given a static, parameterless reference list, this is nearly sufficient, though ordering and size remain unstated.

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

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

The tool takes zero parameters, so there is nothing for the schema or description to document; the baseline for a parameterless tool applies. The description correctly does not invent parameter semantics.

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 (attachments a build can mount on rails/M-LOK slots) and enumerates concrete examples (optics, backup sights, carry handle, vertical grip, light), so the agent knows exactly what comes back. It is implicitly differentiated from generic sibling list tools like list_references by tying the content to the build domain, 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?

It gives clear downstream context: 'Pass them to build_gun as params.attachments,' which tells the agent why and when to call this tool relative to the build_gun sibling. It stops short of stating exclusions or alternative sources for the same data.

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 and no output schema, the description carries the full burden and does disclose the returned fields (name, pass status, size) and ordering. It says nothing about pagination, result limits, or the scope of 'latest' (all builds vs. a window), which matters for a list endpoint.

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 ordering ('newest first') before enumerating the returned fields. No filler, no repetition of the name.

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, low-complexity list tool with no output schema, the description usefully enumerates the result fields, which substitutes for the missing schema. Only the absence of pagination/limit behavior 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 zero parameters, so there is nothing to document beyond the empty schema; baseline 4 applies. The description correctly adds no parameter chatter.

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 clear verb+resource (lists builds) and adds scope ('latest', newest-first) plus the fields returned. It implicitly contrasts with the singular read_build, but never names or differentiates itself from siblings like read_build or compare_to_reference.

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?

'Latest ... newest first' hints at the recency-listing use case, so usage is implied. There is no explicit when-to-use, when-not-to-use, or pointer to read_build for single-build detail.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return content (platform/family names plus parameter names) and, by omission of any arguments, implies a static read-only enumeration, but it never states that it is read-only, whether the list is static or environment-dependent, or what the output shape 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 eleven-word sentence with no filler, and the identifying content is front-loaded. The phrasing 'gun families Model Lab can draw' is slightly cryptic but earns its brevity.

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-argument, no-output-schema listing tool the description needs to convey the return values, and it does so at a high level (families and their parameter names). It stops short of describing format, ordering, or how the 'parameter names' relate to describe_params, 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 the schema has nothing to describe and this dimension is at the baseline 4. Nothing in the description misleads about 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?

The description decodes the opaque term 'platforms' as 'gun families Model Lab can draw' and states the payload includes their parameter names, which is clearer than the bare name. It does not, however, differentiate itself from siblings such as list_presets or describe_params, so an agent must infer the boundary. Clear but undifferentiated.

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 list_* or describe_params tools. The agent gets no condition, prerequisite, or exclusion that would select this tool over its siblings.

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

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

With no annotations, the description carries the burden, and it does disclose the return content (each build's parameters and the published lengths it is checked against). However, it says nothing about ordering, scope, or whether the set is fixed, so behavioral disclosure is partial for a read-only listing.

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 padding, and the concrete preset names are front-loaded. The phrasing is a fragment rather than a crisp sentence, which slightly reduces clarity.

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 list tool with no output schema, the description adequately conveys what comes back, but it omits how this listing relates to the many sibling listing tools, which is the main thing an agent needs to choose 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to compensate for on the input side.

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 and its contents (ready guns, their parameters, and published lengths), so an agent can tell what data it returns. But it is a noun phrase with no action verb, and it never clarifies how 'presets' differ from siblings like list_platforms or list_references, leaving differentiation to inference.

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

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

There is no statement of when to use this tool versus the many list_* and describe_* siblings, nor any prerequisite or exclusion. The agent is left to guess whether presets overlap with platforms or references.

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

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

With no annotations, the description carries the full disclosure burden, and it says nothing about ordering, pagination, permissions, or whether the list is static. It does hint at the data carried per item (source, licence, scale, matching build), which is mild return-value context, but behavioral traits are essentially undisclosed.

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 short sentence with no filler, which is good. However, the phrasing is grammatically tangled ('The real-gun photos compare_to_reference measures against'), forcing the agent to re-parse it, and the payload (item fields) is buried rather than front-loaded.

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 are no annotations and no output schema, so the description is the only source of behavioral and return information. It gestures at item contents but omits the core action, ordering, and relationship details needed to call a zero-argument list tool confidently.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics to add. Schema coverage is reported at 100% for an empty object, so nothing is 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?

The sentence describes what a reference *is* (source, licence, scale, matching build) rather than stating that this tool lists them. It never uses a verb like 'list' or 'get', so an agent must infer the action from the tool name alone. The resource is identifiable but the operation is not articulated.

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

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

The only contextual hook is the mention of compare_to_reference, implying these references are the input that sibling consumes, but there is no explicit when-to-use, when-not-to-use, or alternative-selection guidance. Any usage inference is left to the agent.

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. The 'read_' prefix suggests a safe read, but the description says nothing about whether it is read-only, how large the payload is ('every check, files' implies a heavy aggregate read), pagination, or error behavior for an unknown build name.

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 compact with no wasted words, but it is a bare noun list with no verb or framing, which makes it harder to parse than a single well-formed sentence would be. Brevity here stems partly from under-specification rather than disciplined concision.

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 one parameter, no annotations, and no output schema, the description does useful work by naming the returned sections, which partially compensates for the missing output schema. It still omits any sense of response shape, size, or how the aggregate read relates to the granular sibling list 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 100% and there is a single, clearly documented parameter ('a build folder name from list_builds'). The description adds no syntax or format detail beyond the schema, so the baseline 3 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 names the resource ('a build's facts') and enumerates the kinds of data returned, so the agent can infer this is a read of a single build. However, there is no verb, and it never distinguishes itself from siblings that also surface parts of this data (list_builds, describe_params, list_attachments, list_references), so selection between them is guesswork.

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 rather than list_builds, describe_params, or list_attachments, even though they overlap heavily with the enumerated contents. The only hint of context is in the schema ('a build folder name from list_builds'), which is sequencing, not usage guidance.

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