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

With no annotations, the description carries the full burden and does well: it discloses batching (one StarAlignment execution per batch, max 20), that files are written to output_dir, that matrix_only's temp folder under scratch is deleted afterwards, and that it runs without geometry confirmation dialogs. It stops short of stating required permissions or error handling, but side effects and write locations are 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?

Front-loads the core purpose before the mode and directory details. It is dense and somewhat run-on toward the end (matrix_only and result-format clauses are long), but every sentence carries distinct operational information rather than filler.

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

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

For a 9-parameter mutation tool with no annotations and no output schema, it covers the essentials: where outputs land, the matrix_only deletion behavior, and what the per-target result contains (StarAlignment outputData values). Minor gaps remain around permissions and failure modes.

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 beyond the schema: output_dir must lie inside <workspace>/output or the state folder, registered names follow <name><output_postfix>.xisf, and batch_size caps StarAlignment executions rather than just being a number.

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

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

States a specific verb and resource: 'Register image files onto a reference image file with StarAlignment, file to file (no views are opened).' The 'file to file / no views are opened' phrasing implicitly distinguishes it from view-based siblings like align_to_reference, so an agent can route correctly.

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 matrix_only alternative mode and output_dir placement rules, which helps mode selection. However it never states when to pick align_files over siblings such as align_to_reference or reproject_to_reference, so cross-tool selection is left 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 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?

With no annotations, the description carries the full burden and does so richly: a not-yet-started job is removed and never runs, a running job stops at its next processEvents() call with an MCP_CANCELLED error, native process calls cannot be interrupted, and already-applied changes persist. These are exactly the consequences an agent needs before invoking a destructive stop.

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

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

Front-loaded with the action, then layered with the important state-dependent behavior. It is longer than most definitions but nearly every clause conveys a distinct operational fact; the default-target sentence could be folded in more tightly.

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 parameterless-required cancellation tool with no output schema and no annotations, the description covers targeting, timing, interruption limits, and where to read the result. Nothing an agent needs to call it safely 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% and the single parameter's description already states 'Omit for the running job,' which the prose merely restates. Baseline 3 applies since the schema does the work and the description adds no new syntax or format detail.

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

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

States a specific verb and resource ('Stop a job') and names exactly which tools create such jobs (run_pjsr, run_pjsr_file with async), so the agent can place it precisely among siblings. It also implicitly distinguishes itself from job_status, which reports rather than cancels.

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?

Explains the trigger condition (a job started asynchronously) and the two distinct states it applies to, plus routes the agent to job_status for the outcome. It does not name an explicit when-not-to-use case, but the context is unambiguous for a one-param tool.

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

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

With no annotations to lean on, the description carries the full behavioral burden and does so well: it discloses the data-release fallback order and that failed searches are reported rather than retried, the supplement-merge behavior with merge_px replacement, the saturated flagging rule, the G-sorted order, and the 200-star inline limit with full output written to a scratch JSON file. Failure semantics and side effects are unusually explicit.

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

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

The purpose and search scope are front-loaded, and despite being a single dense paragraph, each clause conveys distinct information (search geometry, returned fields, release fallback, supplements, ordering, output destination). It is long but justified by the tool's complexity, with only minor packing of multiple ideas per sentence.

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 7-parameter tool with a nested supplement array and no output schema, the description fully compensates by enumerating the returned per-star fields (x, y, RA, Dec, G, BP-RP, in-frame status, peak luminance, saturation) and the file/inline output behavior. An agent has everything needed to invoke and interpret the call 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 coverage is already 100%, so the schema documents each parameter, but the description adds real semantic value beyond it: it clarifies that margin_fraction extends the center-to-corner radius, that merge_px governs replacement of a Gaia star by a supplement star, that saturation_level drives the saturated flag, and that an omitted data_release triggers an ordered fallback. This meaningfully enriches several parameters.

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

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

The description names a specific verb and resource ('List catalogue stars over a plate-solved view from PixInsight's local Gaia database') and specifies the exact scope (one Gaia search centered on the image with a corner-reaching radius). This is clearly distinguishable from siblings like measure_stars or measure_star_layer, which measure detected stars rather than querying a Gaia catalogue.

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

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

Usage is implied through the precondition that the view must be plate-solved, but the description never states when to prefer this over alternatives such as measure_stars or run_plate_solve workflows. No explicit exclusions or alternative routing are given, leaving the agent to infer the use case from 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?

No annotations are provided, so the description carries the burden, and it does disclose real behavior: the clone preserves FITS keywords, astrometric solution and view properties, implying a faithful copy that leaves the source intact. It doesn't cover cost, memory duplication, or any workspace/permission constraints, so it stops short of full 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 tight sentences: the purpose and restore path come first, then the preserved attributes. Every clause carries information and nothing is redundant.

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 only two documented parameters and no output schema, the description covers what the tool produces (a restorable backup view) and what it preserves. It omits whether the clone appears as a new open view or where it lives in the workspace, a minor gap for a low-complexity tool.

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

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

Schema description coverage is 100% (both source_id and clone_id are documented), so the schema already does the heavy lifting. The description adds only the implicit framing of clone_id as a view name via 'backup view,' which is marginal 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 (clone) and resource (image) and defines the outcome (a backup view). It also names the complementary sibling restore_from_clone, so an agent can distinguish this tool from other image-manipulation tools without opening a 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 clearly frames the use case — creating a backup you intend to restore later — and points at restore_from_clone as the paired operation. There is no explicit when-not guidance or note about prerequisites, keeping it just below 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?

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 does well: it discloses that neither view is mutated, that maximum and mean use every sample while p99 is taken over at most 2,000,000 evenly spaced samples, and defines when "identical" is true. It omits any note on error behavior for mismatched views, keeping it short of a 5.

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

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

Front-loaded with the core action, then the metrics, then the sampling caveat and the non-mutation guarantee in a single efficient closing sentence. Dense but every clause carries information; the nested quantifier/percentile detail is a touch heavy but justified.

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

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

There is no output schema, so the description must explain return values — and it enumerates them: per-channel max, mean, 99th-percentile absolute difference, fraction outside [0, 1], the "identical" flag, and p99Samples. An agent knows exactly what it will get back.

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 view_id, reference_id, and rect (including exclusive x1/y1). The description restates the whole-image-vs-rectangle choice and defines A/B roles implicitly, adding only marginal meaning beyond the schema — the baseline 3.

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 — pixel-by-pixel comparison of two open views — plus the dimensional precondition (same width, height, channel count). This clearly distinguishes it from siblings like get_image_stats or measure_sharpness, which operate on a single view.

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 conveys the applicable context (two open views of matching geometry, whole image or a rect) but never explicitly says when to pick this tool over alternatives or what to do if the views differ in size. Usage is implied rather than stated, so it lands at minimum-viable.

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?

With no annotations, the description carries the full burden and does so well: it discloses in-place mutation, the noGUIMessages behavior routing warnings to the Process Console, and the destructive side effect of deleting the astrometric solution. It stops short of stating limits (e.g., cropping past image bounds) or auth/permission needs, so not a 5.

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

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

Four sentences, each carrying distinct payload, with the core operation front-loaded before the side-effect details. Slightly dense but 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 mutation tool with no annotations and no output schema, the description covers the important behaviors (in-place edit, astrometric-solution loss, no-op case) and hints at the result reporting a removed solution. Missing only edge-case limits and failure conditions.

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%, giving a baseline of 3, and the description adds real meaning: it clarifies the amounts are pixels removed per side and that the zero/omitted default across all four amounts produces no change. This relational/edge-case semantics goes beyond the per-field 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?

States a specific verb (crop) and resource (image edges), plus the scope constraint 'in place.' An agent can distinguish it from siblings like resample_image or reproject_to_reference without opening any schema.

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

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

It describes the no-op case (all amounts 0 or omitted leaves the image unchanged), which is useful behavioral guidance, but never names an alternative tool or states when to prefer this over resampling/reprojecting. Usage context is only implied.

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

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

With no annotations, the description carries the 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, the description carries the full behavioral burden and does so well: it discloses parent creation, relative vs. absolute path resolution, refusal of out-of-scope paths, idempotent behavior for existing folders, and the return value.

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 tightly written sentences with no waste. The core action and path behavior are front-loaded, and the return value is stated last as useful closing 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 one-parameter directory-creation tool with no annotations and no output schema, the description is complete: it covers path rules, idempotency, side effects, and the return value. Nothing essential for correct invocation 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 description coverage is 100%, so the single parameter is already fully documented in the schema. The description reinforces the path rules but adds no syntax or format details beyond what the schema provides, making the baseline 3 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 gives a specific verb and resource: create a folder, including missing parents, within the workspace output or state folder. It is unambiguous and clearly distinguishable from the many process-running and image-operation siblings.

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

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

It clearly states the allowed path scopes and that paths outside them are refused, plus that an existing folder is left alone. It does not explicitly name alternatives or say when this tool should be preferred over other filesystem-related tools, but the usage context is clear.

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

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

With no annotations provided, the description carries the full burden and does so well: it discloses the path sandbox and refusal behavior, that the working image is unchanged, that parent folders are auto-created, and that FITS keywords/astrometric solutions/view properties are preserved or dropped depending on format. These are non-obvious behavioral traits 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?

It is a dense single paragraph but every sentence carries load and the core action is front-loaded. Length is justified by the amount of genuinely useful constraint detail, though it could be split for readability.

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

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

No output schema or annotations exist, and the description fully compensates by covering path rules, format-from-extension mapping, bit-depth defaults, metadata preservation, and non-mutation of the source image. Nothing an agent needs to call it correctly appears 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 already 100%, so the baseline is 3, but the description adds real meaning: relative paths resolve under <workspace>/output, absolute paths must lie in output or the state folder, and bit-depth defaults per format map onto the 'bits' enum. It goes beyond restating 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: "Write an image to a file in the workspace's output or state folder," which clearly distinguishes it from read-only image tools and from preview siblings like save_preview. An agent can identify the core action without opening 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 detailed conditional rules for path resolution and format selection, which implicitly guides correct invocation, but it never states when to prefer this tool over alternatives such as save_preview or save_and_show_preview. Usage is implied rather than explicitly contrasted against siblings.

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

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

With no annotations, the description carries the 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 and does well: it discloses case-insensitive substring matching, grouped-name expansion with a concrete example, result ordering (exact, substring, grouped), and that Q channel curves are returned. It does not mention cost, limits, or result size, but for a read-only search this is substantial.

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 tight sentences, front-loaded with what and how it matches, then the routing advice, then a niche detail. 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 two-param read-only lookup with no output schema, the description covers matching behavior, ordering, and when to use it. It could say what a result row contains (name only? name+QE curve?), which would matter for an agent parsing the response, but nothing essential 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 already 100% with examples for both params, so baseline is 3; the description adds real meaning beyond the schema, namely the case-insensitive substring semantics of 'query' and the grouped-name matching rule, plus the Q-channel note relevant to 'channel'.

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

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

Names a specific verb (search) and resource (PixInsight's built-in filter and camera QE database) with the exact lookup key (name, case-insensitive substring). An agent can distinguish it from all the run_*/measure_* siblings at a glance.

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

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

Explicitly states the purpose: 'Use it to pick exact names for run_spfc or run_spcc,' which maps this lookup tool onto the two downstream tools that consume its output. It does not state when-not to use it, but for a benign lookup tool the context is clear.

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

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

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?

No annotations are provided, so the description carries the full burden. It discloses what is computed (median, MAD, min/max, per-channel medians, clampFractions), which is meaningful behavioral detail, but says nothing about cost, whether the view must be open, or side effects. Adequate but leaves gaps for a no-annotation tool.

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

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

A single front-loaded sentence lists the verb, resource, and all returned statistics with zero padding. 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?

With no output schema, the description compensates by enumerating the exact returned values including the non-obvious clampFractions. It is close to complete for a read-only stats tool, missing only access/prerequisite context.

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?

Only one parameter (view_id) and schema description coverage is 100%, with the schema documenting it as a PixInsight view ID. The description adds no further parameter meaning, which matches the baseline when the schema does the work.

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

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

States a specific verb (get) and resource (image statistics) and enumerates the exact statistics returned. It is distinct from measurement siblings like measure_sharpness or measure_saturation, though it does not explicitly say how it differs from them.

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

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

There is no guidance on when to prefer this tool over the many measure_* siblings (measure_core_clipping, measure_clipped_blocks, etc.), nor any prerequisites such as the view needing to be open. Usage is only implied by the tool name and stat 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?

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 and does so well: it discloses side effects (temporary synthetic/64x64 images are created and then closed), an explicit safety guarantee ('open images are not touched'), per-file error semantics (readable/missing/corrupt), and the null-coverage fallback when ra_deg/dec_deg are omitted. This is exactly the 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?

Front-loaded with the core purpose, then one clause-group per section, so the structure is scannable despite being a dense single paragraph. It is appropriately sized for a four-section diagnostic, though the run-on enumeration of per-section behaviour could be tightened.

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

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

No output schema exists, so the description must describe return content, and it mostly does: magnitudes/spectra for gaia, per-file status and coverage for mars, version/model/gpu-cpu for xterminators, memory and disk for system. A few return details (e.g. precise field names, failure modes when PixInsight sections error) remain implicit, keeping it short of a 5.

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 100%, so baseline is 3, but the description adds real meaning: it explains that sections default to all, that mars_files overrides the configured MARS files, and that omitting the ra/dec pair makes the probe position (0,0) and coverage null. This 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?

States a clear specific verb and resource: 'Report what this PixInsight installation has', and enumerates exactly what is probed (gaia, mars, xterminators, system). It is easy to distinguish from measure_* tools, but it never names its closest siblings (pixinsight_info, workspace_info, list_packs), leaving differentiation to inference.

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

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

The description implies this is a one-shot diagnostic and explains each section's behavior, but it never states when to run it versus alternatives like pixinsight_info or workspace_info, nor any prerequisites or warnings about cost. Usage context is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does so well: it declares the tool read-only, explains that it does not use PixInsight and therefore answers while a job runs, and enumerates every state value plus the ancillary data (elapsed time, processEvents interval, mcpProgress text, result/error, console errors).

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 dense but well-structured sentence lists the return fields, followed by a short default-behavior sentence and a short read-only caveat; nothing is redundant, though the first sentence is long enough to be slightly heavy.

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

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

There is no output schema and no annotations, so the description must cover both behavior and return shape; it does, describing the state set, timing metrics, progress text, and terminal result/error content. Nothing an agent needs to call it correctly 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 description coverage is 100% and the single job_id parameter is fully documented there. The description's note that omitting job_id returns the running or most recent job restates the schema rather than adding format or ID-provenance detail, so the baseline 3 applies.

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

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

The description names a specific verb (report on) and resource (a job started by run_pjsr/run_pjsr_file with async), and enumerates the exact fields reported, so an agent can distinguish it from cancel_job or wbpp_status without opening any schema.

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

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

It gives a clear trigger (a job started by run_pjsr or run_pjsr_file using async) and explains the no-argument default behavior. It never names an explicit alternative sibling (e.g., cancel_job, wbpp_status) or states when not to use it, so it falls 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, 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 carries the full behavioral burden. It discloses the sampling method, thresholds, de-duplication, FWHM calculation, color diversity, and the exact return fields. It lacks explicit side-effect or error info but is highly transparent about its process and output.

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 each sentence adds necessary technical detail. The purpose is front-loaded, followed by a logical breakdown of the algorithm and return values. It is dense but not wasteful.

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

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

For a single-parameter tool with no output schema, the description is exceptionally complete. It defines the algorithm, thresholds, return fields, and even the luminance formula, leaving no ambiguity 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 schema already describes view_id as 'View to measure' with 100% coverage. The description does not add any extra semantics, format constraints, or usage hints for this parameter. Baseline 3 applies.

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

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

The description clearly states 'Measure the stars of a view by pixel sampling' with a specific verb and resource. It goes further to describe the exact algorithm, distinguishing it 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?

There is no guidance on when to use this tool versus alternatives. It does not mention conditions, exclusions, or trade-offs. An agent would have to infer its use case from the technical details 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?

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?

With no annotations, the description carries the full burden and delivers: output is truncated to [0,1], the reply reports per-channel fraction of pre-truncation out-of-range samples, the astrometric solution is copied only when size_from has one (and only unless copy_astrometric_solution is false), view ids must be simple identifiers, and pow() is unavailable. These are exactly the behavioral facts an agent cannot infer from schema or annotations.

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?

Information-dense and front-loaded, with the tool's core action first and constraints after. It is a single long paragraph of interrelated clauses rather than a run-on, but the lack of any structural break makes it heavier to scan than it needs to be.

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 9-parameter mutation tool with no output schema, the description supplies the return information (per-channel clipping fractions) and the key behavioral caveats, so an agent can call it correctly. It does not say what happens on failure (e.g., bad expression or unknown size_from) or whether the new image is opened/shown.

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 89%, so the baseline is 3, and the description adds real meaning on top: which parameters pair with which color mode, the semantics of size_from's astrometric propagation, and that symbols may hold constants only. It does not explain expression syntax operators beyond the pow() caveat or the exact meaning of each channel expression.

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

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

States a specific verb and resource ('Run PixelMath to create a NEW image from expressions that reference other open views by id'), which separates it from run_pixelmath, run_pjsr, and the measure_* siblings at a glance. The 'NEW image' framing tells an agent this constructs a view rather than modifying one in place.

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 covers in-tool conditions (color 'rgb' takes red/green/blue, color 'gray' takes a single expression) and constraints on expression syntax, but never says when to choose this tool over the sibling run_pixelmath or run_pjsr. Usage is implied by the expressions-and-new-image framing rather than stated.

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

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

With no annotations, the description carries the 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 and does so well: it states the source is not changed, the result is a new 32-bit float view with a default naming convention, and the call reports size, time, and whether the result is empty when fields do not overlap. It also flags the accuracy caveat (registration set by the solutions; verify residual against the reference).

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?

Information is front-loaded (what it does, then when to use, then side effects), and every sentence adds something. It is dense but slightly over-packed into the first long sentence with nested parentheticals.

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 no-output-schema mutation-of-a-new-view tool, the description covers prerequisites, side effects, defaults, and a summary of returned facts. It stops short of describing the return structure in detail, though the reported fields are named.

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 including defaults and the interpolation enum. The description adds only a behavioral note that the result comes from a single interpolation of the source, and says nothing about clamp or the enum choices beyond 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?

It states a precise verb and resource (resample onto another image's pixel grid via the two astrometric solutions) and clarifies the outcome (result takes the reference's size and solution). It does not explicitly contrast with siblings like align_to_reference or resample_image, so an agent still has to infer the boundary between them.

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

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

Gives a concrete use case (bring a master from another telescope/session onto a reference grid) and a hard prerequisite (both views need a solution, run_plate_solve). It names no exclusion or alternative tool, so the when-not side is left 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, the description carries the full behavioral burden and does so well: it discloses that it runs in place or on a copy (output_id) that carries keywords/solution/view properties, that FITS keywords are kept, that PixInsight removes the astrometric solution and reports its before/after presence, and that the geometry dialog is suppressed (noGUIMessages). This is rich, mutation-relevant detail.

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 core purpose and in-place/copy distinction are front-loaded, and every sentence carries information (mode semantics, side effects, astrometric behavior). It is a dense single block rather than cleanly sectioned, which keeps it just short of top marks.

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 mutation tool with no output schema, the description covers modes, in-place vs copy behavior, preservation of keywords, astrometric-solution removal, and even what the result reports. Minor gaps remain (no pagination/return-structure concerns here, but interpolation choice reasoning against siblings is absent), so a 4.

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 baseline is 3, but the description adds real meaning beyond the schema: 'factor 2 bins 2x2 into one pixel with the given downsampling combination' concretizes integer mode, and 'enlarge: true multiplies the size instead' clarifies direction semantics the schema only states tersely.

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?

Starts with a specific verb+resource ('Change an image's pixel dimensions') and names the three operating modes, each with a concrete behavior (2x2 binning, relative factor, match reference size). An agent can distinguish this from crop_image, reproject_to_reference, and align_to_reference from the description alone.

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

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

The description explains what each of the three modes does, which helps an agent pick a mode, but it never states when to prefer this tool over siblings like crop_image or reproject_to_reference, nor any prerequisites. Mode selection guidance is present; tool-vs-alternative guidance is not.

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.