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

The description discloses that 'tools are consumed', which is a key side effect not covered by annotations (none provided). It omits whether targets are also consumed or replaced, and does not describe the output or whether the operation modifies the scene in place.

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

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

The description is a single, information-dense sentence with no redundant phrases. Every clause adds value: the operation types, the difference semantics, and the consumption warning.

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

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

The description covers the core operation and tool consumption, but lacks details on whether targets are also destroyed, how solids are referenced, and what the tool returns (though an output schema exists). These gaps leave room for misinterpretation in a destructive operation.

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 schema description coverage of 0%, the description compensates by explaining the valid values for 'operation' and the roles of 'targets' vs 'tools' (especially in the difference operation). This adds meaningful context over 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 clearly states the tool performs boolean operations on solids, listing the three specific operations. This distinguishes it from sibling tools like serp_transform or serp_create_surface, which handle different geometric modifications.

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 provides context for when this tool is appropriate (combining or subtracting solids) via the operation list and clarifies the difference operation semantics ('targets minus tools'). However, it does not explicitly mention alternatives or exclusion cases.

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 input ordering, selection prompt semantics, and error behavior for too few or leftover inputs, but it does not state whether commands may mutate the document, whether changes are undoable, or what permissions are needed for an arbitrary command runner.

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

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

The definition is front-loaded with the core action, followed by compact, purposeful examples and notes. Every sentence adds concrete value without repetition or unnecessary filler.

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

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

An output schema exists, so return values need not be explained, and the description covers the non-obvious invocation protocol well. The main remaining gap is guidance on choosing this generic tool over the many specialized sibling tools and a clearer statement of mutation or undo implications.

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: 'command' is shown as the command name, and 'inputs' is explained as ordered interactive responses with examples. It also clarifies that selection prompts accept object names, 'all', or an empty string to finish.

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

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

The description clearly states a specific action and resource: running any Serpentine3D command exactly as if typed at the command line, with examples such as 'circle', 'extrude', and 'zoomextents'. However, it does not explicitly differentiate this generic escape hatch from the many dedicated sibling tools like serp_create_curve, serp_transform, or serp_boolean.

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 examples imply how to format command and inputs, and the notes explain selection prompt values. But there is no explicit guidance on when to use this tool instead of the dedicated sibling tools, nor any stated exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden of disclosing side effects. It explains how 'kind' interprets the points, but it does not state whether the curve is added to the scene, what the return value is, or any consequences. This is a notable gap for a creation tool.

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

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

The description is compact and front-loaded, stating the primary purpose in the first sentence and then enumerating the meaningful 'kind' options in the second. Every word earns its place; there is no filler or redundancy.

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 5 parameters, no annotations, and zero schema-level descriptions, this tool needs more context. The description only covers 'points' and partially 'kind', omitting the behavior of 'degree', 'closed', and 'name'. It is not enough for reliable invocation in varied scenarios.

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 adds meaning for 'points' (3D coordinates) and 'kind' (four interpretation modes), but it leaves 'closed', 'degree', and 'name' completely unexplained, making it hard for an agent to set them correctly.

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

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

The description opens with a specific verb-resource pair: 'Create a NURBS curve from 3D points.' This clearly distinguishes it from sibling tools like create_surface or transform, and it immediately states the core input format.

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 this tool is for making curves from given 3D points and defines the 'kind' options, which helps choose call behavior. However, it never explicitly tells when to prefer this over alternatives like create_surface, nor does it mention any exclusions or prerequisites.

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

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

With no annotations, the description must carry the behavioral disclosure. It does reveal operation-specific behavior, such as 'closed profiles become solids' for extrude with cap, and defaults for distance and angle. However, it does not disclose whether the operation modifies source curves, what happens on failure, or what the output object is (e.g., its name or type). This is a moderate level of transparency.

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

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

The description is compact and well-structured. It leads with a one-sentence purpose, then a bullet-style list of operations and their parameters. Every line adds value with no redundancy or padding.

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

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

Given the tool's complexity (five operations, variable params) and the existence of an output schema (which can convey return value details), the description covers the core usage well: it specifies prerequisites (existing curves), operation parameters, and defaults. It falls short only on the unexplained `name` parameter and edge-case behaviors, but overall it is sufficiently complete for typical use.

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 compensates by detailing `operation` values and the structure of `params` for each operation, including defaults and example vector format (e.g., direction [x,y,z]). It also explains how `curves` should be provided (order, count). The only gap is the `name` parameter, which is likely the output name but is not explained.

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

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

The description clearly states the tool's function: 'Create a surface/solid from existing curves'. It specifies the resource (curves) and the result (surface/solid), and enumerates the supported operations (extrude, revolve, loft, planar, sweep), which distinguishes it from sibling tools like serp_create_curve (which creates curves) and serp_boolean (which operates on existing solids).

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

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

The description gives a clear context for use: creating surfaces/solids from existing curves. It does not explicitly compare with alternatives or state when not to use it, but the purpose is so specific that an agent can readily infer appropriate usage scenarios. No exclusions are mentioned, but none are needed for such a specialized tool.

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

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

No annotations are provided, so the description carries the full burden. It clearly discloses the file-writing behavior and format selection, but it does not mention whether existing files are overwritten, whether directories must exist, or any error conditions. For a straightforward export tool, this is moderate transparency.

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

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

The description is a single sentence that front-loads the action ('Export') and includes the essential qualifiers: target (scene/selection), formats, and format selection mechanism. Every word earns its place; no redundancy.

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 conceptually simple, and the description covers the core behavior and parameters. An output schema exists, so return-value documentation is not needed. The main missing context is file-overwrite behavior and potential failure modes, but overall the description is sufficiently complete for this export tool.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to the 'path' parameter by explaining that the extension determines the format, and it clarifies that 'selected_only' controls whether the scene or current selection is exported. This is valuable context beyond the raw 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 clearly states the tool exports a scene or selection to specific 3D file formats (.serp, .step/.stp, .obj), with the format determined by the file extension. This is a specific verb+resource+behavior that distinguishes it from siblings like serp_import and serp_screenshot.

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

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

The description provides clear context: you can export either the whole scene or the current selection, and the format is chosen by the file extension. It does not explicitly mention when to use this over alternatives, but among the siblings only serp_screenshot is a visual export, and this tool's purpose is distinct enough that no exclusion is necessary.

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

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

With no annotations, the description carries the full burden, and it does disclose genuinely useful behavior: the add is additive ('What is already there stays') and non-destructive to the user's view unless zoom_extents is set. It omits error behavior for unsupported/duplicate files 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?

Three short sentences, front-loaded with the action and formats, then the two behavioral caveats. No filler; every clause carries information.

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

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

An output schema exists so return values need not be described, and the description covers the mutation's additive semantics and viewport effect. It stops short of covering failure modes or permissions, which would matter for a no-annotation write tool.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it enumerates the accepted file extensions for `path` and explains what `zoom_extents` actually does to the user's view. Remaining gaps are path format/conventions and whether the path must be absolute.

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 ('Add a file to the scene') and enumerates supported formats (.serp, .step/.stp, .obj), which goes beyond the tool name. It does not explicitly distinguish itself from siblings like serp_export or serp_command, but the import action is unambiguous.

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

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

No when-to-use guidance, no prerequisites, and no named alternatives among the many siblings (serp_export, serp_command, serp_prepare_script). The reader must infer that this is the tool for bringing external geometry files into the scene.

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 must carry the behavioral burden, and it partially does: it discloses that layers can be nested via 'parent' and addressed by path, and it details the style/hatch units and defaults (0 = printer default, 'from print'). However, it says nothing about what 'delete' does to objects on the layer, whether operations are reversible, or what errors occur for a missing layer — significant gaps for a mutation tool with zero annotation 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 action enumeration is front-loaded and every sentence carries information the schema does not. The style clause is a dense parenthetical run-on that would read better as a list, but given 0% schema coverage the detail is justified rather than wasteful.

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

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

An output schema exists, so return values need no explanation, and the nested-layer and path-addressing model is well covered. What is missing is the destructive-behavior contract for 'delete' and any indication of which parameters pair with which actions — material for an 8-parameter mutation tool with no annotations.

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: 'color' format is given as [r,g,b] 0-1, 'style' is broken down field-by-field with units and accepted values, 'parent' is explained, and path-based naming ('Walls::Interior') is clarified. 'objects', 'visible', and 'new_name' are only covered by implication through the 'assign', 'visible', and 'rename' action names, which is a minor remaining gap across 8 undocumented parameters.

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

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

The description opens with a specific resource ('Manage layers') and immediately enumerates the exact operations via the action values, so an agent can map intent to a call. It is clearly distinct from siblings like serp_create_curve or serp_transform, though 'Manage' alone is generic and the enumeration does the identifying work.

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 through the action list rather than stated: an agent can infer 'list' is the default and that 'assign'/'delete' are the mutating paths, but there is no explicit when-to-use-this-vs-alternative guidance, no prerequisites (e.g. must a layer exist before 'assign'?), and no note on which actions require 'name'.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not state whether the tool is read-only, whether it operates on existing geometry, what 'targets' means, or what happens if the required parameter is missing. The terse description leaves significant ambiguity for an agent.

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

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

The description is a single, dense sentence that front-loads the core action ('Measure geometry') and then conveys the parameter dependencies efficiently. Every part earns its place, but the compact format could be slightly improved with clearer separation of the measurement modes.

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

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

The tool has three parameters, one required, and no annotations. The output schema exists but is not shown, so the description need not cover return values. However, it fails to explain target references, side effects, error conditions, or how the tool relates to the current scene, leaving it incomplete for nuanced usage.

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 adds the allowed values for 'what' and the dependency between 'what' and the other parameters, which is meaningful. However, it does not explain the coordinate format for 'points' or what 'targets' refer to (object names, IDs, etc.), leaving gaps that the schema does not fill.

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

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

The description clearly states the tool measures geometry and enumerates specific measurement types (distance, length, area, volume, bbox, centroid). This verb+resource pairing is distinct and establishes a clear purpose separate from sibling tools that create, transform, or select geometry.

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

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

The description provides clear usage context by specifying which parameter is needed for each measurement type ('distance' needs points; others need targets). While it doesn't explicitly exclude alternatives or say 'use this when you need X', the mapping of parameter dependencies gives practical guidance on how to invoke it correctly.

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 non-execution, that existing drafts and geometry are preserved, and the post-call user workflow (edit/preview/Keep/Discard). It omits permission or failure-mode details, keeping 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?

Three short sentences, front-loaded with the action and its key constraint, with no redundant restatement of the name. The namespace and workflow lines are borderline but earn their place by adding context.

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

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

An output schema exists, so return values need not be explained, and the description covers side effects, workflow, and execution semantics. The remaining gap is argument documentation, which is minor given the otherwise complete behavioral picture.

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

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

Schema description coverage is 0% for two parameters, so the description must compensate. It explains runtime namespaces (doc, geo, selected) but says nothing about the required 'source' parameter or the 'title' default, leaving the actual arguments 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 first sentence gives a specific verb and resource ('Open Python in a new editable Script draft') plus an explicit boundary ('without executing it'). It implicitly distinguishes itself from execution-oriented siblings like serp_command, though it never names a sibling directly.

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 workflow sentence ('user can edit the draft, Run to preview, then Keep or Discard') implies when this tool fits: staging a script for review rather than running it. However, no explicit when-to-use vs. alternative guidance or prerequisites are stated for the sibling set.

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

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

No annotations exist, so the description must carry the full burden; 'Get' implies a safe read but read-only semantics and cost on large scenes are never stated. It does add real context by disclosing that user_text keys/values are included and that mutation belongs to the setusertext command.

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

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

Two sentences, front-loaded with the verb and resource, with the payload contents listed immediately. The nested parenthetical is dense but every clause carries information; 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?

An output schema exists, so return structure need not be repeated, and the description nonetheless summarizes the returned categories. It stops short of noting preconditions (an open document) or whether results are expensive to gather, which is the only remaining gap for a zero-argument read 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?

Zero parameters, so the baseline is 4 by rule. The description still adds meaning by explaining where the returned user_text values originate (from setusertext), which is beyond any schema field.

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 ('Get') and resource ('the current scene') and enumerates the returned contents (objects, layers, selection, bounds, display mode). It does not explicitly differentiate from the overlapping sibling serp_layers or serp_select, which keeps it at 4 rather than 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?

Usage is implied (inspect scene state before acting) but never stated as a when-to-use rule, and the exclusion is only partial: 'Set user text with the setusertext command' routes mutation away, but nothing tells the agent when to prefer serp_layers or serp_select over this.

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 of behavioral disclosure. It clearly states the action (capture the current 3D viewport) and the return type (PNG image). Since this is a non-destructive capture, no warnings about side effects are necessary, but it could mention that it uses the active camera/viewpoint.

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 consists of two short sentences. The first sentence conveys the core function and purpose, and the second adds a usage hint. Every word earns its place; no redundancy or filler.

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

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

For a simple screenshot tool with one optional parameter and no output schema, the description is largely complete: it states what is captured, the return format, and when to use it. The only gap is that it does not explicitly mention the width parameter or clarify that it captures the current viewport state (camera, layers, etc.), but overall it provides enough context for an agent to invoke it 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 schema has one parameter (width) with 0% description coverage, and the description never mentions width or its meaning. The parameter name is somewhat self-explanatory, but the description does not compensate for the low schema coverage or clarify how width affects the output (e.g., pixels, aspect ratio).

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

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

The description uses a specific verb ('capture') and resource ('current 3D viewport'), clearly distinguishing it from sibling tools like serp_scene_info or serp_viewport. It also states the purpose ('so you can see the model'), making it immediately obvious what the tool does.

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 explicitly recommends using this tool after making changes to check the result, giving a clear use case. However, it does not mention when not to use it or name alternatives (e.g., serp_viewport for viewport control), so it lacks explicit 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 provided, the description carries the burden of behavioral disclosure. It successfully communicates selection-mode semantics and the special behavior of 'clear'. It could go further by explaining whether criteria combine with AND/OR, but the core behavioral traits are adequately 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?

The description is compact and front-loaded: the first sentence states the primary action and criteria, and the second sentence provides essential mode information. Every phrase adds value without redundancy.

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

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

The tool has four optional parameters, no annotations, and an output schema is present, so return values need not be explained. The description covers all parameters and key behaviors, though it leaves some edge cases (e.g., whether multiple criteria are combined) undocumented. Overall, it is sufficiently complete for a selection 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 property descriptions are absent (0% coverage), so the description must add meaning. It compensates well by explaining the meaning of 'kind' with the allowed values (curve/surface/solid) and clarifying mode behavior. It does not define the exact expected format for 'names' or the default behavior when 'mode' is omitted, but the overall parameter semantics are much clearer thanks to the description.

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

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

The description clearly states the action ('Select objects') and the criteria (names, kind, layer), which makes the tool's purpose immediately understandable. It is distinct from sibling tools like serp_create_curve or serp_boolean, focusing specifically on selection.

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 explains the mode parameter ('replace', 'add', 'clear') and highlights the non-obvious behavior that 'clear ignores other args', which is directly useful for invoking the tool. It does not explicitly name alternative tools or exclusions, but no sibling tool is a selection tool, so the intended usage context is clear.

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 of behavioral disclosure. It only lists parameter syntax and does not reveal side effects such as whether 'move' mutates the original, whether 'copy' creates new objects, or the exact semantics of 'keep_original' in mirror. This is a significant gap for a mutation tool.

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

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

The description is compact and structured as a syntax reference, with no verbose fluff. The multiline operation/params listing is efficient, though it could be slightly clearer with examples or expanded explanations for each operation.

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

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

The tool has an output schema, so return values need not be described. All five operations and their parameters are documented, making the description sufficient for most selection and invocation needs. However, the lack of behavioral context (side effects, safety) prevents a perfect score.

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

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

The schema only provides a generic 'params' object with no internal structure. The description fully specifies the parameter layout for each operation, including defaults (e.g., axis defaults to Z) and parameter formats (offset, center, factor, plane_point). It also clarifies that targets are object names. This adds substantial meaning 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 clearly states 'Transform objects (by name)' and enumerates five specific operations (move, copy, rotate, scale, mirror), distinguishing it from sibling tools like boolean, create, or measure. The verb+resource is clear and specific.

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 makes the tool's scope obvious (any transformation operation) and implies when to use it. However, it does not explicitly discuss alternatives or scenarios where another tool would be preferred, so it falls short of a full 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 provided, the description carries the full burden of disclosure. It indicates undo/redo are state-changing operations but does not mention potential side effects, such as whether undone operations can be recovered, whether the undo history is limited, or whether it affects only certain object types. This is a significant gap for a mutation tool.

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

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

The description is a single sentence that conveys the core functionality and the optional parameter in a compact, front-loaded manner. Every word contributes meaning, with no unnecessary elaboration.

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

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

For a simple one-parameter tool with an output schema, the description is largely sufficient. It covers the main behavior and parameter semantics. However, it omits caveats like the scope of 'last operation' (e.g., across all scenes or within current scene), which could be relevant in a complex 3D environment.

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

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

The schema only defines `redo` as a boolean with a default, but the description explicitly explains its meaning: setting `redo=true` triggers redo instead of undo. This directly adds semantic value beyond the raw schema, making the parameter's effect completely clear.

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

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

The description clearly states the tool's function: undoing the last operation, with an explicit mention of the redo capability via the `redo` parameter. It is distinct from sibling tools, which focus on creation, measurement, transformation, etc., so there is no ambiguity about what this tool does.

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 usage (i.e., after performing an operation to reverse it), but it does not explicitly state when to use it vs. alternatives, nor does it mention any prerequisites or exclusions. For a standard undo/redo tool, this is acceptable but lacks explicit 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the zoom_extents effect and lists parameter options, but does not disclose whether the viewport change impacts the active view persistently or requires an open scene. This is adequate for a simple view control but lacks deeper behavioral context.

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

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

The description is compact and information-dense, with each parameter listed along with its valid options in a single sentence. There is zero filler—every word contributes to understanding the 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?

Given the tool's simplicity, the presence of an output schema, and full parameter documentation, the description is largely complete. It lacks mention of prerequisites (e.g., active viewport) and side effects, but for a viewport adjustment tool this is likely sufficient. A slightly more complete description would note that changes affect the current view only.

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 input schema has no descriptions (0% coverage), so the description fully compensates by documenting each parameter: view lists all valid orientations, display_mode lists valid visual styles, and zoom_extents explains its behavior. This is comprehensive for a 3-parameter tool and adds significant meaning 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 explicitly states the tool's function ('Adjust the viewport') and enumerates all view orientations and display modes, making its purpose unambiguous. It clearly distinguishes itself from sibling tools by focusing solely on viewport manipulation.

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 usage (adjusting the viewport) but provides no explicit when-to-use or alternative guidance. It does not mention when to prefer this over other scene tools, though the intent is clear from the name and context.

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