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

With no annotations, the description carries the behavioral transparency burden. It explicitly discloses that the target is replaced in place, which is a critical side effect. It does not mention other behaviors like persistence or error conditions, but the core destructive action is covered.

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 action, and no filler. The side effect is stated immediately after the action.

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

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

The description is sufficient for a simple two-parameter mutation tool. It explains what happens to the target and that the reference is untouched (via schema), and no output schema exists. It could mention prerequisites like open images, but that is not essential given the schema descriptions.

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?

Both parameters are fully described in the input schema (target_id, reference_id) with 100% coverage. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ('align'), the resource ('target image to a reference image'), and the method ('StarAlignment'). No sibling tool performs alignment, so it is well-differentiated.

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 use when the agent wants to geometrically align one view to another, but it does not explicitly state conditions or alternatives. No exclusions or when-not-to-use guidance is provided.

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 must carry the behavioral disclosure burden. It does explain what the mask does to processing (protect black, allow white) and how inverted changes it, which is valuable. However, it does not disclose whether applying a mask replaces an existing mask, whether it is reversible, or what side effects occur on the target view.

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 with no fluff. The primary action and semantics are front-loaded, and the inverted guidance is a natural follow-up. Every sentence earns its place.

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

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

The description is sufficient for a simple masking operation: it explains what the mask does, how the target view is affected, and how to invert. It does not mention how this interacts with downstream processing tools, but the phrase 'allows processing where it is white' implies the intended workflow. Given no output schema and a simple parameter set, this is nearly complete.

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

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

The input schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds meaning by clarifying the mask value semantics (0=black protects, 1=white allows) and explicitly linking inverted=true to flipping this behavior, which goes beyond the schema text.

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 verb and resource: applying a mask to a target view, and it explains the mask's semantics (black protects, white allows processing). It does not explicitly name a sibling alternative like remove_mask, but the core action is unambiguous enough to distinguish it from create/remove/close mask tools.

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 tool is used to restrict processing on a view, but it gives no explicit when-to-use or when-not-to-use guidance. It mentions inverted=true, a parameter directive, but does not describe when to prefer this over related tools such as remove_mask or create_luminance_mask.

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 thoroughly. It discloses the exact formula (sigma = 1.4826 × MAD), per-channel vs linked behavior, inversion handling, clamping behavior, defaults, and failure mode ('Fails, changing nothing, when the clipping point leaves no range'). This is exemplary behavioral disclosure.

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

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

The description is dense and information-rich, with every sentence contributing algorithmic detail. It is front-loaded with the main action and then details the math. It is longer than ideal, but the complexity of the algorithm justifies the length. No wasted words, though the MTF formula could be seen as heavy for a tool description.

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 (4 params, no output schema, no annotations), the description is remarkably complete. It covers the algorithm, parameter semantics, edge cases (sigma 0, inverted channels, linked mode), defaults, and failure behavior. An agent has everything needed to invoke it correctly and predict outcomes.

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 100%, so the baseline is 3. The description adds significant meaning beyond the schema: it explains how shadows_clipping and target_bg are used in the MTF formula, how linked affects the computation, and the exact role of each parameter. It doesn't explicitly restate each parameter's type/default, but the schema already covers that. The added algorithmic context elevates it above baseline.

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 ('Stretch a view in place') and resource (PixInsight's auto-stretch via ScreenTransferFunction/HistogramTransformation), and distinguishes it from generic stretch tools by specifying the exact algorithm. It clearly identifies what the tool does and how it differs from siblings like robust_median_stretch or stretch_stars.

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 algorithm and defaults, and the schema notes 'linked' is ignored for mono images. It does not explicitly state when to use this tool versus alternatives like robust_median_stretch or stretch_stars, but the detailed algorithm description implies its use case (PixInsight auto-stretch). Clear context is provided, but no explicit exclusions or alternative routing.

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 only states the action and that the clone can be restored, but does not disclose whether the original is modified, whether clone_id must be unique, whether the image must be open, or what the clone contains (full snapshot vs reference). This is insufficient for safe invocation.

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

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

One sentence with no wasted words. The action is front-loaded, and the reference to restore_from_clone is scannable and relevant. It is concise without sacrificing the core message.

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 supply enough context for correct use. It does not mention prerequisites (e.g., open image), uniqueness expectations for clone_id, or the nature of the backup (snapshot vs live copy). The tool creates a resource, so more behavioral detail is needed; the description is incomplete for a safe call.

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

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

Schema description coverage is 100%, so the schema already defines both parameters ('Source view ID' and 'Name for the clone'). The description adds no additional parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Clone') and resource ('image to a backup view'), and explicitly references the complementary operation restore_from_clone. This distinguishes it clearly from sibling tools like copy_astrometric_solution or align_to_reference, leaving no ambiguity about what it 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 implies a clear usage context: create a backup view that can be restored later, and names the restore counterpart. However, it does not explicitly state when to use this versus alternatives (e.g., before destructive edits) or mention any exclusions, so some inference is still required.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the outcome ('free memory') but does not mention whether closing is irreversible, whether unsaved changes are affected, or any side effects on related views, clones, or masks.

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

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

A single front-loaded sentence with no filler. Every word contributes meaning: the action, the target resource, and the purpose are all present.

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 one-parameter tool, the description is close to sufficient. However, since there are no annotations and no output schema, a note on how to obtain view_id (e.g., via list_open_images) or the irreversible nature of closing would improve completeness.

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

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

The schema fully documents view_id with 'View ID to close', so the parameter meaning is already clear. The description adds a slight mapping between 'image window' and view_id, but no extra format, source, or usage nuance 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 states a specific verb ('Close'), a clear resource ('image window'), and a rationale ('to free memory'). It is immediately distinguishable from sibling tools like close_mask and open_image.

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 when to use the tool: when an image window should be closed to release memory. However, it provides no explicit guidance about alternatives, such as using close_mask for masks, or what not to use this tool for.

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 behavioral burden. It discloses that the operation is destructive ('delete') and why it exists (free memory), which covers the key trait. However, it omits details like irreversibility, potential errors for invalid mask_id, or any effect on the underlying image, leaving some unknowns.

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

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

A single 10-word sentence that is front-loaded with the primary action and resource, immediately followed by the purpose. Every word earns its place; there is no redundant terminology 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 one-parameter tool with full schema coverage and no output schema, the description provides everything an agent needs to invoke it correctly: what action to take, on what resource, and why. The only minor gap is absence of a note on side effects beyond memory usage, but that does not hinder correct 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 100% — 'mask_id' is already documented as 'Mask view ID to close'. The description's mention of 'mask window' aligns with the schema but adds no new semantic detail beyond what the input schema already provides, hence the baseline score.

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 explicit action verbs 'close and delete' with a specific resource ('mask window') and even states the purpose ('to free memory'). This clearly differentiates it from siblings like remove_mask or close_image, making the tool's unique role 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 phrase 'to free memory' implies a usage context (when the mask window is no longer needed and resources should be released), but the description does not explicitly state when to choose this tool over alternatives such as close_image or remove_mask, nor does it provide exclusions.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses the dimension precondition and the return value, but doesn't state whether the input views are modified or destroyed, or whether the operation is reversible. It implies creation of a new view (via 'renamed to'), but doesn't explicitly confirm the inputs are untouched. This is minimal but not misleading.

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 three short sentences, front-loaded with the purpose, then the constraint, then the return value. There is no fluff or redundant information. Every sentence earns its place.

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

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

Given the simplicity of the tool (4 required params, no output schema, no annotations), the description covers the essential points: purpose, constraint, and return. It doesn't mention error conditions or side effects, but those are implied by the dimension constraint. Compared to the calibration example for update_drive (which lacked permissions and reversibility), this is more complete because it gives the return and the key precondition. It's sufficient for an agent to call 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 covers all parameters with descriptions (100% coverage), but the tool description adds a cross-parameter constraint: all three view IDs must have identical dimensions. This is not in the schema and adds meaning beyond what the schema provides. The description also clarifies the return value, which relates to the output_id parameter. So it adds value 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 states a specific verb (Combine), the resource (3 mono views), the result (single RGB color image), and the method (ChannelCombination). It also names the return value. This clearly distinguishes it from siblings like lrgb_combine, which combines luminance with color, and create_luminance_mask, which does something different.

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 tool is used when you have three mono views of identical dimensions and want to combine them into RGB. It doesn't explicitly mention alternatives or exclusions, but the purpose is clear enough that an agent would know when to select it. However, it doesn't say 'use this instead of lrgb_combine' or 'not for combining luminance', so it's not fully explicit.

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 fully pays it: it reveals in-place mutation, Rec.709 luminance weighting, Gaussian blur normalization, the exact knee formula, both mode equations, per-channel application, and final truncation to [0,1].

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 main intent is front-loaded, and the remaining sentences are dense with necessary mathematical detail rather than filler. Despite its length, it is an efficient specification for a complex 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 algorithmic behavior and all seven parameters are covered, and in-place modification makes a return-value description less important. The formula, modes, parameter roles, and side effects are self-contained enough for an agent to invoke the tool 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?

Although schema coverage is 100%, the description adds substantial parameter meaning: it maps min_clamp/max_clamp to the knee endpoints, explains blur_sigma's role in the mask, and defines how rate and headroom shape the soft-mode curve. This goes well beyond the short schema descriptions.

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 and resource: it compresses bright values in place above a per-pixel knee. The detailed luminance/blur/knee formula further distinguishes this from generic curve/clamp siblings, so an agent can tell exactly what it 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 gives no when-to-use guidance or alternatives. It never says when continuous_clamp should be chosen over run_curves, run_pixelmath, or auto_stretch, and it does not mention prerequisites or excluded 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?

No annotations are provided, so the description carries the full burden, and it does well: it discloses in-place mutation, the exact mathematical operation, 64-bit PixelMath execution, truncation to [0,1], and the reported median and max. It does not cover failure modes, but core behavior is clearly visible.

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 dense sentences capture the operation, the exact formula, the processing mode, and the result reporting. There is no filler, and the action is front-loaded.

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

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

Given no annotations and no output schema, the description provides enough operational detail to invoke the tool: the in-place target, the source channel, the factor semantics, numeric clamping, and the reported outputs. It omits explicit error cases and alternative-selection guidance, but is otherwise complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the meaning of continuum_factor and the roles of ha_id and rgb_id through the formula, but adds little beyond what the schema already states.

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

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

States a precise verb and resource: subtract the scaled R channel from an Ha view, in place. The explicit formula Ha = max(0, Ha - continuum_factor * R) makes the operation unambiguous and distinguishes it from related narrowband tools like ha_inject_red.

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 no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. With a large sibling set containing similar narrowband operations, an agent gets no routing help beyond inferring from the formula.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses that the target's pixels are unchanged and that dimensions must match, which is useful. However, it doesn't state whether the target's existing WCS is overwritten, whether observation keywords are merged or replaced, or whether the source file must be open. These are meaningful behavioral gaps for a metadata-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?

Two sentences, no filler. The core action is front-loaded, the constraint is stated, and the non-destructive nature is clarified. Every sentence earns its place.

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

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

For a 2-parameter tool with full schema coverage, the description is mostly complete. The main gaps are behavioral: overwrite semantics for existing WCS/keywords and whether the source must be an open image or just a file path. These are relevant for an agent deciding whether to call this tool and what to expect afterward.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds the relationship between them (source carries the WCS, target receives it) and the dimension constraint, but doesn't add format or path details beyond the schema. Baseline 3 is appropriate.

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 ('Copy'), a specific resource ('astrometric solution (WCS) and observation keywords'), and the source/target relationship. It also clarifies what is NOT copied ('the target's pixels are unchanged'), which distinguishes it from image-copying tools like clone_image or crop_image.

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 precondition ('Source and target must have the same dimensions') and implies the use case: transferring WCS/observation metadata from a file to a view. It doesn't explicitly name alternatives like run_plate_solve, but the sibling list shows plate solving is the alternative for creating a WCS, while this tool copies an existing one. The context is clear enough for an agent to select 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, the description carries the full burden and does so thoroughly. It discloses the exact mathematical thresholds (median + 5 MAD, percentile 85 + 10 * core_bias), the sampling circle radius, feathering and blur parameters, the fact that it replaces existing views of those names, and the error condition (fewer than 50 sampled subject pixels). This is exemplary behavioral disclosure.

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

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

The description is dense and information-rich, with every sentence contributing a specific algorithmic detail. It is front-loaded with the core purpose and then details the mask construction. It could be slightly more structured (e.g., separating the error condition), but it is appropriately sized for the complexity.

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 (three masks, multiple thresholds, blur, view replacement), the description is remarkably complete. It covers inputs, algorithm, outputs, side effects (replacing views), and error conditions. No output schema exists, but the description fully explains what the tool creates, so nothing critical is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining how core_bias shifts the core threshold on the percentile scale (0 = percentile 85, 1 = percentile 95) and how view_id is the source for the masks. It doesn't restate the schema but enriches it with the algorithm's context.

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 ('Create') and resource ('three masks from percentiles of the image's own luminance'), and names the exact output views (azone_core, azone_shell, azone_outer). It clearly distinguishes itself from the sibling create_zone_masks by specifying the adaptive, luminance-based algorithm and the three named outputs.

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 when to use this tool: when you need adaptive zone masks based on the image's own luminance distribution. It does not explicitly state when not to use it or name alternatives like create_zone_masks, but the detailed algorithm and output names make the usage context clear. A brief exclusion note would push it to 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?

No annotations are provided, so the description must carry the burden. It discloses the mathematical operation and optional processing steps (blur and shadow clip), which is useful. However, it doesn't mention that this creates a new mask view (mutation), potential side effects on existing masks, or whether the operation is reversible. Basic behavioral context is present but not comprehensive.

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

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

One sentence that packs the core formula, optional processing, and the purpose. It is efficient and begins with the primary action. Could arguably be split for readability, but it's not verbose.

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, no output schema, and no annotations, the description is reasonably complete for a creation tool. It explains the main calculation and optional post-processing, but lacks details on what happens to existing masks, potential required prerequisites (e.g., a color view must be open), and clear usage context. It's sufficient 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 100%, so parameters are already documented. The description adds formula details (Y = 0.2126R + 0.7152G + 0.0722B) and mentions blur and shadow clip, which map to blur and clip_low parameters. But it doesn't explain the gamma parameter or how the shadow clip threshold is applied beyond the schema's description. Baseline 3 is appropriate since schema covers most semantics.

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

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

States a specific verb, resource (luminance mask), and the underlying math formula, plus optional blur and shadow clip. It distinguishes from create_zone_masks and create_adaptive_zone_masks by implying a luminance-based mask rather than zone masks, though it doesn't explicitly name the difference.

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

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

No guidance on when to use this tool versus alternatives like create_adaptive_zone_masks or create_synthetic_luminance. The description implies a use case (creating a luminance mask from a color view) but doesn't state when it's preferred or when to avoid 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, the description carries the full behavioral burden. It discloses the exact calculation, the replacement of an existing view of the same name, the optional max_value cap, truncation to [0,1], and the reported median/max statistics. This is substantive but stops short of describing edge cases 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?

The description is compact and front-loaded: the first sentence states the purpose and formula, and the second covers capping, truncation, and output reporting. Every sentence contributes meaningful information 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?

For a 6-parameter tool with no output schema, the description covers the core formula, optional cap, truncation behavior, view replacement, default naming, and returned statistics. It is nearly complete; only minor details like handling of invalid dimensions or negative weights are absent, but these are inferable from the schema.

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 100%, so the baseline is 3, but the description adds real meaning by explaining how ha_weight and oiii_weight combine, how max_value caps the result, and the default output name. This goes beyond the schema's field-level descriptions.

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 creates a mono view from a weighted sum of Ha and OIII, with a precise formula. It does not explicitly compare itself to sibling tools such as lrgb_combine or pixelmath_new_image, so it lacks explicit sibling differentiation.

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 no guidance on when to use this tool versus alternatives like lrgb_combine, pixelmath_new_image, or other view-creation tools. The intended use is only implied by the formula and the tool name, not stated explicitly.

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 goes well beyond the schema by explaining how masks are computed, that they are linearly ramped and Gaussian-blurred with specific sigmas, and that views mask_core, mask_shell, and mask_halo are created and replaced. This is unusually transparent about side effects.

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

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

The description is dense but efficient: the first sentence states the core action, the second provides the algorithm details, and the final sentence states the required constraint. Every clause contributes useful information with no filler.

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

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

For a tool with no output schema and no annotations, the description is remarkably complete. It names the output views, describes the computation, discloses the replacement behavior, and mandates the threshold ordering. An agent has enough 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?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the parameter meanings by mapping each clip threshold to its band, but it does not add substantial new meaning beyond the schema's own parameter descriptions.

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 leads with a specific verb and resource: 'Create core, shell and halo masks from three fixed luminance thresholds.' It clearly distinguishes this tool from sibling tools like create_adaptive_zone_masks by emphasizing 'fixed' thresholds and naming the exact masks produced.

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 operational context: it defines the three threshold bands, the linear ramp, the Gaussian blur sigmas, and the required ordering halo_clip < shell_clip < core_clip < 1. It does not explicitly name alternatives or state when not to use it, but the 'fixed thresholds' phrasing implies the contrast with an adaptive sibling.

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?

The description discloses a critical behavioral trait: 'in place', meaning the original image is modified. With no annotations provided, this is valuable. However, it doesn't mention whether the operation is reversible, whether it affects clones, or what happens if crop amounts exceed image dimensions.

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 with zero waste. The core action, the in-place behavior, and the parameter semantics are all front-loaded. Every word earns its place.

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

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

For a simple 5-parameter tool with 100% schema coverage, the description is mostly complete. The main gap is the lack of behavioral details around edge cases (e.g., cropping more pixels than the image has) and whether the operation can be undone. No output schema exists, so return value behavior is not disclosed.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds the crucial context that amounts are 'pixels to remove from each side', which reinforces the schema descriptions but doesn't add new information beyond them.

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 ('Crop'), a resource ('an image'), and the key behavior ('in place'), which clearly distinguishes it from sibling tools like clone_image or get_image_dimensions. It doesn't explicitly name a sibling alternative, but the 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?

The description implies when to use it: when you need to remove pixels from image edges. It doesn't explicitly state when not to use it or mention alternatives like clone_image for non-destructive cropping, but the context is reasonably clear for a simple operation.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It conveys that the tool is introspective ('Describe... whether it can run...') and lists what data is inspected, which implies a read-only operation. However, it never explicitly states that it does not execute or modify the process, and it does not describe error behavior for unknown constructor names.

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 filler. The core action and scoping ('Describe one PixInsight process by its PJSR constructor name') are front-loaded, and every subsequent clause adds a distinct piece of expected output.

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 one-parameter introspection tool with no output schema, the description does a good job enumerating what will be returned: view/global execution capability, parameter values/types, and named constants. It would be more complete if it stated the result format or behavior for invalid/unavailable process names, but an agent can still call the tool correctly from this description.

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

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

Schema description coverage is 100%, so the schema already defines 'name' as a PJSR process constructor name. The description repeats this and adds only a concrete example ('SCNR') and a link to the returned information, which is helpful but not substantial new semantic content.

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

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

The description uses a specific verb, 'Describe', and a specific resource, 'one PixInsight process by its PJSR constructor name'. It enumerates the exact information returned (view/global run capability, parameter values/types, numeric constants), which clearly differentiates it from execution-oriented siblings like run_process or enumeration-oriented list_processes.

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 usage guidance is given. The description does not say when to prefer describe_process over list_processes, run_process, or run_pjsr, nor does it mention any prerequisites or common scenarios such as inspecting a process before running it. The agent is left to infer the tool's role from its name and output description.

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

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

With no annotations, the description fully carries the transparency burden and succeeds: it discloses that the target is modified in place, the mask is temporary and removed afterward, the computation runs in 64-bit PixelMath truncated to [0,1], and it reports median and channel maxima. This is exactly the kind of behavioral context an agent needs.

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

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

The description is dense but every sentence earns its place: summary, explicit channel formulas, soft-clamp behavior, mask construction, mask removal, numeric precision, and output reporting. No filler, no redundancy, and the most important behavioral facts come first.

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

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

For an 11-required-parameter tool with no annotations and no output schema, this description is remarkably complete. It fully specifies the algorithm, the mask lifecycle, the numeric domain, and the reported output values, leaving no critical ambiguity for an agent deciding whether and how to invoke it.

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

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

Although schema coverage is 100%, the description significantly enriches parameter meaning by embedding each parameter in the actual equations (e.g., g_ha_fraction's role in the G term, rolloff as the fraction of excess kept, mask_blur as Gaussian sigma). This bridges the gap between telling an agent what a parameter is and how it behaves.

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 precise statement: 'Add Ha and OIII (mono views) to an RGB view in place, through a temporary luminance mask.' This names the specific operation, resources, and mechanism, and is clearly distinguishable from siblings like ha_inject_red or lrgb_combine.

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 detailed math and mask behavior make the intended use context unambiguous: this is the tool for a dynamic Ha+OIII blend into RGB with a luminance mask. However, it does not explicitly compare itself to alternatives (e.g., ha_inject_red, synthetic luminance) or state when not to use it, so it falls 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 present, the description carries the full burden of disclosing side effects and constraints. It explicitly says the working image is not changed, missing parent folders are created, paths outside allowed regions are refused, and bit-depth defaults vary by format. This is unusually transparent for a tool definition.

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 tight, front-loaded with the core purpose, and every sentence provides distinct value. It moves from the main action to path rules, format mapping, bit-depth defaults, and side effects without repetition 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?

The description covers path safety, supported formats, bit-depth behavior, and non-mutation of the working image, which is enough to invoke the tool correctly. It does not mention overwrite behavior or what happens on unsupported extensions or failures, and there is no output schema, so a small completeness gap remains.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains how relative file_path is resolved, what absolute paths are permitted, how the extension selects the format, and what bit-depth behavior applies per format. This far exceeds the baseline expected when the schema already documents each parameter.

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 concrete verb and resource: 'Write an image to a file in the workspace's output or state folder.' It clearly identifies the tool's purpose and even scopes where output may be written)Skip. It does not explicitly distinguish itself from sibling save_preview/save_and_show_preview tools, so it falls short of a full 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 gives detailed path and format constraints but never states when to choose this tool over alternatives such as save_preview or save_and_show_preview. There is no when-to-use / when-not-to-use guidance, so an agent must infer usage from the name and general purpose.

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 behavioral disclosure burden. It transparently warns that any existing view of the target name is replaced, explains the clipping behavior, and states that median and max are reported. It does not state whether the source view remains untouched, but the creation semantics imply it.

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: the first states the action, the second gives the formula and destruction warning, and the third states what is returned. There is no filler and no unnecessary restatement of the schema.

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

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

For a tool with no output schema and no annotations, the description provides the algorithm, the destructive side effect, and the returned statistics. The only missing context is a prerequisite that the source view be a valid RGB view, which is lightly implied by the schema parameter description.

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 100%, so the baseline is 3. The description adds meaning by tying continuum_factor to the formula, clarifying output_id replacement when the view already exists, and explaining that the result is mono and clipped, which goes beyond the raw parameter names.

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

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

The description names a specific operation ('Create a mono view'), gives the exact formula (max(0, B - continuum_factor * R)), and states the output type. It does not explicitly differentiate from siblings like continuum_subtract_ha, but the B-minus-scaled-R formula makes the intent clear.

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

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

The description gives a clear algorithm and result, so the use case (extracting pseudo-OIII from an RGB view) is inferable. It does not, however, state when to prefer this over sibling tools such as continuum_subtract_ha or dynamic_narrowband_blend, so explicit routing guidance is missing.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses ordering semantics (exact, then substring, then grouped-name matches), case-insensitivity, and the grouped-name expansion behavior. It also notes that sensor QE curves have channel Q, which is a useful behavioral detail. It does not mention pagination or result limits, but for a search tool this is reasonably transparent.

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 sentences, each dense with useful information: matching semantics, ordering, grouped-name behavior, downstream usage, and the Q channel note. No filler or repetition of schema content.

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 2-parameter search tool with no output schema, the description covers matching, ordering, and downstream usage. It does not describe the result format (e.g., what fields are returned per match), but the description's stated purpose is to pick exact names, and the ordering semantics are sufficient for that. Minor gap, but overall complete enough.

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

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

Schema description coverage is 100%, so the schema already documents both parameters with examples. The description adds the grouped-name matching behavior and the Q channel note, which enriches the 'query' and 'channel' semantics respectively. However, it does not add much beyond the schema's examples, so a baseline 3 is appropriate.

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 ('Search'), a specific resource ('PixInsight's built-in filter and camera QE database'), and the matching semantics (case-insensitive substring, grouped-name expansion). It also names the downstream consumers (run_spfc/run_spcc), which distinguishes it from the many measurement/process tools in the sibling list.

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 explicitly says to use it to pick exact names for run_spfc or run_spcc, which gives a clear when-to-use context. It does not explicitly state when not to use it or name an alternative lookup tool, but among the siblings there is no obvious competing search tool, so the guidance is adequate.

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?

There are no annotations, so the description carries the behavioral burden. The verb 'Get' signals a read-only operation, and the output scope is clear, but the description does not disclose behavior for missing/invalid view IDs, whether multiple views are validated independently, or what 'color status' precisely means. For a simple getter this is acceptable but not richly transparent.

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 two sentences, front-loads the main function, and then adds a single high-value domain constraint. Every sentence earns its place; there is no fluff or repetition of the schema.

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 single-parameter read-only tool with no output schema, the description is largely sufficient: it states the resource, scope, and an important use condition. It could mention error behavior or return shape, but those are minor for this simple API.

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

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

Schema description coverage is 100% for the only parameter, view_ids, with the schema already saying 'View IDs to check.' The description adds that it works for 'one or more views' and connects the parameter to the ChannelCombination precondition, but it does not add significant format or semantics 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 uses a specific verb and resource: 'Get dimensions, channel count, and color status for one or more views.' This clearly identifies what the tool returns and is distinct from sibling tools like combine_channels or get_image_stats, so an agent can select it accurately without open the 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?

It gives a concrete usage context: 'Every channel must have identical dimensions before ChannelCombination,' which implies this tool is the right precondition check before combine_channels. It does not explicitly name alternatives or say when not to use it, so it stops short of full routing 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 must disclose behavioral traits itself. It does not state that the operation is read-only or non-destructive, nor does it describe the return format, error behavior, or any side effects. The description only lists the statistics, leaving the agent uncertain about what to expect.

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

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

The description is a single, compact sentence that front-loads the operation ('Get image statistics') and then lists the specific statistics. There is no unnecessary verbiage, making it easy to parse and act on.

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

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

For a simple getter with one parameter and no output schema, the description is moderately complete. It lists the statistics but does not indicate the return structure (e.g., JSON object, array), nor does it clarify that the operation is read-only. While not severely deficient, an agent might need more context to fully anticipate the tool's behavior.

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 100%, so the schema already documents view_id as a PixInsight view ID. The description adds no additional meaning about the parameter, such as how to obtain a valid view ID or whether it is optional. The baseline of 3 applies because the schema handles the 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?

The description clearly states the verb 'Get' and resource 'image statistics', and enumerates specific statistics (median, MAD, min, max, per-channel medians). This distinguishes it from sibling tools like get_image_dimensions, but it does not explicitly name any sibling or contrast with the many measure_* tools, so it misses the full differentiator.

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

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

No guidance is provided on when to use this tool versus alternatives such as measure_uniformity or measure_stars. There are no explicit conditions, exclusions, or recommended scenarios, leaving the agent to infer usage from the tool name alone.

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

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

With no annotations provided, the description carries the full burden, and it does well: it discloses in-place modification, the exact per-channel formula, 64-bit PixelMath execution, and truncation to [0,1]. It does not mention edge cases like no-op behavior when Ha never exceeds Y, but the core mutation behavior is transparent.

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 with the purpose, then gives the formula and execution detail. Every sentence carries meaningful information; 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?

For a three-parameter in-place transform with no output schema, the description is nearly complete: it defines the operation, the math, the precision, and the clipping behavior. A minor gap is that it does not state prerequisites like the target being an open RGB view or the result of the in-place operation, though these are partially implied by the schema.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters clearly. The description adds the formula context around 'strength' and the Rec.709 luminance definition, but it does not substantially enrich parameter 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 states a specific verb ('Raise the luminance'), a precise resource ('an RGB view'), and the exact condition ('where Ha exceeds it'). It distinguishes itself from sibling ha_inject_red by targeting luminance while preserving colour ratios, so an agent can tell them apart.

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

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

The description explains the mechanism but gives no explicit guidance on when to use this tool versus alternatives like ha_inject_red, extract_pseudo_oiii, or create_synthetic_luminance. Usage context is only implied by the mathematical behavior, not 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?

The description discloses that the operation modifies the target in place, runs as 64-bit PixelMath truncated to [0,1], and reports the new R maximum and image median/max. With no annotations provided, this is substantial behavioral disclosure. It could add side-effect warnings (e.g., irreversible modification) but the in-place mutation is already stated.

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 sentences, each dense with information: the core transformation, the optional clamp, and the execution/reporting behavior. No filler or repetition of schema content.

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 6-parameter mutation tool with no output schema and no annotations, the description covers the transformation, the optional clamp, the in-place behavior, and the reported outputs. It does not explicitly state prerequisites (e.g., matching dimensions, mono Ha view) but the schema already notes 'same dimensions' for ha_id. The main gap is lack of explicit warning about irreversibility, but the in-place statement covers the critical part.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds the formula context that ties the parameters together (e.g., how strength and brightness_limit interact), but it does not add per-parameter details beyond the schema. Baseline 3 is appropriate.

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 ('Add Ha to the red channel'), the resource (RGB view), the condition (where Ha exceeds R by a given fraction), and the exact transformation formula. It clearly distinguishes itself from the sibling ha_inject_luminance by targeting the red channel rather than luminance.

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 mathematical condition and the optional clamp behavior, giving an agent enough context to decide when to use it. It does not explicitly name alternatives or state when not to use it, but the precise formula and the sibling name ha_inject_luminance make the intended use case 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 disclosing side effects. It only states that the reference is not modified, but it never states that the target view is modified in place, what happens to rejection thresholds, or how failures are reported. This is a meaningful transparency gap for a process that likely mutates the input view.

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 two sentences with no wasted words. The primary action is stated first, and the important caveat about the reference view is included succinctly.

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?

This is a mutating process with no annotations and no output schema, so the description must do more. It omits whether the target view is changed in place, what the result of the operation is, and any guidance on how reject_low/reject_high affect the fit. The description is too sparse to fully support correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters and their defaults. The description adds only the conceptual purpose of view_id and reference_id ('match a reference view') but no additional format, interaction, or edge-case details, so the baseline 3 is appropriate.

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 names a specific process (LinearFit), states its action ('scale a linear image'), and identifies the target/reference relationship. It also distinguishes an important boundary ('The reference is not modified'). It does not explicitly differentiate from the similarly named sibling align_to_reference, but the 'scale' wording implies intensity matching.

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 a clear context for when to use the tool: when a linear image needs intensity scaling to match a reference view. However, it gives no when-not-to-use guidance and does not explicitly route away from sibling tools such as align_to_reference, leaving the comparison 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 burden of disclosing behavior. 'List' makes the read-only nature clear, and the description states what data is returned. It does not discuss empty states, ordering, or failure behavior, but these are minor for a simple inventory operation.

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 with no filler. It front-loads the action and resource, and every word contributes useful 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 zero-parameter, read-only list operation, the description is nearly complete: it identifies the resource and the returned attributes. It does not describe output serialization or edge-case behavior, but these are not necessary for correct invocation.

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

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

The input schema is empty, so there are no parameter semantics for the description to add. It correctly avoids inventing parameters, and the zero-parameter baseline of 4 applies.

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

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

The description states a specific verb and resource: 'List all currently open images in PixInsight'. It also specifies the returned data ('dimensions and color status'), and this distinguishes it from sibling tools like get_image_dimensions, which target a single image.

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 usage context is implied: use this tool when you need an inventory of open images. However, the description does not explicitly state when to prefer this over alternatives such as get_image_dimensions or workspace_info, and it gives no exclusions or routing 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 at all, the description carries the transparency burden and does so well: it explicitly declares 'Read-only' and notes that the listing reflects server startup discovery, implying a static snapshot rather than live state. It also pre-announces the diagnostic content (load status, why skipped), which sets expectations beyond the empty schema.

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 entire description is one well-structured sentence that front-loads the primary purpose, then adds the specific details in a parallel clause and closes with a one-word safety qualifier. Every segment earns its place and there is no filler.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description is sufficient: it specifies the full scope of returned information (status, counts, skip reasons, replacements) and the read-only nature. An agent can invoke and interpret the result without needing further clarification.

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

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

The tool has zero parameters and the input schema is an empty object with 100% schema description coverage, so the baseline for parameter semantics is 4. The description reinforces that no input is needed by focusing entirely on the returned information.

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

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

The description names the resource ('runtime tool packs discovered at server startup'), a specific action ('List'), and enumerates the exact information returned (load status, tool counts, skip reasons, replaced core tools). This clearly distinguishes it from sibling tools like list_processes or workspace_info, which target different resources.

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 intended context clear by scoping it to startup-discovered runtime tool packs, so an agent knows when it applies. However, it does not explicitly name alternatives such as list_processes or pixinsight_info or state when not to use this tool, leaving that distinction implicit.

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, and it explicitly discloses that the operation is read-only, that it classifies by prototype chain, and that it never instantiates a process. This goes beyond the basic 'list' phrasing and gives meaningful behavioral assurance.

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 two sentences: the first states the purpose and output, the second adds behavioral detail. There is no filler, and the most important information is front-loaded.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description is complete. It explains what is listed, the output format, examples, and the internal method, which gives an agent everything needed to invoke and interpret the tool correctly.

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

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

The tool has zero parameters and an empty input schema, so the description does not need to explain parameter meanings. The description adds useful context about what the returned names represent, which is sufficient for a no-parameter tool.

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 the exact action ('List every PixInsight process available on this installation') and the output format ('PJSR constructor name'), with concrete examples like 'SCNR' and 'PixelMath'. This clearly distinguishes it from sibling tools such as list_open_images or describe_process, which operate on different resources.

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 it clear that this tool is for enumerating all installed processes, which is a distinct use case. It does not explicitly name alternative tools or exclusion criteria, but the context and scope are clear enough for an agent to select it when needing the full process list.

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?

Despite no annotations, the description discloses key behaviors: in-place modification of the RGB view, the conditional LinearFit on the L view (with a modified-in-place note), the effect of lightness/saturation values (0.5 leaves unchanged), and that chrominance noise reduction and highlight clipping remain at defaults. This is thorough and goes beyond basic parameter descriptions.

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

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

The description is dense and well-structured, with each sentence adding new information. It front-loads the primary purpose, then clarifies channel behavior, parameter semantics, conditional logic, and defaults. No repetition or fluff; all parts contribute to understanding.

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

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

For a tool without an output schema, the description covers the operation, side effects, and parameter behavior thoroughly. However, it does not explicitly state what the tool returns or whether it returns a modified view or a status. Given its in-place nature, this is a minor gap, but with no output schema, a note on return behavior would make it fully complete.

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

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

While schema coverage is 100%, the description adds significant meaning beyond the schema. It explains the relationship of lightness and saturation to mL/mc, the neutral value 0.5, and provides a detailed explanation of the optional linear_fit_reject_high parameter (what it does, what it fits against, and the coefficient formula). This is invaluable for correct invocation.

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 ('Replace the lightness of an RGB view with a grayscale L view') and the specific process (LRGBCombination). It is unambiguous about the operation and distinguishes it from generic combine tools by describing the in-place modification and the L channel handling.

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 operation but does not explicitly state when to use this tool over alternatives. It mentions conditional behavior for the optional parameter, but no direct comparison to sibling tools (e.g., combine_channels, run_pixelmath). Usage context is implied through the detailed description.

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

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

With no annotations, the description carries the full disclosure burden, and it succeeds: it reveals the sampling scheme (every 8th pixel), the selection condition, the exact return JSON keys, and the mono-view error condition. This gives an agent a clear model of what will happen when the tool is invoked.

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 deliver the essential information with no filler: formula, pixel filtering, output shape, and error condition. The metric definition is front-loaded and the return format follows logically.

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?

Despite having no output schema, the description lists the exact JSON fields returned. Both required parameters are documented, the sampling behavior is specified, and the only obvious error case (mono view) is stated. For a simple read-only measurement tool with two parameters, this is complete.

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

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

The input schema already covers both parameters with 100% description coverage, so the baseline is 3. The description largely restates the schema's meaning for brightness_threshold and view_id, adding only the sampling behavior rather than new per-parameter semantics.

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

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

The description names a specific operation (measure chroma), a precise metric formula ((max - min) / max), a target population (bright pixels in a colour view), and an explicit sampling rule (every 8th pixel). This clearly differentiates it from sibling measurement tools and leaves no ambiguity about 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?

Usage is reasonably implied: call this when you need chroma statistics from bright pixels of a colour view, and the description explicitly warns that a mono view is an error. However, it does not compare against similar siblings such as measure_saturation or measure_uniformity, nor does it state when one should be chosen over another.

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 thoroughly. It discloses the sampling strategy (every 3rd pixel), the counting condition (luminance or any channel above level), the block_fraction threshold, and the exact JSON return format including the luminance formula. This provides an agent with full visibility into the tool's behavior and approximation nature.

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 paragraph that efficiently conveys the purpose, algorithm, and output. It is front-loaded with the core purpose and then details the method and return format. While not overly long, it packs a lot of information; it could be slightly more structured with bullets but remains readable and concise.

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 (tiling, sampling, threshold, output), the description covers all essential aspects: the algorithm, the parameters, the output schema (even without an output schema, it explains the JSON fields), and the luminance formula. An agent has everything needed to call this tool correctly and interpret results. No major gaps identified.

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 100%, so all parameters are described. The description adds significant value by explaining how parameters interact: block_size default (50), block_fraction as a 0-1 fraction, and the sampling rule that ties level to the counting condition. This goes beyond the schema's basic descriptions and clarifies the algorithm's dependency on these inputs.

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

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

The description clearly states a specific verb (count) and resource (image blocks above a level). It distinguishes from sibling measurement tools by specifying the exact counting method and output structure. An agent can immediately understand what this tool does and how it differs from measure_core_clipping or measure_uniformity.

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 internal algorithm and output but does not explicitly state when to use this tool versus alternatives. It implies usage for detecting clipped or bright regions but lacks guidance on when to prefer it over other measurement tools. There is no 'when not to use' or reference to siblings, leaving the agent to infer the best context.

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 full responsibility for behavioral disclosure. It thoroughly explains the algorithm: how the brightest block is found, how boxes are sampled (every 2nd pixel vs every pixel), that boxes are centered and clamped to the image, and the exact output fields including the luminance formula. It does not explicitly state it is read-only, but the measurement nature and lack of mutation verbs make this clear.

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

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

The description is dense and information-rich, with every sentence serving a purpose: defining the measurement, specifying the algorithm, and listing return values. It is not overly verbose, but the technical detail makes it slightly longer than the minimum; still well-organized and front-loaded with the core purpose.

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 measurement tool with only two parameters and no output schema, the description is complete: it defines the sampling strategy, the exact return fields, and the luminance formula. An agent can invoke it correctly without additional information, making it self-sufficient.

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

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

Schema description coverage is 100%: both level and view_id have descriptive comments. The description adds the luminance formula and algorithmic context but does not materially extend the parameter meanings beyond what the schema already states. Baseline 3 is appropriate as the schema already carries the semantic load.

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 verb and resource: it measures how much of the brightest region exceeds a given level, with precise algorithmic details (64px block, 128px and 32px boxes, sampling pattern). This distinguishes it from sibling measurement tools like measure_clipped_blocks or measure_highlight_texture, which target different phenomena.

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 for what the tool measures but does not explicitly compare it to alternatives or state when not to use it. It implies usage for clipping analysis in the brightest region, but an agent would need to infer selection from the tool name and description rather than explicit routing 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 present, the description fully discloses the operation: subject-pixel criteria, ROI construction, shell-zone definition, metric formulas, reference-handling behavior, error thresholds, and the luminance formula. This goes well beyond a simple 'measure texture' statement and leaves little hidden 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?

The purpose is front-loaded in the first sentence, and every subsequent sentence provides a necessary computational detail. The description is long, but the algorithmic complexity justifies its length; there is no filler or repetition.

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?

Despite lacking an output schema, the description lists the returned JSON keys, explains the reference/retention semantics, and states the error condition. Some minor ambiguity remains about how 'current' maps to the three metrics, but the description is sufficient for an agent to invoke the tool 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 already documents both parameters completely, so the baseline is 3. The description adds material meaning for reference_id by specifying that the reference is measured over the same ROI and that retention ratios are computed with null-rules, and it also clarifies the error condition involving either view. This exceeds the baseline.

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 action and target: 'Measure the texture of the bright subject zone.' It then enumerates exact metrics and a precise subject-pixel definition, so an agent can tell what resource is being measured. However, it does not explicitly differentiate this from sibling measurement tools such as measure_subject_detail or measure_sharpness.

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

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

No guidance is provided about when to use this tool versus alternative measurement tools, nor are there exclusions or prerequisites. The algorithmic detail implies a bright-zone texture context, but there is no explicit selection heuristic for an agent to follow.

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 the algorithm step-by-step (centre definition, radial profile, sign-change counting), output JSON structure, and the luminance formula. However, it does not explicitly state that the tool is read-only or has no side effects, though 'measure' implies it.

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

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

The description is dense and logically ordered: purpose, algorithm, output, formula. Each sentence carries technical substance with no filler, though it is longer than strictly necessary. The main purpose is front-loaded.

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

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

The description fully explains the algorithm and return values (oscillations, max_amplitude, center, profile_sample), compensating for the lack of an output schema. It does not cover edge cases (e.g., empty region, brightness threshold) or failure modes, but given the tool's complexity, it is comparatively complete.

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

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

Schema coverage is 100%, but the description adds significant meaning beyond the schema: it explains min_amplitude as 'summed |derivative| of a run' and how it filters oscillations, and clarifies view_id as the target image. This algorithmic detail is not present in 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 states a specific verb and resource: 'Measure concentric oscillation around the brightest region.' It provides detailed algorithmic context, but does not explicitly differentiate from sibling tools like measure_stars or measure_sharpness, leaving some ambiguity about when this specific measurement is intended.

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 its many siblings (e.g., measure_uniformity, measure_core_clipping). No exclusions or alternative routing are mentioned; usage context must be inferred from the name and algorithm.

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. It does so by disclosing the exact sampling strategy, luminance formula, output JSON fields, and error condition for mono views. It does not explicitly state it is read-only, but 'Measure... Returns JSON' strongly implies no mutation.

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 two dense sentences with no filler. Every clause provides necessary technical detail: formula, sampling, output, error condition, and luminance coefficients.

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

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

There is no output schema, so listing the exact JSON fields is essential and provided. The error condition, sampling rule, and formula fully equip an agent to invoke and interpret the result for a single-argument 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 100% and the only parameter view_id already has a basic description. The tool description adds meaningful semantics: the view must be a colour viewcars and mono views are invalid, which goes beyond the schema.

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

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

The description names a specific verb and resource: 'Measure HSV saturation' of subject pixels in a colour view. It includes the exact formula and the return values, making it clearly distinct from sibling measurement tools like measure_bright_chroma or measure_uniformity.

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 clearly states this applies to colour views only and that a mono view is an error, which is a strong when-not signal. It does not explicitly name sibling alternatives, so guidance on when to prefer this over measure_bright_chroma or measure_subject_detail is absent, but the technical definition gives sufficient context.

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 full behavioral disclosure: it names the exact algorithm, the pixel sampling strategy, ROI fallback behavior, output JSON structure, and luminance weighting. This is far more transparent than typical tool descriptions.

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 dense sentences deliver the formula, ROI behavior, and return format without redundancy. Critical information is front-loaded, and every clause earns its place.

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

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

For a measurement tool with no output schema and no annotations, the description is complete: algorithm, sampling, ROI semantics, constraints, and return fields are all specified. Nothing essential is missing for correct invocation and interpretation.

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 100%, so the baseline is 3. The description adds genuine meaning by explaining that ROI parameters must all be provided together or omitted for the central-half default, and that the region must lie inside the image.

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: 'Measure sharpness' via a precise formula (mean Sobel gradient energy). It also clarifies the region selection rules eliminating ambiguity against other measure_* sibling tools like measure_uniformity or measure_stars.

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 tool's purpose clearly implies when to use it: when sharpness of a region or central half is needed. However, it does not explicitly compare to sibling tools or state when not to use it, leaving alternatives 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 provided, the description carries the full behavioral burden and succeeds: it discloses the subsampling scheme ('every 4th pixel'), the selection threshold ('largest channel ... above 0.005'), the precise diversity and chroma formulas, and the exact JSON return fields. No contradiction with annotations since none exist.

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

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

The purpose is front-loaded and nearly every clause earns its place given the tool's six outputs. However, the opening sentence is a long run-on with nested parentheticals; tighter sentence structure would merit a 5.

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

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

With no output schema, the description rightly specifies the full return JSON, the sampling behavior, and the metric definitions, so an agent can call the tool correctly from text alone. Minor gaps remain: expected value range for levels and prerequisites for producing a star layer are not stated.

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 100%, so the baseline is 3. The description adds only modest param-level meaning: it ties levels to the fraction_above {level: fraction} output key structure, but otherwise largely restates what the schema already says about view_id and levels.

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 ('Measure') and a defined resource ('a star layer (a mostly black view holding stars)') and enumerates the exact metrics computed: fraction above levels, color_diversity, bright_star_chroma, max, and median. The algorithmic specificity distinguishes it from the sibling measure_stars without ambiguity.

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 star-layer definition implies the intended input context, but the description never states when to choose this tool over siblings like measure_stars, measure_sharpness, or measure_bright_chroma, and gives no exclusions or alternatives. Usage context is present only implicitly.

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 fully discloses the tool's behavior: pixel sampling grid size, local maxima criteria, deduplication limits, star count caps, FWHM definition, color diversity formula, luminance weights, and response fields including edge-case behavior for background_median. This is exemplary 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 dense but front-loaded with the core purpose before diving into technical specifics. Every detail (algorithm, limits, output fields) serves a purpose, though it is a single long block rather than structured sections, so it loses one point.

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

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

Given the tool's complexity and the absence of an output schema, the description is remarkably complete. It names every returned JSON field, explains how each is computed, states invariants like 'at most 100 kept' and the '30 brightest measured', and defines edge cases. An agent has enough information to invoke it correctly and interpret results.

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?

There is only one parameter, view_id, and the schema already covers it at 100% with 'View to measure.' The description does not add significant new semantic detail about how view_id is used beyond the schema, so the baseline score of 3 is appropriate.

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 and resource: 'Measure the stars of a view by pixel sampling.' It explains the exact algorithm and output stats, making it easy to distinguish from sibling measurement tools like measure_star_layer or measure_ringing.

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 explicit guidance is given about when to use this tool versus alternatives such as measure_star_layer or measure_sharpness. The description is purely algorithmic and does not mention when it is the appropriate choice, nor when another measurement tool should be preferred.

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

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

No annotations exist, so the description carries the full behavioral burden and delivers extensively: the 32px block segmentation, the subject-selection threshold (median + 8 × 1.4826 × MAD), exact formulas for every metric, the contrast_ratio edge case (0 when at most 0.001), the returned JSON keys, and the Rec. 709 luminance weights. This is far beyond what annotations would typically provide.

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 is front-loaded in the first sentence, followed by a methodical progression: algorithm, metric definitions, edge case, return format, luminance formula. Every sentence earns its place for a tool this complex, though the density of mathematical detail (constants, Sobel sampling, formula chains) pushes it near the upper bound of length.

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 single-parameter tool with no annotations and no output schema, the description is complete: it defines the computation, handles edge cases, enumerates all six JSON return values, and gives the luminance formula needed to interpret results. An agent can invoke the tool and correctly interpret its output with nothing else.

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

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

Schema description coverage is 100% for the single view_id parameter, so the schema already documents what it is ("View to measure"). The description adds no additional per-parameter meaning, but with full coverage the baseline of 3 is appropriate — nothing critical is missing.

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 "Measure subject brightness, detail and contrast" pairs a specific verb with a specific resource, and the algorithmic detail (subject vs. background blocks) makes it unmistakably distinct from sibling tools like measure_stars, measure_sharpness, and measure_uniformity. An agent can tell exactly what this tool quantifies and which siblings it does not overlap with.

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

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

Usage context is implied through the metric definitions — an agent can infer this tool is for subject/background analysis, not star measurement or sharpness measurement. However, with roughly ten measure_* siblings, the description never explicitly states when to choose this tool or names alternatives to exclude, leaving routing to inference rather than 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, the description carries the full behavioral burden and does an unusually thorough job: it specifies pixel classification thresholds, all output metrics, denominator clamping, and the exact luminance formula. The only gap is that it never explicitly states whether the operation is read-only or modifies the view, which is relevant given annotations are absent.

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 long but every sentence carries substantive algorithmic content; it is front-loaded with the core purpose and then systematically details the calculation. It could be more readable with structure, but for the complexity involved 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?

The description fully enumerates return fields, defines formulas, handles edge cases like denominators clamped to 0.001, and specifies the luminance formula, compensating for the lack of an output schema. It is incomplete only in not stating prerequisites or when to select this tool among the extensive sibling measurement family.

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 already provides 100% coverage for the single parameter view_id by describing it as 'View to measure', so the baseline is 3. The description adds no additional parameter-level guidance, such as whether the view must be open or what type of image is expected.

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: 'Measure subject and background tones', and then provides a precise algorithm and metric definitions. It does not explicitly contrast itself with sibling measurement tools, but the subject/background framing and metric names make the tool's function reasonably 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 description implies the tool is for measuring tonal separation between subject and background, but it gives no explicit guidance on when to use this tool versus the many sibling measure_* tools, nor any prerequisites or exclusions. An agent would have to infer selection criteria from the algorithm alone.

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 Committee. It goes beyond the schema by explaining the computation method ('4-corner median stddev') and the score direction ('Lower score means more uniform'). However, it does not disclose failure modes, return format details, or explicitly confirm read-only 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?

Two short sentences with no filler. The core purpose and score interpretation are front-loaded, and every phrase adds 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?

This is a simple two-parameter measurement, and the description covers what is measured, the method, and how to interpret the result. The lack of an output schema is partly offset by the word 'score', though an explicit return-type note would make it fully complete.

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

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

Schema description coverage is 100%, so both view_id and sample_size are already documented. The description does not add meaning beyond the schema; it merely implies the corner-sampling context that the schema already states for sample_size.

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 ('Measure'), a clear resource ('background uniformity'), and a distinctive method ('4-corner median stddev'). This distinguishes it from sibling measurement tools such as measure_stars, measure_ringing, and measure_sharpness.

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 choose this tool over the many other measure_* siblings, nor any preconditions like needing an open view. The intended use is only implied by the tool name and the phrase 'background uniformity'.

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 and exceeds it: it gives the exact mask formula using mask_clip_low, mask_gamma and mask_blur; describes the scale order and slope-limit assignment; explains the optional HDRMT pass; discloses that the mask is closed afterwards; and even specifies the Sobel-gradient detail score calculation. This is far beyond a generic 'enhances the 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?

The description is a dense, front-loaded paragraph: the core purpose is stated in the first sentence, then each subsequent sentence adds necessary algorithmic detail—mask construction, LHE scale behavior, optional HDRMT, mask closing, and the detail score. There is no filler or repetition.

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 17-parameter tool with no annotations and no output schema, this description is highly complete: it covers the algorithm, mask side effects, and the scoring behavior. The main gaps are that it does not specify the format in which the detail score is returned nor prerequisites such as the view needing to be open, but these are minor against the overall depth.

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 100%, so the baseline is 3, but the description adds relational value by tying mask_clip_low, mask_gamma and mask_blur into a concrete formula, assigning lhe_slope_limit to large/mid scales and lhe_fine_slope_limit to the fine scale, and clarifying that hdrmt_layers triggers the HDRMT pass. Some HDRMT-specific parameters remain schema-only, which is acceptable given full schema coverage.

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 'Masked three-scale LocalHistogramEqualization on a view, in one call, with an optional HDRMultiscaleTransform pass,' which is a specific verb-resource pairing and immediately distinguishes it from sibling tools like run_lhe and run_hdrmt by emphasizing the composite, masked, multi-scale nature.

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 when to use the tool—when a masked three-scale LHE with optional HDRMT is desired in a single call—but never explicitly names alternatives or exclusion criteria. The phrase 'in one call' hints at a separate-call alternative, but there is no direct routing guidance like 'for single-scale LHE use run_lhe.'

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 behavioral burden. It discloses the return value and the notable side effect of automatically closing crop_mask windows that come with XISF files, adding value beyond the bare purpose.

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 concise sentences with no redundant wording. The primary action is front-loaded, and the important side effect is included without extraneous detail.

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 low-complexity tool with one parameter and no output schema, the description is complete: it states what to provide, what happens, and what the agent will receive in return. No critical operational behavior is omitted.

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

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

Schema description coverage is 100% and the only parameter, file_path, is already documented as an absolute path. The description adds the supported file formats (XISF/FITS), but otherwise adds little beyond the schema baseline.

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 ('open'), resource ('XISF/FITS image file in PixInsight'), and the return value (view ID). This clearly distinguishes it from siblings like close_image, clone_image, and export_image.

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 intended use is implied: load an image file before further processing in PixInsight. However, it does not explicitly state when to choose this over alternatives or 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?

There are no annotations, so the description carries the full behavioral burden. It discloses non-obvious constraints: expressions reference open views by id, view ids must be simple identifiers, pow() is unsupported and must be replaced via exp(ln()) or ^, and symbols can only be constants. This goes well beyond a generic 'run PixelMath' statement.

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?

Four concise sentences, with the core purpose and key distinction front-loaded. Every sentence adds value: color behavior, identifier rules, and a math workaround. There is no filler or repetition of the input schema.

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

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

For an 8-parameter tool with no annotations and no output schema, the description covers the essential operational constraints and parameter relationships. It does not explain what happens on output_id conflicts or whether the new image becomes active, but the schema already documents the individual parameters, so the description is reasonably complete.

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

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

Schema coverage is already high at 88%, so the baseline is 3. The description adds meaningful parameter-level semantics by tying the color enum to which expression parameters are expected (red/green/blue vs single expression) and by giving expression-syntax constraints that are not present in 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 opens with a specific verb and resource: 'Run PixelMath to create a NEW image from expressions that reference other open views by id.' It clearly distinguishes this tool from siblings like run_pixelmath by emphasizing the new-image behavior, and it specifies the color-mode options (rgb vs gray).

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 creation-focused use case clear and gives practical guidance about expression identifiers and color modes. However, it never explicitly names an alternative tool (such as run_pixelmath) or states when NOT to use this tool, leaving the selection decision partly 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 safety burden, and it explicitly labels itself 'Read-only.' It does not describe error cases or whether PixInsight must be installed, but for a zero-argument informational probe this is a meaningful and sufficient behavioral disclosure.

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

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

Two short sentences with no waste. The core purpose is front-loaded, the read-only guarantee is immediate, and the alternative-tool pointer is kept to a single clause.

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 low-complexity, zero-parameter tool with no output schema, the description tells an agent everything needed to invoke it correctly: the result content, the read-only nature, and the neighboring live-status case. Nothing important is missing.

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

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

The input schema is empty and parameter coverage is 100%, so there are no parameters to document. The description adds useful context by stating what is reported (paths and connector version), which is the full semantic picture for a no-argument call.

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 ('Report') and resource ('resolved PixInsight installation paths... and the connector version'). This clearly differentiates it from the many image-processing sibling tools and from the workspace-oriented info tools.

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 redirects one relevant alternative case: 'For live process status, use the doctor command.' This tells an agent when not to use this tool and names the intended alternative, matching the best-practice pattern.

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 states that the mask is removed, implying a destructive action, but does not disclose prerequisites (e.g., whether a mask must exist), side effects, reversibility, or what happens if no mask is present. This is minimal behavioral transparency 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 with no wasted words. The action and object are front-loaded, and it is appropriately sized for the simplicity of 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?

For a simple one-parameter tool with no output schema, the description is minimally viable but leaves gaps. It doesn't mention what happens if no mask exists, whether the view must have a mask, or any error conditions. These gaps are notable because the description is the sole source of behavioral context, but they are not severe enough to make the tool unusable.

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 100%, and the only parameter target_id is already described as 'Target view ID'. The description adds no additional meaning beyond the schema, but with full schema coverage, a baseline of 3 is appropriate – the schema does the heavy lifting.

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 ('Remove') and the resource ('current mask from a view'), which is specific and unambiguous. However, it does not explicitly distinguish this from the sibling tool close_mask, which might also be interpreted as removing a mask from a view, so it lacks explicit sibling differentiation.

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

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

No guidance is provided on when to use this tool versus alternatives such as close_mask or apply_mask. The description only states what the tool does, leaving the agent to infer the appropriate context without any explicit conditions or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and a motivation for renaming, but does not disclose side effects, reversibility, error conditions, or the return value. For a mutation tool, this is a notable omission.

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 extremely concise, with two short sentences. The primary action is front-loaded, and the second sentence provides useful context about the purpose of renaming. No extraneous words.

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 rename tool with only two string parameters, the description covers the core purpose and a reason to use it. However, without annotations, it lacks details about required preconditions (e.g., view must be open), potential failure modes, or what happens after renaming. It is minimally complete but not thorough.

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

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

Schema description coverage is 100%, with both parameters already described ('Current view ID' and 'New view ID (no spaces)'). The description adds no additional semantic information beyond restating the renaming action, so it meets the baseline but does not enhance parameter understanding.

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 verb 'rename' and the resource 'image view', specifying the action as changing the view ID. No sibling tool appears to offer a rename operation, so it stands out on its own.

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 a specific context for using the tool: long XISF names can cause some PixInsight processes to fail, implying renaming might help avoid this. However, it does not explicitly state when to use it vs. alternatives or provide exclusions, leaving some usage decisions 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 of disclosing destructive behavior. 'Replacing all changes since the clone was made' clearly signals that the target image will be overwritten, which is essential safety information 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?

A single, well-structured sentence states the action, source, and consequence with no wasted words. It is front-loaded and easy to parse.

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 destructive operation with no output schema, the description plus schema provide adequate context: what happens, which parameters are needed, and what the effect will be. Minor lack of explicit alternative guidance 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?

Schema description coverage is 100%, and both parameters are already documented in the input schema. The description adds no additional meaning beyond identifying the operation's overall purpose.

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 identifies the action ('Restore'), the resource ('an image'), and the source ('a backup clone'), while distinguishing it from sibling tools like clone_image. The phrase 'replacing all changes since the clone was made' adds a precise outcome.

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 use case is implied: restore when you want to revert an image to a previously cloned state. However, it does not explicitly name alternatives or state when not to use it, leaving the routing decision partially inferential.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It fully delivers: it states the in-place mutation, the exact per-channel formula, linear weighting behavior, 64-bit PixelMath execution, truncation to [0,1], and the reporting of median/max before and after. This gives an agent a complete behavioral model beyond the schema.

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

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

The description is dense but every clause earns its place: purpose, formula, weighting, numeric precision, and reporting. It is front-loaded with the core action and then clarifies mechanics, making it efficient without 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 tool with no output schema and no annotations, the description is remarkably complete. It covers inputs, the algorithmic transformation, edge-case behavior, execution mode, and observable output (before/after stats). An agent has enough information to invoke the tool correctly and interpret its side effects.

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?

Even though schema coverage is 100%, the description adds significant semantic depth by tying parameters directly into the formula: max_value as the upper cap, restore_start and restore_end as the linear weighting range, and target_id/pre_star_id as the target and reference. It also explains edge behavior, such as the max(Lr, 0.001) denominator, which is not present in 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 states a specific verb ('Restore'), the resource ('the colour ratios of a reference view'), and the precise scope ('in the bright areas of a target'), while also noting it is in-place and preserves luminance. This clearly distinguishes it from generic tools like run_pixelmath and from other star-related tools by specifying the exact operation and domain.

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 clearly implies when to use the tool: when you need to restore reference color ratios in bright areas while keeping the target's luminance. It does not explicitly name alternatives or provide when-not-to-use guidance, so it falls short of a 5, but the context is unambiguous enough for selection among the large sibling list.

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 burden for behavioral disclosure. It indicates that the tool resumes command execution after a pause/abort, which is a behavioral state change. However, it doesn't disclose side effects (e.g., whether queued commands resume automatically) or any potential state changes beyond enabling commands. A clearer note on what exactly resumes would be more helpful.

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 extremely brief yet information-dense: two sentences, each earning its place. The first defines the action and context, the second specifies the prerequisite. No wasted words.

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

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

For a zero-parameter, state-transition tool with no output schema, the description is nearly complete. It explains the trigger condition and the effect. The only minor gap is that it doesn't describe what the user should expect after the call (e.g., a confirmation or how to verify that commands are enabled again), but given the simplicity, this is a minor omission.

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

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

The tool has zero parameters, and the schema correctly shows an empty object with 100% coverage. The description doesn't need to add parameter meaning since there are none, and it implicitly confirms that. This is a clear case where the baseline 4 is appropriate for no-parameter tools.

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 clear verb ('allow') and a specific resource ('PixInsight commands'), and clarifies it is a resume operation after a pause/abort. It distinguishes itself from the broader set of process-control tools, though it doesn't name a specific sibling alternative.

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 explicit usage guidance: 'Call ONLY when the user explicitly tells you to continue,' which clearly sets the condition. It doesn't explicitly mention when not to use it beyond caveating the condition, but that is sufficient.

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, and it does so thoroughly. It discloses that the view is modified in place, that passes before the last run on a scratch copy, that the view is left unmodified when any pass cannot be solved (e.g., D = 0), and that the result is JSON with per-pass statistics. It also explains the exact mathematical transform, including the MTF function and highlight compression. This is far beyond what annotations would typically provide.

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

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

The description is dense and information-rich, with the core purpose front-loaded in the first sentence. Every sentence adds technical detail that an agent needs to understand the algorithm. It is long, but the complexity of the tool justifies the length. It could be slightly more concise by trimming some mathematical notation, but the structure is logical: purpose, algorithm, parameters, edge cases, output.

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 complex 7-parameter image processing tool with no annotations and no output schema, the description is remarkably complete. It covers the algorithm, parameter semantics, edge cases (D = 0, unsolvable passes), the in-place mutation behavior, the scratch copy behavior, and the JSON return format. An agent could invoke this tool correctly with high confidence based on the description alone.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters. The description adds significant meaning beyond the schema: it explains how black_point_sigma relates to sigma = 1.4826·D, how passes interact with the previous output, how linked affects statistics grouping, and how highlight_knee/highlight_midtones are applied after the last pass. The only minor gap is that the description doesn't explicitly restate each parameter's constraints, but the schema already does that.

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 and resource: 'Stretch a linear view in place so its median lands on target_median.' It names the exact operation, the in-place mutation, and the target condition. It also distinguishes itself from siblings like run_curves, auto_stretch, and stretch_stars by describing a precise median-targeting algorithm rather than a generic stretch.

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 algorithm's behavior in detail, including per-pass statistics, the linked parameter for color vs grayscale, and the highlight_knee/highlight_midtones optional compression. It does not explicitly name sibling alternatives or state when to choose this over run_curves or auto_stretch, but the detailed mathematical behavior gives an agent enough context to know when this tool is appropriate. The 'linked true takes one set of statistics over all channels jointly; false takes them per channel' line is a clear usage condition for color images.

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 must carry the behavioral burden. It does disclose that the view is 'replacing it in place', indicating a destructive mutation, which is critical. However, it does not mention potential side effects, reversibility, or any conditions under which the operation might fail. The single disclosed behavior is important but not comprehensive.

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 concise sentence that front-loads the action and side effect. It is efficient with no wasted words. However, it could slightly expand on usage context without sacrificing conciseness, so it loses a point for being too terse in an area that matters.

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 mutates a view and has no output schema; the description covers the core action and side effect. Yet it lacks usage guidelines and differentiation from sibling tools, which are essential for an agent to decide when to use it. The information is adequate for a trivial call but incomplete for correct selection among similar tools.

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

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

Schema description coverage is 100%, so each parameter (view_id, tolerance, poly_degree) already has a textual description. The tool description adds no additional meaning or context for these parameters beyond the schema. Per the rubric, the baseline is 3 when schema coverage is high and the description does not enrich the semantics.

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

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

The description clearly states the tool runs AutomaticBackgroundExtractor (ABE) on a view and replaces it in place, which is a specific verb-resource combination. It distinguishes from siblings like run_per_channel_abe (which processes per channel) and run_bxt (a different background extraction tool). The action and scope are unambiguous.

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

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

The description offers no guidance on when to use ABE versus alternatives such as run_bxt, run_gradient_correction, or run_background_neutralization. It does not mention prerequisites, intended context, or exclusions. An agent cannot determine when this tool is preferred over its siblings.

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

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

No annotations are provided, so the description carries the full burden. It only states the intended effect but does not disclose that this mutates the target image, whether it is reversible, what happens on failure, or whether it requires a color image. This is a significant transparency gap for a process-invoking 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 compact sentence and is easy to parse. However, the opening 'Run BackgroundNeutralization' largely repeats the tool name, so it is not maximally economical.

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 schema is simple and the tool is callable with just view_id, but the description lacks behavioral context and does not explain how this relates to sibling background-correction tools. Since there are no annotations or output schema, the description should have done more.

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

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

Schema description coverage is 100%: view_id is described as a PixInsight view identifier. The description adds no additional parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb ('Run') and resource ('BackgroundNeutralization') with a clear outcome: equalize background level across channels. It is clear about what the tool does, but it does not differentiate it from sibling background-related tools like run_abe or run_gradient_correction.

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 context is implied: use this when you need background levels equalized across channels. However, there is no explicit guidance about when not to use it or which alternative to choose among background/gradient-related sibling tools.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explains the functional modes (PSF correction vs. sharpening) but does not state whether the operation modifies the view in-place, is reversible, requires specific image conditions, or what the tool returns. It omits side effects and any state changes, which is a significant gap for a process 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?

Two sentences with no filler. The purpose is front-loaded, and the parameter clarification is concise. Every word earns its place, and the structure is efficient for an agent to parse quickly.

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

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

For a tool with 5 parameters, no output schema, and no annotations, the description leaves important gaps: it does not mention the adjust_star_halos parameter (though the schema covers it), does not state what happens to the view (in-place modification?), whether processing is destructive, or what the expected return value is. An agent would need to infer too much to use this confidently.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying the conditional relationship: correct_only applies PSF correction without sharpening, and otherwise the sharpen parameters control strength. This helps the agent understand how the boolean and numbers interact, exceeding the schema's isolated definitions.

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 runs BlurXTerminator on a view, and distinguishes it from sibling tools like run_sxt (StarXTerminator) and run_nxt by specifying the exact process. It also names the key mode (correct_only) and the sharpening parameters, making the purpose 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 description provides guidance on when to use correct_only versus the sharpening controls, but it does not explicitly mention when to choose this tool over alternatives such as run_sxt, run_nxt, or other processing tools. There is no exclusion or alternative recommendation, leaving some usage ambiguity in a tool list with many similar process tools.

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