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

The description describes a resource-creating operation ('Add a picture the kit uses', 'Use the id it returns'), while the annotations declare readOnlyHint=true. This is a direct conflict about whether the tool mutates state, so the description cannot be trusted as behavioral guidance.

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

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

Short and front-loaded with the purpose, and every clause carries information. The fragment 'or a whole painted sheet for {"sheet": ...}' is syntactically awkward and forces the reader to reconstruct the meaning, which costs it a point.

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

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

An output schema exists, so the description needn't explain return values, and it still notes 'Use the id it returns in the kit'. Inputs, formats, and the chat-app fallback are covered; only the path/base64_png relationship is left implicit.

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 load and mostly does: it defines the name charset ('letters, digits, _ and -'), explains path (local file path) and base64_png (base64 PNG/JPEG data), and notes PNG-with-transparency preference. It does not state whether path and base64_png are mutually exclusive or 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?

The description states a specific verb and resource ('Add a picture the kit uses') and distinguishes two asset variants: a logo for an 'image' layer or a whole painted sheet. It is clearly not list_assets, render_sheets, or validate_kit, 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?

It gives concrete invocation context (local file path on local servers vs. base64 data) and an explicit exclusion: 'In a chat app that can't send a picture's bytes, skip this: build with layers.' The alternative is an approach rather than a named sibling tool, so routing is clear but not tool-to-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, idempotentHint and non-destructive, so safety is covered. The description adds real behavioral detail beyond that: grid draws u/v coordinate lines every 0.1 (thicker at u=0.5) on the front/back panels, and cropping follows jersey_only. It does not describe the response shape, but the rendering behaviour is well 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?

Every sentence carries information, but the prose is informal and meandering, and the opening is a sentence fragment rather than a front-loaded statement of purpose. It is longer than it needs to be for the payload it delivers.

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 7 parameters, 0% schema coverage and no output schema, the description does enough to call the tool correctly: it covers view, grid, cropping and reference input. The unexplained required 'kit' parameter and the 'body' parameter leave a small gap, but overall it is fit for purpose.

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 mostly does: it explains view selection, jersey_only cropping, grid default and what the lines mean, and the two reference-input modes (path vs base64). Only kit (required) and body ('male') are left unexplained, which keeps it from a 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?

The description states a concrete action: rendering the user's reference picture beside the kit on the game's rider from a matching angle to spot differences. It is clearly distinguishable from siblings like render_sheets or preview_kit. The opener is a grammatical fragment, but the resource and intent 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?

It tells the agent when to use it (to spot what differs — colours, panel/logo placement, sizes) and how to choose the view ('pick the view nearest the reference's angle'). It also gives an explicit fallback when bytes cannot be sent (leave the reference out). No sibling is named as an alternative, so it stops short of a 5.

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 cover the safety profile (readOnly/idempotent/non-destructive), and the description adds substantial context beyond them: the gating preconditions, the refusal behavior, and the exact shape of the result (embedded application/zip resource, kit:// URI, on-disk path). The 'fails unless user_approved' gate is exactly the kind of behavioral disclosure the schema cannot carry.

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 core action, and no sentence is filler, but the heavy nested parentheticals ('(the user has seen and agreed)', '(an embedded resource, application/zip, also readable later as kit://<file name>)') make it dense and slow to parse. Information is earned, but the packaging is run-on.

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

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

For a gated export tool with no output schema, the description covers preconditions, refusal behavior, and the returned artifact and its location, which is most of what an agent needs. Minor gaps remain: error/response shape on refusal and what 'the two finished sheets' 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%, so the description must compensate. It defines user_approved's meaning ('the user has seen and agreed') and path's behavior ('local servers; default its work folder'), and the kit argument is implicitly the kit being exported. This meaningfully exceeds the bare anyOf/boolean 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 ('Write the kit file (.kit.zip)') and enumerates the archive contents (kit.json, sheets, pictures, previews). This clearly separates it from siblings like import_kit (inverse), preview_kit (no artifact), and render_sheets (produces sheets, not the bundle).

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 conditions invocation on 'the compare loop shows the kit matching the user's pictures' and routes the agent to get_kit_spec's workflow. It further states the refusal conditions (never compared, invented parts, missing user_approved), giving both when-to-use and when-it-will-fail.

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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the useful framing that this is a static spec document whose output should precede other operations, but discloses nothing further (no size, rate limits, or freshness).

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

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

A single tight sentence that front-loads the subject (the kit format) and lists the covered topics without padding. The imperative "Read first" is placed last rather than first, a minor structural nit.

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 reference tool with a full output schema, the description needn't explain return values and adequately signals the scope of the spec. It is complete enough to invoke correctly, with only the lack of sibling differentiation as a 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 there is nothing for the description to disambiguate; baseline 4 applies. The schema correctly defines an empty object.

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 kit format/spec) and enumerates its contents: sheets and panels, layer types, workflow. It clearly reads as a reference-documentation retrieval tool, though it never explicitly contrasts itself with siblings like get_template or validate_kit.

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?

"Read first" is an explicit sequencing directive that tells the agent to call this before the other kit tools, which is genuinely useful routing guidance. It stops short of naming alternatives or stating when-not to use it, so it falls just below the top tier.

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=true, but the description states save_to writes a full-size PNG to a path, a filesystem side effect. That directly contradicts the read-only annotation, so this is an annotation contradiction and the disclosure cannot be considered trustworthy.

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 dense but front-loads the core resource and devotes space to necessary variant details. It remains somewhat tangled with parenthetical explanations, so it is not maximally 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 no output schema and 0% schema descriptions, more is needed about the return value when save_to is omitted, and about routing versus sibling tools. The parameter behavior is well covered, but the overall definition has gaps for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It documents all three: sheet values and dimensions, the two style modes with their contents, and save_to's local write behavior. This adds substantial meaning beyond the bare 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 sheet's template) and its variants, and explains what each style contains. It does not explicitly distinguish this from sibling tools like get_kit_spec or render_sheets, so it is clear but not fully sibling-aware.

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 explains what each style is for (guide for placing layers, clean for painting a whole sheet via route B), which gives implied usage. It does not state when to choose this tool over alternatives or any prerequisites/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 declare readOnlyHint=true and destructiveHint=false, but the description says it 'adds its pictures as assets' and 'shows it on the riders'—clear state mutations. This directly contradicts the read-only annotation.

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

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

A single sentence that front-loads the main action, but crams multiple outcomes and a parenthetical without clear structure. It is adequate but could be more scannable.

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 import tool with no output schema, the description mentions the return (kit object) and side effects, but omits parameter usage, error handling, and return-type details. The annotation contradiction further undermines completeness.

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

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

Schema description coverage is 0% for two optional parameters (path, base64_zip). The description does not mention either parameter, leaving an agent with no guidance on how to supply the zip content or path.

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: 'Open a .kit.zip' and describes its outcomes (returns kit object, adds pictures as assets, shows on riders). It does not explicitly differentiate from siblings like preview_kit, but the core 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?

Provides implied usage: 'to keep working on it' and 'to edit and pass to the other tools'. However, it does not specify when to use this over preview_kit or get_template, nor does it state 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds only the weak temporal qualifier 'added so far', which does not clarify scope, ordering, or whether results are per-session or per-kit.

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 phrase with no waste, but that brevity comes from under-specification rather than discipline. There is no front-loaded statement of action for an agent to anchor on.

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

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

An output schema exists, so return values need not be explained. However, for a listing tool sitting among nine siblings, the description omits what an 'asset' is, the scope of the listing, and any relationship to kits or templates, leaving the agent unable to place it confidently.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. No param-level value could be added here.

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 'The pictures added so far' is a noun fragment, not a verb+resource statement, so it never says what the tool does. It loosely hints that assets are images accumulated in the session, but 'pictures' does not even match the tool's own 'assets' terminology, and nothing distinguishes it from siblings like get_template or preview_kit.

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. An agent cannot tell from this fragment whether to call list_assets, get_template, or preview_kit to inspect current state.

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, destructiveHint=false and a closed world, so the safety profile is covered. The description adds meaningful context — the output is a rider/kit preview in the game's visual style and is meant to be compared against a reference — but it never says what is returned (images, paths, count), whether rendering is slow or costly, or where output goes.

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 sentence is front-loaded and the view definitions earn their place, but the text is jammed into run-on lines with embedded definitions ('front34_left = ...') and inconsistent casing ('body:') that make it harder to scan than necessary. Little is wasted, but the structure is loose rather than tight.

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

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

With no output schema and no annotations about return payload, the description should say what an agent gets back (rendered images, file references, counts) and what the kit input must look like. It covers the workflow and two parameters reasonably but leaves the required kit format and the return shape unspecified, which are exactly the gaps a preview/render tool needs filled.

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. It does real work for two of three params: body is constrained to 'male'/'female' and views gets a full enumeration plus a concrete default (front, front34_left, back) that the schema does not express (schema default is null). But the required 'kit' parameter — typed only as anyOf object/string with additionalProperties true — is never explained, leaving the most important input undefined.

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

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

The description conveys that this produces a visual render of the kit on the game's rider model ('in the game's look'), which is a distinct resource from siblings like get_kit_spec or validate_kit, and it explicitly names compare_to_reference as the follow-up step. However, it never uses a direct verb (render/produce/generate), so the agent infers the action from the name plus phrasing rather than being told 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 clear workflow context: use this, then follow with compare_to_reference and fix what differs — an explicit sequencing cue that no sibling states. It does not state when NOT to use this tool (e.g., after edits vs. before) or explain prerequisites for the kit argument, so it stops short of full when/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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds that two images are produced in a fixed order (jersey, then bib), but says nothing about image format, resolution, or size 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?

One compact sentence with no filler, and the key detail (two sheets, jersey then bib) is placed clearly. Slightly fragment-like phrasing rather than a front-loaded verb statement, but very 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?

There is no output schema, and the description does partially cover the return (two pictures in a given order), which helps. But for a tool whose only parameter is undocumented in both schema and description, an agent still lacks enough to construct a correct call.

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

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

The single required parameter 'kit' has 0% schema description coverage and accepts either an object or a string, yet the description never explains what a kit is, whether to pass an object spec or a string identifier, or where such a spec comes from. With the schema silent, the description should have compensated and does not.

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

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

States a specific resource (the kit's two finished sheets) and the output form (pictures), so an agent knows this produces rendered images rather than data. However, it never names or contrasts with the likely-overlapping siblings preview_kit or export_kit, leaving the boundary between rendering and previewing/exporting 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?

"to check the flat layout" implies the use case, which is more than nothing, but there is no explicit when-to-use, when-not, or alternative-tool guidance despite three plausible overlapping siblings (preview_kit, compare_to_reference, export_kit).

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 full safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description carries little burden there. It adds that failures are reported as 'the problems to fix' rather than raising, which is useful, but says nothing about the format source or severity semantics.

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

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

Two short sentences, front-loaded with the operation before the result shape. Slightly redundant to restate the return value when an output schema exists, but there is no filler.

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

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

The tool is simple (one parameter, an output schema, rich annotations), so the description is nearly sufficient. It leaves the string-vs-object input form unexplained and gives no hint about what 'the format' refers to, likely get_kit_spec, which an agent would need to know 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 single parameter has no documented meaning. The description calls it 'a kit object', which is helpful but also narrower than the schema, which accepts either an object or a string (presumably an inline kit or a reference/id); that ambiguity is never resolved.

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 (check/validate) and resource (a kit object against the format), so the agent knows this is a validation call rather than a fetch or render. It does not differentiate itself from neighbors like get_kit_spec or preview_kit, which also touch kit correctness, so it stops short of a 5.

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

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

There is no when-to-use guidance: nothing says whether this runs before export_kit, replaces preview_kit, or what to do when it reports problems. The agent must infer the place of validation in the workflow from the tool name alone.

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