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

With no annotations, the description carries the full burden and does so well: it discloses the visual overlay (purple dashed lines at 0%/100%/key heights), the fitting rule (top/bottom view scaled to front/back width), and the textual output content (dimensions, proportions, mismatches). It still omits failure modes (e.g. what happens with fewer than 2 views or mismatched labels) and permission requirements.

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 effect, then the overlay semantics, then per-parameter notes under clear 'views:/labels:/method:' labels. Dense but each section earns its place; the intermediate overlay explanation is slightly verbose relative to its decision 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?

No output schema exists, and the description compensates by naming what the text report contains. All three parameters are explained and the required/optional split (only views is required) is discoverable from the schema. Remaining gap is the absence of error/edge-case behavior, minor for a read-only alignment utility.

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 schema is bare (array of strings, plain string), yet the description documents all three parameters: views with its four path syntaxes («путь», «путь|N», «путь|0», «путь|x1,y1,x2,y2»), the accepted label vocabulary, and method's role. This fully compensates for the schema gap.

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

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

States a specific verb+resource (выровнять виды / align views) and immediately explains the concrete effect: background removed, uniform object height, common baseline. This is far more than a restatement of the name. It does not, however, explicitly differentiate itself from adjacent siblings such as split_views, compare_views, or export_views, so the agent must infer the boundary.

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

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

Usage is implied rather than stated: labels are described as enabling server-side pair checks (спереди ↔ сзади, слева ↔ справа), and method is pointed at 'как в silhouette'. There is no explicit 'use this when / not when' or named alternative for competing tools, so the routing guidance is only partial.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the alignment rule (height/bottom alignment; scene scale irrelevant, proportions matter) and the exact text output (IoU score, per-height-band wider/narrower, missing/extra regions, key-height shift). It stops short of stating whether the operation is purely read-only or involves any cost, but the behavioral disclosure is unusually rich.

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

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

Front-loads purpose before param details, with clear line-per-parameter structure. Dense and mostly earning its space, though slightly long and mixing prose justification with the parameter list rather than keeping them cleanly separated.

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 4-param tool with no annotations and no output schema, the description supplies the missing return semantics and alignment behavior, which is the critical gap. It lacks only an explicit read-only/mutation note and any guidance on choosing among the many sibling comparison 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 coverage is 0%, yet the description documents all four parameters: 'reference' syntax variants (path, path|N frame, path|0, path|x1,y1,x2,y2), 'render' expectations (same angle, orthographic preferred, transparent background for accuracy), all four 'mode' values with rendered layouts, and what 'method' controls. This fully compensates for the empty schema.

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

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

States a specific verb+resource: comparing a model render against a reference of the same angle, returning silhouette match % and divergence locations. It clarifies scope (silhouette/proportion comparison, not visual similarity) and anchors 'method' semantics to the sibling 'silhouette', so an agent can distinguish it from compare_views/compare_parts.

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

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

Gives an iterative workflow ('Правь модель и вызывай снова, пока совпадение не станет высоким') and defers 'method' behavior to the sibling silhouette. However, it never explicitly says when to choose this tool over compare_views or compare_parts, leaving the routing to inference.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the alignment method (whole-object, height and bottom, as in compare), the return content (per-part match %, wider/narrower/shifted/tilted), and the default name-matching behavior for 'match'. It omits whether the tool writes files or is purely analytical, and any error/limit conditions, so a 4 rather than 5.

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

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

Purpose and the key differentiator are front-loaded in the first two lines, followed by per-parameter notes, which is a sensible structure. It is fairly long and the render description is dense, but each block maps to a distinct parameter and none of it is 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?

For a 4-parameter tool with no annotations, no output schema, and 0% schema coverage, the description supplies the missing context: prerequisites, alignment behavior, result format, and per-parameter meaning. It leaves the return channel (values vs. written files) and failure modes unspecified, so it is strong but not exhaustive.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: every one of the four parameters gets an explanation, including the 'match' JSON shape with a concrete example and the 'path|N' syntax for reference. The 'method' parameter is only defined by cross-reference to 'silhouette' ('как в silhouette') rather than an inline definition, which is the one weak spot.

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 opening line names a precise verb and resource ('Сравнить модель с референсом по деталям') and immediately narrows the scope to per-part matching percentages. It explicitly contrasts itself with the whole-silhouette approach ('Общий % силуэта не замечает ошибок в мелких деталях'), which distinguishes it from the sibling 'compare' tool.

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

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

It states the selection condition well: use this when overall silhouette matching misses small-detail errors, and it names the prerequisites (reference must already have parts marked via 'parts', render must come from render_parts). It does not spell out when NOT to use it or a full alternative-selection rule, so it falls just 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?

With no annotations, the description carries the full burden. It usefully discloses the result layout and a hard limit (max 6 pairs, matching order), but says nothing about accepted input formats, permissions, failure modes, or what happens if pairs are mismatched.

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

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

Three short, front-loaded paragraphs: output description first, then input-pairing rules, then per-parameter notes. No filler, though the trailing parameter glosses read like notes rather than prose.

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 and no annotations, so the description must do everything; it covers the result structure and pairing constraint well, but leaves input format (paths vs IDs vs base64), method options, and error behavior to inference from sibling tools.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: labels = view names, method = object-finding method (as in silhouette), references/renders = ordered pairs of the same view. The 'auto' default of method is not explained, which is the main gap.

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

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

States a specific verb and resource ('Сравнить сразу несколько ракурсов') plus the exact output shape (one row per view: reference, model, difference, % match). The word 'сразу несколько' implicitly distinguishes it from the single-view 'compare' sibling, though it never names that contrast 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 usage context (references/renders must be pairs of the same view in matching order, up to 6 pairs) and defers semantics to siblings ('как в compare', 'как в silhouette'), but never states when to choose this over compare or compare_parts, nor any exclusion.

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

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

With no annotations, the description carries the full burden and does well: it defines the coordinate frame (origin on the symmetry axis at the object base, x right, z up), the unit convention, the return shape (outer contour and holes as separate lists), and the side effect of save_to writing a .json. It does not disclose safety/permission requirements or failure modes, which keeps it short of a 5.

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

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

Front-loaded with the deliverable before the coordinate frame and the per-parameter notes; each block (output description, coordinates, parameters) earns its place. The parameter block reads as a list of definitions rather than flowing prose, and 'method' is a dangling cross-reference, but there is little waste.

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 convey the return value — and it does, specifying scene coordinates, unit scaling, and that holes are returned as separate lists. Combined with full parameter documentation, this is sufficient for an agent to call the tool correctly, with only the vague 'method' option and unstated error behavior left open.

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 6 parameters exist, so the description must compensate — and it does, defining view syntax ('path', 'path|N', 'path|0', 'path|x1,y1,x2,y2'), detail's meaning and default, half, real_height, save_to, and method. The one weakness is 'method', which is defined only by cross-reference ('as in silhouette') rather than being self-contained.

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 deliverable — a silhouette contour as points plus a vertical symmetry axis, in scene coordinates, ready for Blender curves — and even names the output partitioning (outer contour vs holes). It does not explicitly contrast itself with the sibling 'silhouette' beyond deferring the 'method' option to it, so sibling differentiation is only partial.

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

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

Usage is implied rather than stated: 'half' is flagged as the profile needed for a body of revolution (Screw), and 'save_to' is framed for reading contours back in Blender code. There is no explicit statement of when to choose this over 'silhouette', 'view', or 'parts', and no 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?

With no annotations, the description carries the full load and discloses important behaviors: the folder is created, existing files are overwritten, backgrounds are removed via a chosen method, and views.json records image size, object placement, and real_height-derived scene-unit data. It does not describe error handling or the tool's return value, leaving minor gaps.

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

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

The description is front-loaded with the core action and outputs, and each subsequent paragraph (alignment consistency, views.json details, parameter glossary) adds necessary information. It is longer than average but stays on point with no filler, though the dense parameter glossary could be slightly tighter.

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

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

Given five parameters, no output schema, and no annotations, the description covers the operational context, output artifacts, and parameter semantics well. It omits what the tool returns (e.g., file paths or status) and any failure modes, which are the remaining gaps.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for all five parameters: views (as in align_views), folder (absolute path, created, overwritten), labels (named values included in filenames), real_height (scene units with example), and method (as in silhouette). This fully replaces missing schema documentation.

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 ('выровненные виды'), plus the exact outputs (PNG with transparent background and views.json) and the intended use case (Blender/C4D underlays). It also names related tools (align_views, silhouette) for parameter provenance, distinguishing its role from those siblings.

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

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

Provides a clear context ('для подложек в Blender / C4D') and implies a workflow by specifying that views come from align_views and method from silhouette. It does not state when *not* to use the tool or name direct alternatives, so it stops short of the top score.

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 discloses rich parameter behavior (formats, defaults, enum-like values) but is silent on whether the tool only renders/returns an image or mutates any stored view, and gives no output or permission context. Solid but incomplete for a zero-annotation tool.

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

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

Purpose is front-loaded in one sentence, then each parameter is handled in a tight line. No padding, though some lines are dense and the structure relies on the reader parsing per-parameter prose.

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

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

Given 5 parameters at 0% schema coverage and no annotations, the description is thorough on inputs. It does not describe the return value (no output schema exists), which is a minor gap for a rendering tool whose output an agent may need to anticipate.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it explains all five parameters—view formats ('path', 'path|N', 'path|x1,y1,x2,y2'), step in pixels with its default rule, units ('px'/'percent') with the 0–100% convention and line spacing, mode values, and method. This is 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?

States a specific verb+resource: it overlays a coordinate grid on a view for measuring part sizes and positions using labeled lines. The purpose is concrete and an agent can distinguish it from a plain view tool. Sibling differentiation is implicit (references 'view' and 'silhouette' for parameter behavior) rather than explicit.

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

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

Usage is implied ('to take dimensions and positions of parts', 'grid is convenient to place on a large area'), which tells the agent the measurement context. However, there is no explicit when-to-use-vs-alternatives guidance relative to the many sibling tools (view, silhouette, contour, mark, compare).

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

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

With no annotations, the description carries the full behavioral burden and does disclose output behavior: frames are outlined with purple borders, numbered, and their coordinates are listed in text. This tells the agent what it will get back, though it does not state read-only nature, file access requirements, or error 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?

Three short, front-loaded sentences: purpose first, then the entry-point guidance, then the parameter note. Little waste, though the parameter line is almost too terse to be fully useful.

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 and no output schema, the description must explain behavior and returns, and it does describe the return content (dimensions, format, framed views with text coordinates). It leaves some gaps about output channel/format and failure modes but is largely adequate for a one-parameter inspection tool.

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

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

Schema description coverage is 0% and the single 'path' field has only a generic title, so the description must compensate. It does by defining path as an absolute path to the image, adding format and meaning that the schema lacks.

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 resource and output set: an overview of a reference image with its full picture, dimensions, format, and any frames from a multi-view sheet. This is more specific than the generic name 'inspect', but it does not explicitly differentiate itself from siblings like view or sheet.

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

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

It gives an explicit entry-point instruction ('Start working with a reference with this tool'), which clearly tells the agent when to reach for it first. It stops short of naming alternatives or stating when-not-to-use it.

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

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

With no annotations provided, the description carries the full burden. It usefully discloses the return content (name, pixel size, file size), implying a read-only listing operation, but says nothing about permissions, depth limits, or behavior when the folder is empty/invalid.

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 a single sentence describing the result, followed by two tight parameter notes. No wasted words; appropriately sized for a two-parameter tool.

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

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

For a simple, non-destructive list tool with no output schema and no annotations, the description covers the essential facts: what it lists, what it returns, and both parameters. The main gap is usage context relative to siblings.

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

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

Schema description coverage is 0%, so the description must compensate — and it does, documenting 'folder' as an absolute path and 'recursive' as searching nested folders. This adds meaning the bare schema lacks, though format/error handling details are absent.

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 — listing image and video files in a folder — and even names the returned fields (name, pixel dimensions, file size). It is clearly distinguishable from the view-processing siblings, though it doesn't explicitly contrast 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?

There is no guidance on when to use this tool versus the many sibling tools (inspect, view, compare, etc.). Usage is only implied by the verb 'list'. No prerequisites or exclusions are stated.

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

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

With no annotations, the description carries the full burden and does a lot: it specifies the return content (lengths, angles, percentages), that the area around marks is shown zoomed, and detailed snap behavior (pull to silhouette edge up to 12px, or to sharp internal gradients such as seams/chamfers). It leaves one gap: it does not clarify whether marks persist to the file or are just an overlay, so side-effect behavior is ambiguous.

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 purpose and output, then neatly structured per parameter. Dense but every line earns its place; the parameter blocks are easy to scan. Slightly long overall, but no filler sentences.

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

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

Given six params at 0% schema coverage, no annotations, and no output schema, the description supplies both parameter syntax and expected return values, which is substantial. It is nearly complete; only persistence/side-effects of the marks and the meaning of the view-index suffix remain unspecified.

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

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

Schema coverage is 0%, so the description must compensate, and it documents all six parameters: view with its four format variants ('path|N', 'path|x1,y1,x2,y2'), points/lines array shapes, labels defaulting to P1,P2,…, snap enum values with semantics, and method. The only weakness is that 'method' is delegated ('как в silhouette') rather than explained, and the 'N' in 'path|N' is not fully spelled out.

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 verb+resource: draw points/lines on a view and return exact measurements (px length, % of object dimensions, angle, point position in %). This is far more specific than the vague name 'mark'. It does not, however, explicitly differentiate itself from the many measurement siblings (grid, contour, silhouette); it only references silhouette for the method parameter.

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

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

Usage is implied rather than stated: 'проверка себя вместо оценки на глаз' frames it as a verification tool and 'Если отметка легла не туда — поправь и вызови снова' gives an iterative workflow. There is no explicit when-to-use-this-vs-alternatives guidance against siblings like grid or contour.

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

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

With no annotations, the description carries the full burden and does well: it discloses that colors are sampled with lighting so highlights and shadows appear as separate entries, and warns that the base material color is typically the most frequent mid-tone rather than the lightest or darkest. This is exactly the kind of non-obvious behavior that prevents misreading results. It stops short of covering error cases or access constraints.

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 and output format are front-loaded, followed by a behavioral caveat, then a compact parameter block. Every line earns its place, with only minor formatting irregularity from the embedded line break.

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 4-parameter tool with no annotations and no output schema, the description covers the operation, the meaning of results, and all parameters. It does not describe response structure (ordering of colors, field names for the linear/sRGB components) or failure modes, but it names the output formats, which is adequate.

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

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

Schema description coverage is 0%, so the description must compensate and it does for all four parameters: view syntax including slices ('path|N', 'path|0') and crop rectangles ('path|x1,y1,x2,y2'), the 1..12 range for colors (absent from the schema), the meaning of whole=true, and method's relationship to silhouette. This adds substantial meaning beyond the bare schema titles.

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

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

The description states a specific operation — extracting the object's main colors for materials — and names the output forms (HEX, sRGB 0..1, linear 0..1, area share). It also clarifies the semantics of the result (lighting included; base color is the most frequent mid-tone). Sibling differentiation is only partial, limited to a reference to silhouette for the method parameter, but the verb+resource is unambiguous.

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

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

The 'whole' note implies when to include background, and 'method' is delegated to silhouette ('как в silhouette'), which gives the agent a cross-reference. However, there is no explicit statement of when to choose palette over siblings like silhouette or compare, nor any prerequisite or exclusion. Usage must be inferred.

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 much of it: it discloses the ambiguity of a single point, the iterative retry loop, that segments are persisted and reusable via the 'path|name' view syntax, and what is returned (colored numbered mask plus size/position in % of the object frame, area, pieces, holes, long-axis tilt, color). It omits failure modes, cost/latency of the SAM model, and any permission or overwrite 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?

Well front-loaded: purpose first, then the point/box workflow, then persistence, then per-parameter detail. Length is justified by the tool's complexity, though it is a dense run-on block and partially restates the points/exclude/box semantics already present in the nested schema definitions.

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

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

For a 3-parameter, nested-object tool with no annotations and no output schema, the description supplies the return contents, the retry protocol, and persistence behavior, so an agent has enough to invoke it correctly. It leaves method's accepted values and error behavior unaddressed.

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?

Top-level view/parts/method have no schema descriptions, and the description compensates well: it enumerates view forms ('path', 'path|N', 'path|0', 'path|x1,y1,x2,y2'), caps parts at 12, and fixes coordinates as original-image pixels. It adds little on method beyond deferring to silhouette, so a full 5 is not warranted.

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 opening sentence states a specific verb+resource+method: isolate an object's parts by points/boxes using SAM 2.1 and measure each. It then contrasts against siblings by naming silhouette, contour, palette, mark, grid, align_views and compare_parts and describing how a saved part feeds each. An agent can distinguish this from the whole-object tools without opening any schema.

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

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

Strong operational guidance: place a point in the part center (or several points, or a box), and if the wrong region is isolated, add points/box/exclude and re-call with the SAME name. It also states the most reliable recipe (2-3 points plus exclude on same-colored neighbors) and the pick fallback for a single point. It never explicitly says when to prefer silhouette or another sibling instead, so the when-not side is only implied.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the 1–12 image cap, the 2000 px-per-image limit, and default label behavior, but says nothing about permissions, output format, or failure modes for a tool whose output is an image.

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?

Purpose is front-loaded, followed by a constraint tip and per-parameter notes. Dense but every line contributes; nothing is padded.

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

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

For a 3-parameter tool with no output schema and no annotations, the description covers purpose, limits, and all three parameters adequately. Minor gaps around return behavior remain but are not critical.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it documents paths as absolute with a 1–12 range, labels as matching the path count with a number+filename default, and mode as mirroring view with the valid values enumerated.

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+resource: composing several images onto one sheet with captions for side-by-side comparison. It is clear what the tool produces, but it does not explicitly distinguish itself from overlapping siblings like grid, compare_views, or compare_parts.

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 via the limit-saving tip (use when a conversation exceeds 20 images). There is no explicit statement of when to prefer this over view, grid, or compare_views, nor any exclusion criteria.

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

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

With no annotations, the description carries the full burden. It does disclose the output behavior (pale background with purple mask contour, ask the agent to verify visually) and the neural-net method used, which is meaningful context. But it omits failure behavior, what happens when segmentation fails, and any performance/permission characteristics.

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

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

Purpose and the visual-verification note are front-loaded, followed by a compact view/method reference. Every line contributes; only the pale-background/purple-contour sentence is slightly padded relative to the rest.

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 and no annotations, so the description must explain what the tool does and returns, which it largely does (measurements plus a visual overlay). It is close to complete for a 2-parameter tool; the main omission is error/failure handling when no object is detected.

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 supply parameter meaning and it does so thoroughly: the view syntax ('path', 'path|N', 'path|0', 'path|x1,y1,x2,y2') is spelled out with the meaning of each form, and all three method enum values are defined with the scenarios they fit.

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

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

Names a specific operation (separate object from background) and a concrete measurement set (bounding box, proportions, parts, holes, key heights). This is clearly distinguishable from siblings like contour and parts because it enumerates the silhouette metrics it returns.

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 mode-selection guidance for the method parameter ('simple' only for uniform background, 'auto' for shadows/reflections/complex backgrounds), which is real when-to-use advice. However, it gives no guidance on when to pick silhouette over sibling tools such as contour or parts, leaving tool selection implied.

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

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

With no annotations, the description carries the full burden. It usefully discloses the frame-detection algorithm (solid-color gaps or seams), the single-frame fallback, and upscaling of small frames, but says nothing about what is returned (single montage vs. separate images), file writes, or failure when no frames are found.

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?

Purpose is front-loaded in the first sentence, mechanism and edge cases follow, and parameters are listed last. Slightly more detail than strictly needed, but every sentence carries information.

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

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

For a two-parameter tool with no output schema and no annotations, the description covers purpose, algorithm, and both parameters adequately. It is thin on return semantics and failure modes, which the agent would need to know before relying on 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%, so the description must compensate, and it does: path is documented as the absolute image path, and max_edge is explained as the per-frame long-side cap with a 200–2000 range and a 1024 default (the range is not in the schema). This meaningfully exceeds 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?

States a concrete verb (splits) and resource (a sheet/collage/turnaround) and adds the outcome ('shows each frame large'), so the agent knows exactly what it does. It does not explicitly differentiate itself from siblings like grid, sheet, or view, so it falls short of a 5.

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

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

The description implies the usage context ('лист (коллаж, turnaround)') but never states when to prefer this over grid, sheet, view, or export_views. No exclusions or prerequisites are given, leaving selection to inference.

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

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

With no annotations, the description carries the full burden and does well: it guarantees maximum quality without recompression, discloses that it returns an image plus text with a coordinate-translation formula, and explains the max_edge default rationale (avoiding the per-conversation image limit past 20 images). It does not mention any rate limits or file-size constraints, but for a read-only viewing tool this is solid coverage.

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

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

The description is front-loaded with the core purpose followed by one line per parameter, so it is easy to scan. It is somewhat long, especially the multi-line mode enumeration, but each line adds actionable meaning rather than filler.

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

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

For a 4-parameter viewing tool with no output schema and no annotations, the description is nearly complete: it covers every parameter, the return payload, and the default behavior. The one gap is the absence of routing guidance against sibling tools, which an agent on a crowded toolset would still need.

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%, yet the description documents all four parameters with meaning beyond the schema: path lists accepted formats and requires an absolute path, region defines [x1,y1,x2,y2] in original-pixel space and notes small regions get enlarged, mode enumerates four values with distinct interpretations, and max_edge gives the 200-2576 range and the reason for the 2000 default.

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 verb and resource: display an image or a region of it at maximum quality without recompression. This is clear and specific. However, it never contrasts itself with siblings like inspect, split_views, or sheet, so an agent cannot fully disambiguate from the schema 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?

The mode parameter is explained with use cases (contrast for chamfers/seams/relief, edges for silhouette and form lines, tones for reading volume), which is genuinely useful guidance. But it does not state when to choose this tool over alternatives such as inspect or compare_views, leaving the tool-selection decision to inference.

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