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

Annotations already provide readOnlyHint=true and destructiveHint=false, and the description adds the non-destructive label plus the plate-solved prerequisite and JPEG output format. It does not describe what happens with unsolved inputs or output delivery, but the annotation profile covers the key safety concerns.

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, front-loaded sentence with no filler. Every phrase contributes useful context about the operation, content, and safety.

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

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

With no output schema and 0% parameter documentation, the description leaves important gaps: the meaning of max_edge, the available layer strings, and the format or location of the rendered JPEG are not specified. The purpose is clear, but an agent cannot fully determine call semantics.

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

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

Schema description coverage is 0%, so the description carries the burden for explaining id, layers, and max_edge. It only hints at possible layer values by listing annotation types, leaving id and max_edge effectively unexplained.

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 specifies a verb ('Render'), resource ('annotated JPEG'), content types ('Messier/NGC/named stars/constellations/grid'), and purpose ('to confirm the target'). It is distinguishable from generic preview tools, though it does not explicitly contrast itself with sibling 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 phrase 'to confirm the target' offers an implied use case after plate solving, but there is no explicit guidance about when to choose annotate over render_preview or compare_previews, nor any exclusions or alternatives.

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

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

Annotations already indicate a mutating, non-destructive operation. The description adds meaningful behavioral detail: the effect on subsequent processes and the inverted masking semantics. It does not contradict annotations and gives useful context beyond the structured fields.

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, efficient sentence with parenthetical clarifications. It front-loads the core action and adds the inverted behavior without 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?

The description covers the main behavior well, but it omits explicit semantics for visible and the conditions under which mask_id is needed (especially in remove mode). Since there is no output schema and parameters are weakly documented, these gaps leave some 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?

Schema description coverage is 0%, so the description must compensate. It explicitly explains remove and inverted, but id, mask_id, and visible are left to inference. While id and mask_id are somewhat inferable from context, visible is not addressed, and the relationship between remove and mask_id is unclear.

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 (attach/remove), a resource (mask view to an image window), and the consequence (subsequent processes are masked). It also distinguishes itself from mask creation siblings like star_mask or range_mask by focusing on applying an existing mask to a window.

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: attach a mask view, remove it with remove:true, and use inverted:true to protect bright regions. It does not explicitly name alternatives or state when not to use the tool, but the usage context is clear enough for an agent to select it appropriately.

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

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

Annotations already mark destructiveHint=true and readOnlyHint=false, so the mutation risk is established. The description adds meaningful context: global application when id is omitted, requirement for exact PJSR parameter names, enum string handling, and the 'Checkpoints first' instruction. It does not describe failure modes or return behavior, but enough behavioral context is added beyond 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?

Three dense sentences, each earning its place: the fallback role, the invocation mechanics, and the checkpoint warning. It is front-loaded with the most important framing and contains 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 generic, schema-light tool, the description covers invocation scope, parameter naming conventions, enum handling, and safety behavior. It also references process_params for further detail. The only notable omission is the semantics of ignore_unknown, but the overall guidance is sufficient for an agent to attempt 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 coverage is only 20%, and the description compensates by explaining 'process' (applied by name), 'id' (omitting it means global), and 'params' (flat object, exact PJSR names, enums as strings). The reference to process_params is helpful. However, 'ignore_unknown' is left unexplained, which prevents a higher 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?

States a specific verb ('apply'), resource ('any installed PixInsight process by name'), and scope ('to a view or globally when id omitted'). The 'Generic fallback' label distinguishes it from the many dedicated process tools in the sibling list, so an agent immediately knows this is the catch-all path.

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 'Generic fallback' clearly implies it should be used when no dedicated tool applies, and it points to process_params for exact parameter names. It does not explicitly enumerate when-not-to-use conditions, but the fallback framing provides adequate 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?

Annotations already mark destructiveHint=true, and the description adds useful behavioral detail beyond that: dry_run only reports the rect, while a real run crops and is preceded by a checkpoint. This is meaningful disclosure for a mutating 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 short and front-loaded: the algorithm comes first, then dry_run behavior, then checkpointing. The fragment 'Checkpoints first' is slightly ambiguous but still compact and useful.

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

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

For a destructive 6-parameter tool with no output schema, the description covers the main behavior and dry-run semantics but misses threshold and id. It also does not say what a non-dry-run call returns or how the crop is applied to the image.

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

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

With only 17% schema description coverage, the description does much of the work, explaining max_zero_fraction, pad, dry_run, and checkpoint. However, it omits threshold entirely and does not clarify id, leaving two parameters effectively unexplained.

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 (trim registration edges) and explains the exact criterion: rows/columns with > max_zero_fraction zero pixels are cropped with padding. This clearly distinguishes auto_crop from generic siblings like crop and crop_preview.

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 clear context for when the tool applies: trimming registration edges. It also advises using dry_run to preview the rect and checkpointing first. However, it does not explicitly contrast with crop or other crop-like 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds the 'Checkpoints first' warning, which is valuable behavioral context for a destructive operation. However, it doesn't disclose what exactly gets modified (e.g., does it replace the image's background model, alter pixel values irreversibly?) or whether it requires a specific image state. The description adds some value beyond annotations but not rich behavioral 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 description is extremely concise: one sentence with a parenthetical clarification and a two-word usage warning. Every word earns its place, and the key information (what it does, when it applies) is front-loaded. The 'Checkpoints first' warning is a critical addition that justifies its placement.

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 destructive linear-stage tool with 5 parameters and no output schema, the description is somewhat thin. It tells the agent what the tool does and that checkpoints are needed, but it doesn't explain the parameter semantics (especially reference_id and background_high), what the expected input image state is, or what the result looks like. The sibling list includes gradient_correction and color_calibrate, which are related but the description doesn't disambiguate. It's adequate but has clear gaps.

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

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

Schema description coverage is 40%, meaning the schema documents some parameters (id, params, checkpoint, reference_id, background_high) but the description itself adds no parameter-level meaning beyond the schema. The description's 'equalize channel backgrounds' hints at what background_high might control, but it doesn't explain the relationship. With 40% coverage, the description partially compensates but doesn't fully bridge the gap for undocumented parameters like reference_id and background_high.

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: 'BackgroundNeutralization (equalize channel backgrounds) — linear stage.' This clearly identifies the tool as applying PixInsight's BackgroundNeutralization process to equalize channel backgrounds, and the 'linear stage' qualifier distinguishes it from tools used later in the processing pipeline. It doesn't explicitly name a sibling alternative, but the parenthetical and stage qualifier provide enough 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 gives a clear context signal: 'linear stage' implies this should be used during the linear phase of processing, and 'Checkpoints first' gives a usage prerequisite. However, it doesn't explicitly state when not to use it or name alternative tools (e.g., gradient_correction, color_calibrate) that might be confused with it. The guidance is implied rather than 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?

The annotations already disclose destructiveHint=true, so the description does not need to repeat that the operation modifies data. The 'Checkpoints first' instruction adds useful context that a checkpoint should be created before invoking the tool, which is a behavioral safeguard. However, it does not describe what actually happens to the view, whether it is modified in place, or what the result looks like.

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 very short and puts the core action first: 'Binarize a (mask) view at a threshold.' The second sentence is also brief, but 'Checkpoints first' is ambiguous enough that it slightly hurts the overall clarity. Still, there is no wasted text.

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 destructive tool with no output schema and three undocumented parameters, the description is incomplete. An agent needs to know what id refers to, how threshold values behave, what the checkpoint parameter does, and what side effects occur. Only the destructive hint and a vague checkpoint warning are available.

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

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

Schema description coverage is 0%, so the description should compensate by explaining id, threshold, and checkpoint. It only alludes to threshold and gives a cryptic 'Checkpoints first' reference, leaving the meaning of the checkpoint parameter and the id parameter largely unstated. Parameter names are suggestive but not sufficient 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 states a specific operation ('Binarize') on a resource ('a (mask) view') with a defined condition ('at a threshold'), so an agent can tell this is a thresholding operation rather than a generic image process. It does not explicitly distinguish it from sibling tools like convert_to_gray or range_mask, but the binarize/threshold phrasing is clear enough for basic selection.

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

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

The phrase 'Checkpoints first' gives a sequencing instruction but no real when-to-use guidance or comparison with alternatives. It does not explain when binarize should be preferred over pixel_math, range_mask, apply_mask, or other image-processing siblings, and it does not state any exclusion conditions.

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

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

Annotations already mark this as read-only and non-destructive; the description adds useful behavior beyond that: auto-stretched thumbnails, per-frame metrics, suspect flagging, and page size. It does not fully describe the deferred job_id lifecycle or return format, but for a read-only review tool the core behavior is well disclosed.

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

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

The description is two sentences, front-loaded with the tool's operational purpose, and ends with a clear workflow instruction. There is no fluff or repetition of the tool name.

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 has no output schema and several optional parameters, this description provides enough core context for a typical review use-case. It does not document the asynchronous job_id channel or exact output/display mechanics, but it is still sufficiently complete for the primary intended usage and follow-up via exclude_frames.

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 very low at 14%, so the description must compensate. It does map the main selection options: 'light group (or file list)' covers group_id/files and 'pages of up to 30 frames' gives some per_page/page context. However, thumb, columns, page, and the play between job_id and page are not meaningfully explained.

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

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

The description uses a specific action ('renders a contact sheet') and a clear resource ('light group or file list'), and lists both what it shows and what it flags. It also differentiates itself by naming the follow-up workflow with exclude_frames.

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

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

The description explicitly says the tool is a blink-style review 'before stacking' and gives the agent the next action: inspect the sheet, then pass bad indexes to exclude_frames. It does not explicitly enumerate alternatives or exclusions, 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?

The annotations mark the tool as destructive (destructiveHint=true), and the description reinforces this by warning to 'Checkpoints first' – implying the operation overwrites/mutates and can be undone via checkpoint. It adds context about the destructive nature and a recommended safety step, but doesn't detail what exactly gets destroyed.

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 short with no filler; it packs the core action and a key caveat into two fragments. It is efficient, though slightly cryptic.

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 three parameters and no output schema, the description should compensate by explaining parameter meaning and return behavior. It fails to do so, leaving the agent with incomplete knowledge 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?

Schema description coverage is 0% and the description does not explain any of the three parameters (id, sigma, checkpoint). The agent gets no semantic information about what id represents, what sigma range is expected, or what the checkpoint flag controls.

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 the operation as 'Gaussian convolution' with the target explicitly being masks ('soften masks'). The purpose is identifiable from the name and description, but it does not distinguish itself from sibling tools such as denoise or sharpen.

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 only instruction is 'Checkpoints first,' which tells the agent to ensure a checkpoint exists before calling. No alternatives or when-to-use guidance is provided relative to sibling tools, leaving selection inference to the agent.

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 adds meaningful behavioral context beyond the sparse annotations: caching by fingerprint, instant returns on cache hits, and async execution unless wait:true. It also discloses the rejection method. However, it does not state what is returned on a miss or whether an existing master bias is overwritten.

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 tight, information-dense sentences with no filler. The core operation is front-loaded, followed by caching behavior and async semantics. Every sentence 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 tool with 5 parametersaching, and async behavior, but critical invocation details remain unclear: what force does, what a non-cached response looks like, and how rejection values are specified. Since there is no output schema and annotations are minimal, these gaps matter.

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 60%, so the schema covers some parameters. The description adds semantics for wait ('async unless wait:true') and hints at rejection ('percentile rejection by count'), but it does not explain force or enumerate valid rejection values, leaving gaps for the less-documented 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?

States a specific verb ('Integrate') and resource ('bias frames into a master bias'), and distinguishes the algorithm ('average, Winsorized/percentile rejection by count, no normalization'). This clearly separates it from sibling tools like build_master_dark and build_master_flat.

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

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

The description implies usage by naming the bias-frame-to-master-bias purpose, but it does not explicitly say when to choose this tool over build_master_dark or build_master_flat. There are no exclusion conditions or alternative recommendations, so usage guidance 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?

The description discloses behavior beyond the annotations: it is 'Cached by fingerprint' and 'Async: returns job_id.' These are genuinely useful execution traits that the annotations do not convey. It stops short of detailing whether cached results bypass processing or what failure modes exist, but it adds meaningful context.

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

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

Four short sentences, each earning its place: the core action, a critical parameter warning, a caching note, and the async interface. Information is front-loaded, with the primary purpose first and the most important caveat second. 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?

The description covers the essential execution model (async, job_id, caching) and one critical parameter, but it does not fully compensate for the missing schema descriptions of wait, force, and rejection. With six parameters and no output schema, an agent may still be uncertain about how to request synchronous execution or control rejection behavior.

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

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

Schema description coverage is only 33%, so the description carries a heavier responsibility. It does add value for master_bias by stating when it should not be passed and why. However, parameters like wait, force, and rejection remain undocumented in both the schema and the description, leaving the agent to infer their meaning.

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: 'Integrate darks into a master dark.' It clearly identifies what the tool does and is easily distinguished from sibling tools like build_master_bias and build_master_flat by the resource it produces (a dark master) and the input it integrates.

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 clear operational guidance: it explicitly warns not to pass master_bias unless using dark optimisation, explaining the CMOS rule that 'bias lives inside the dark.' It does not explicitly compare to sibling build tools, but the rule is a strong usage constraint that helps an agent decide when and how to invoke this tool.

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

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

Annotations only indicate non-read-only and non-destructive, so the description adds useful behavioral context: cached, async, and multiplicative EqualizeFluxes rejection normalization. It does not describe what artifact is produced or returned, but it goes beyond the annotation baseline.

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 deliver the core operation, the critical warning, and the async/cached behavior with no filler. The information is front-loaded and 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 7-parameter tool with no output schema and low schema coverage, this description is incomplete. It omits the meaning of wait despite being async, does not explain force or rejection, and does not clarify the files/group_id alternatives or what the tool returns.

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 only 29%, so the description must compensate, but it only clarifies the role of master_flat_dark and master_bias. It does not explain wait, force, rejection, or the relationship between files and group_id, leaving several parameters under-specified.

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

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

The description states a specific operation: calibrating flats using a master flat-dark or master bias, then integrating multiplicatively. This is clear enough to distinguish it from build_master_bias and build_master_dark, though it does not explicitly differentiate it from calibrate_lights.

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

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

It gives clear input guidance: prefer a master flat-dark, fall back to a master bias, and never use the light master dark. It does not explicitly compare this tool to sibling calibration/integration tools, but the stated preference and hard negative are actionable.

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 adds meaningful behavior beyond the generic annotations: it discloses the CFA-aware nature, the requirement for a master flat, the output location pattern, and that execution is async with per-frame progress. This gives the agent useful operational expectations without contradicting the readOnlyHint/destructiveHint 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?

The description is compact and front-loaded: the first sentence states the core operation, and subsequent sentences provide constraints, output, and async behavior. Every sentence adds operational value with 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 tool with 10 parameters and no output schema, the description covers the main workflow, output destination, and async behavior. However, it does not explain how out_dir interacts with the session path, how files and group_id selection are expected to work, or how outputs relate to previously calibrated files. These gaps make it adequate but not 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?

The description compensates for the 50% schema coverage by clarifying the roles of master dark, master flat, master bias (only for dark scaling), and force. It also implies out_dir semantics via the output path. Some parameters like out_dir remain ambiguous, but the core master/force relationships are meaningfully explained 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 process ('ImageCalibration'), the exact resource ('light frames'), and key characteristics ('CFA-aware', uses master dark/flat). It is clearly distinguished from sibling tools like build_master_dark, debayer, or cosmetic_correction because it targets the calibration step for light frames.

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 by specifying that it calibrates light frames with master dark/flat, and it provides a failure condition ('Refuses without a master flat unless config requireFlats=false or force:true'). However, it does not explicitly mention alternatives or when not to use it, such as when only cosmetic correction or debayering is needed.

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

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

Annotations already indicate the tool is not read-only and not destructive. The description adds useful behavioral detail beyond that by specifying the side effect: writing an .xisf file into the checkpoints directory and returning a path for later restore. It does not cover naming/overwrite behavior, but annotations reduce the burden.

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

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

A single sentence packs in the action, file format, target directory, and return value. It is front-loaded with the core operation and contains 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 simple two-parameter tool, the description is reasonably complete: it states what is written, where, and what is returned. However, it leaves parameter meanings implicit, especially 'label', and provides no explicit when-to-use guidance. This is adequate but has clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It hints that a 'view' is the subject, which loosely maps to the required 'id' parameter, but it never explains what 'id' identifies or what the optional 'label' means. This is partial guidance at best.

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 ('Write'), names the concrete artifact ('.xisf checkpoint of a view'), and states the destination ('session's checkpoints/ dir'). It also connects the tool to restore_checkpoint, clearly distinguishing it from siblings like restore_checkpoint or list_checkpoints.

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 'returns the path for restore_checkpoint' gives clear contextual guidance: this tool is for creating a restore point that will later be used by restore_checkpoint. It does not explicitly list alternatives/exclusions, but the intended workflow is clear enough for an agent to choose it over unrelated save operations.

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 destructiveHint annotation already signals a destructive tool. The description adds value beyond that by enumerating which directories will be deleted, which are kept, and by revealing that dry_run lists the targets without deleting. This gives agents useful optional context beyond the annotation.

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

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

The description is one dense sentence, front-loaded with the action, and every part directly contributes to the usage: what gets deleted, what gets kept, and the dry-run option. There is no redundancy or verbosity.

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 deletion tool with no output schema, the description covers the most important operational facts: exact directory list, retained directories, and dry-run. But it leaves also_previews/also_checkpoints a bit under-specified and does not mention what happens if a directory is missing. It still gives enough to call it safely.

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 only 33%, so the description needs to compensate. It does add meaning to dry_run by explaining its behavior (lists what would go), but remaining parameters (also_previews, also_checkpoints) are only hinted at indirectly via the keep-list. This is adequate but incomplete.

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 ('Delete') with an explicit resource (intermediate directories in the current working dir) and enumerates the exact directories to remove and preserve. It clearly identifies its scope and is not ambiguous against any sibling tool.

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

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

The description implies its use for clearing intermediate processing directories while preserving masters and outputs, and the dry_run instruction hints at a how-to-list step. However, it never explicitly states when to use it vs alternatives or what conditions make this the right cleanup 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?

The annotations already flag destructiveHint=true and readOnlyHint=false. The description adds concrete behavioral context: force defaults to true and discards unsaved changes, which warns the agent about the destructive default beyond what the annotations state.

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 compact sentence that front-loads the action and packs the force semantics into a parenthetical. Every word earns its place.

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

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

For a simple close operation, the description plus annotations cover the safety-critical behavior and the default. It does not state what force=false does or where id comes from, but these are minor gaps given the simple schema and absence of nested/output schemas.

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

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

The schema has zero descriptions for the two parameters, so the description must compensate. It usefully explains force (discard unsaved changes, default true), but it does not explain id, which is required.

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 direct object ('Close an image window'), and the parenthetical clarifies the force parameter. It is clearly distinguished from sibling operations like open_image, duplicate_window, and list_windows even without naming 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?

No explicit when-to-use or alternative routing is provided; the tool does not mention list_windows for obtaining an id or saving before closing. The use case is strongly implied by the operation name, so an agent can infer it, but there is no stated 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?

The description discloses external prerequisites (plate solution + internet), sensor-specific default tuning (Sony OSC with UV/IR cut), the fallback chain between methods, and the linear-data-only restriction. This goes well beyond annotations (destructiveHint true) by explaining what the tool actually does and what it needs before running. No contradiction with 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?

The description is compact at about 36 words and front-loads the method flow, then optional behavior, input constraint, and safety. The arrow notation is dense but every clause earns its place, balancing information density with brevity.

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 tool with 9 parameters and no output schema, the description covers the critical decision path: method selection, prerequisites, linear data, and checkpointing. It is enough to invoke minimally with just an id. It leaves advanced parameter semantics ambiguous, but those are optional and the core operation is sufficiently specified.

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 2 of 9 schema properties have descriptions (22% coverage), so the description must compensate. It does clarify the method parameter (default SPCC, fallback chain) and the neutralization behavior, but leaves narrowband, limit_magnitude, white_reference, and background_reference_id unexplained in both schema and description. This is partial, not full, compensation.

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 identifies the tool's purpose through named PixInsight color-calibration processes (SPCC, PCC, ColorCalibration) and mentions optional background neutralization. It distinguishes itself from siblings like background_neutralize by placing color calibration at the core. However, it never explicitly states a verb phrase like 'calibrate colors', relying on the tool name and process names to convey purpose.

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 explicit fallback routing: SPCC by default (requiring plate solution + internet), PCC as fallback, and ColorCalibration when no astrometry is available. It also restricts input to linear data and instructs checkpointing first, establishing clear usage windows. It does not explicitly contrast the whole tool against sibling tools such as background_neutralize or plate_solve, leaving some selection inference to the agent.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds little beyond that. It mentions 'optionally into a new view' but does not clarify default behavior (whether it overwrites the starless image) or any side effects. No contradiction, but no added disclosure of behavioral traits.

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 and is concise, but it is so brief that it sacrifices necessary detail. It is not bloated, but the sparseness is a weakness rather than a strength.

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 4 parameters, destructive behavior, no output schema, and no parameter descriptions, a one-sentence description is inadequate. It lacks information about return values, edge cases, or how the parameters interact, making it incomplete for an agent to 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 description coverage is 0% and the description provides no explanation of the parameters. While starless_id and stars_id are somewhat self-explanatory, star_boost and new_id have no meaning from the description alone. The tool completely fails to convey 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 clearly states the operation: 'Screen-blend a stars image back onto a starless image (PixelMath)' with a specific verb and resources. It distinguishes this from generic pixel_math by naming the specific image types involved, though it does not explicitly contrast with siblings like remove_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?

No guidance on when to use this tool versus alternatives. It does not mention when this is appropriate (e.g., after remove_stars), nor any prerequisites or exclusions. The description only states what it does, not when it should be chosen.

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

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

Annotations already indicate a read-only, non-destructive operation. The description adds useful behavioral context: the output is a JPEG, it is side-by-side, it uses a shared stretch, and it supports comparing against a checkpoint file. No contradiction with annotations exists.

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?

Single concise sentence with the core purpose front-loaded and no filler. It earns its place by specifying output format, input scope, comparison style, and intended use.

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

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

The tool has 9 parameters and no output schema, yet the description only covers the high-level purpose. Important invocation details such as how id_b and path_b interact, what labels mean, what max_edge controls, and how linked behaves are absent, making it incomplete for an agent to reliably call the 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 low at 22%, so the description must compensate, but it only vaguely explains id_a/id_b as views and stretch as 'same stretch'. Parameters like linked, max_edge, label_a, and label_b receive no meaningful explanation, leaving significant ambiguity 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 a specific function: producing a side-by-side JPEG comparison of two views or a view and a checkpoint file. The 'same stretch' and 'before/after checks' details differentiate it from single-view preview tools like render_preview.

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

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

The description explicitly frames the tool as for before/after checks, which is a clear usage context. It does not name an alternative tool for single-view rendering, but the two-view/checkpoint comparison scope makes the intended use 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?

Annotations already mark the tool as destructive, but the description adds meaningful behavioral context: 'in place' tells the agent the original view is mutated, and 'Checkpoints first' discloses the safety workflow. This goes beyond the annotation alone and helps an agent understand the operational impact.

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 short, purposeful phrases with no filler. The core action is front-loaded, and the checkpoint note adds critical safety information without bloating the text.

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 view-conversion tool, the essential behavior—what is transformed, in-place mutation, and checkpoint-before-run—is covered. There is no output schema, but 'in place' implies no separate returned image. Minor gaps remain around failure behavior and what happens to the existing view, but these are not critical for a tool this simple.

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 documents the checkpoint parameter, and the description's 'Checkpoints first' reinforces the sequencing. The description also implies that 'id' refers to a view, partially compensating for the missing schema description. However, it does not explain the id format or its precise role, leaving a modest gap given 50% 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 clearly states the action ('Convert'), the resource ('a view'), and the mode ('to grayscale in place'), making the tool's purpose unambiguous. It is semantically distinct from sibling operations like invert, binarize, or extract_channels, so an agent can recognize what this tool does 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?

The intended use is implied: use this when a view should be converted to grayscale. However, the description gives no explicit guidance on when to prefer this over alternative operations, nor does it mention exclusions or conditions that would make it inappropriate.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so no contradiction. The description adds valuable context beyond annotations: it operates on calibrated cfa:true frames, is async with per-frame progress, and has an approximate duration. It does not disclose exact side effects on files, but that is partially covered by annotations and the correction 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?

Two sentences with no filler. The key facts — purpose, input state, ordering, async, and timing — are 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 9-parameter tool with no output schema, the description covers the key preconditions and timing but omits any indication of return values, output location, or the role of several parameters. It is sufficient to invoke the tool blindly but not to fully understand the operation's result.

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

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

Schema description coverage is only 33%, so the description must compensate. It explains the two detection paths (master_dark and auto_detect/hot_sigma) and mentions cfa:true. But parameters like files, out_dir, wait, cold_auto, and hot_dark_level remain unexplained in both schema and description, leaving gaps for a 9-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 a specific verb+resource: 'CosmeticCorrection on calibrated (still mosaiced, cfa:true) frames' with the specific goal of fixing hot pixels via master dark and/or sigma auto-detect. It also distinguishes itself from the debayer sibling by explicitly ordering 'Run BEFORE debayer.'

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 clear context: it is for calibrated, still mosaiced frames and must run before debayer. It also notes async behavior and typical runtime. However, it does not state when not to use this tool or name alternative tools beyond the debayer ordering.

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 implies a destructive state-changing operation by advising 'Checkpoints first', and the checkpoint parameter reinforces this. This directly contradicts the readOnlyHint:true annotation, making the behavioral contract inconsistent. The description itself does not state that it mutates the target image or what else changes.

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 the core operation first and no redundant wording. It is appropriately concise and 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 rect semantics are present, but the description omits what id refers to, what the tool returns, and the full side-effect picture. The checkpoint hint is useful but does not resolve the ambiguity of which image is being cropped or whether the operation is reversible beyond that checkpoint.

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 description adds meaning for the rect parameter by defining x, y, w, h. However, id is not explained in either the schema or the description, and checkpoint is already documented in the schema. With only 33% schema description coverage, this is only partial compensation.

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 specifies the operation ('Crop') and the target shape ('rect [x, y, w, h]'), so an agent knows what the tool does. It doesn't explicitly say which image or window the crop applies to, and it doesn't distinguish itself from crop_preview or auto_crop, but the rect format gives enough core purpose clarity.

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 about when to use this tool instead of the many crop/processing siblings such as crop_preview or auto_crop. 'Checkpoints first' is a safety/workflow instruction, not a usage-selection guideline, so the agent is left to infer 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?

Annotations already declare the operation read-only and non-destructive. The description usefully adds that the output is a JPEG, that the default view is a 512 px center box, and that zoom > 1 magnifies. It does not explain stretch behavior or how the JPEG is returned, but the annotation-covered safety profile lowers the burden.

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 short and front-loaded: it states the output type and purpose first, then packs defaults, coordinate options, and zoom behavior into three tight sentences. Every clause adds operational value, and there is no redundant 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?

Core invocation details are present — required id context, center/rect alternatives, default box size, and zoom semantics — and annotations cover the safety profile. However, the `stretch` parameter is unexplained and, with no output schema, the description does not state whether the JPEG is returned inline, as a path, or as a saved artifact, leaving some ambiguity for an agent.

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 description adds meaning for center, rect, zoom, and the default size semantics, all of which the schema largely leaves undocumented. However, with only 29% schema coverage, the unexplained `stretch` enum (stf/hard/none) is a notable gap, and `stf_from_crop` is only covered by the schema. The description partially compensates but does not fully explain all 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 identifies a specific resource and outcome — a '1:1 (or zoomed) JPEG of a region' — and gives a concrete inspection use case ('for star shapes, halos, ringing, noise texture'). It is clear about what the tool produces, though the verb is implicit and it does not explicitly contrast with sibling render/crop 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 communicates the intended context: pixel-level visual inspection of stars and artifacts, which implies when to use it versus full-frame rendering or statistical measurement. It does not mention exclusions or name alternatives like render_preview or crop, but the context is clear and not misleading.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the basic behavioral profile is covered. The description adds that it is a non-linear stage and says 'Checkpoints first', reinforcing the destructive nature and suggesting safe usage. It does not contradict annotations and adds moderate context.

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

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

The description is very short and front-loaded with the core purpose and parameter format. Each clause contributes: transformation type, parameter format, stage, and checkpoint instruction. Minor structural issues include fragmentary phrasing ('CurvesTransformation:') and the terse 'Checkpoints first' that could be clearer, but overall it is efficient and relevant.

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 complexity of the tool (5 parameters, nested objects, no output schema) and low schema documentation, the description handles the main options but still lacks important context. It does not state how the parameters interact (e.g., whether curves and contrast can be combined), what the 'id' refers to, or what happens to the target image beyond being destructive. The 'non-linear stage' and 'checkpoints first' give pipeline context, but significant gaps remain.

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 only 20%, so the description carries the main semantic burden for parameters. It explicitly provides the structure of the curves parameter with a concrete example, and specifies the valid ranges for contrast and brightness (-1..1). It also implies an 'or' relationship between explicit curves and convenience adjustments, which is not clear from the schema alone. It does not explain the 'id' parameter, but the description compensates for the low 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 states a clear operation: applying explicit curves per channel or convenience contrast/brightness, and identifies it as a non-linear stage. It provides a concrete example of the curves format, which distinguishes it from a vague image operation. It does not explicitly differentiate from sibling tools, but the meaning is unambiguous.

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

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

The description indicates the tool is a non-linear stage in a processing pipeline and instructs 'Checkpoints first', which is a clear operational guideline. It mentions the convenience contrast/brightness as an alternative to explicit curves, but does not specify when to choose this tool over sibling tools like stretch or saturation. Exclusions and alternatives to other tools are not explicitly 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 meaningfully adds behavior beyond the annotations by stating 'Async with per-frame progress.' It also warns about source-pattern handling ('Auto reads BAYERPAT'). However, it does not disclose what side effects occur on disk, how output paths are determined, or what happens if no pattern can be detected, so the behavior is only partially 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?

Every sentence in the description earns its place: action, allowed methods, default, pipeline position, and async behavior are all packed into two short lines. It is structured and front-loaded, with no filler 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 five-parameter tool with no output schema and 0% schema descriptions, the description is not complete enough for an agent to invoke it correctly without guessing at files, wait, and out_dir semantics. The workflow ordering and async note help, but the lack of output/behavior detail and parameter guidance leaves important gaps.

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

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

Schema description coverage is 0%, and the description must compensate for five parameters. It does enrich two of them: 'VNG (default)' clarifies the method enum and 'pattern Auto reads... ASI2600MC = RGGB' explains the pattern default, but files, wait, and out_dir receive no semantic guidance.

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 ('Debayer CFA frames'), the input resource, and the algorithm choices, with a concrete pattern example (ASI2600MC = RGGB). It also places the tool in the pipeline ('Run AFTER cosmetic correction'), which clarifies it among the large set of sibling image-processing 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 explicitly says when to call it ('Run AFTER cosmetic correction') and indicates the default method, which is a clear workflow placement. It does not explicitly exclude any alternative or describe when another tool should be used, but the pipeline ordering is enough to remove a major ambiguity in this processing chain.

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

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

Annotations already mark the tool destructive and non-readonly, and the description adds substantial behavioral context: it is async-ish, can take minutes, checkpoints first, deringing is on, and dark-ring artifacts should be inspected afterward. Nothing in the description contradicts the 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?

Three dense sentences: implementation selection, post-check advice, and execution behavior. Every sentence carries useful information with 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?

The description covers algorithm, fallback, safety, artifact checking, and timing, which is strong for a mutating async tool. But with no output schema and an 'async-ish' promise, it does not specify what the tool returns, how to monitor completion, or whether it modifies the image in place; the agent must infer these from sibling job/status tools.

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

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

With schema coverage at only 18%, the description partially compensates by connecting fwhm_px to measured FWHM, clarifying correct_only mode, and describing the BXT/native fallback relevant to method. However, most parameters—iterations, adjust_halos, sharpen_stars, sharpen_nonstellar, and deringing_dark—receive no semantic explanation in either the schema or the description.

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

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

The description states a concrete operation—deconvolution—and goes beyond the name by specifying exact implementation details: BlurXTerminator when available, otherwise native Richardson-Lucy with a PSF derived from measured FWHM. This is specific enough to distinguish it from sibling sharpening/blurring 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 gives clear context for choosing the internal mode (BXT if installed, native fallback) and targeted workflow advice such as using correct_only for the linear stage and checking crop_preview for dark rings. It stops short of explicitly saying when to prefer deconvolve over sharpen or other alternatives, so it is not a full when/when-not guide.

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?

It adds context about algorithm fallback behavior and the checkpoint-before-running step, which complements the destructiveHint annotation. But it does not disclose that the tool likely modifies the active image, what the operation produces, or the full impact of the checkpoint 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 terse sentences convey the key algorithm-selection logic and a critical safety instruction with no filler. Every clause carries information, and the most important behavioral detail 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 is too cryptic for a destructive, 7-parameter tool with a nested params object and no output schema. It omits the target of the operation, the conditions for using denoise versus its many siblings, and the post-operation state, leaving substantial gaps for an agent to fill.

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 description adds meaning to the strength and NXT-specific parameters by linking them to linear/non-linear algorithm selection. It does not explain the id, params object, or checkpoint parameter beyond the schema's own descriptions, and with only 57% schema coverage, this is only partial compensation.

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 identifies specific denoising processes (NoiseXTerminator, MultiscaleLinearTransform, TGVDenoise) and a strength range, so an agent can infer the tool's purpose. It does not explicitly state 'denoise the active image' or differentiate from sibling processing tools, leaving some 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 description gives explicit internal selection rules: use NXT if installed, else MLT for linear data or TGV for non-linear, plus a 'checkpoints first' instruction. However, it does not explain when to choose denoise over sibling tools like deconvolve or blur, nor when it should not be used.

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?

'Async' is a genuine behavioral disclosure not present in the annotations, warning the agent that completion must be checked separately rather than awaited synchronously — important because readOnlyHint=false only signals a non-read operation, not asynchronicity. The note that inputs come from register and are updated by integrate adds useful lifecycle context. It is consistent with the annotations and contradicts nothing, though it stops short of describing side effects or how completion is signaled.

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, each adding distinct information: input source, prerequisite plus scale semantics, and async behavior. No filler or repetition of the tool name, and the key constraint is front-loaded. The dense parenthetical 'CFA-free super-sampling of rejection' sacrifices readability, so it is efficient but not maximally clear.

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 asynchronous tool with seven parameters and no output schema, key operational facts are missing: how an agent detects completion (siblings job_status and job_wait exist but are not referenced), what the result is and where it is written, and the meaning of four parameters. The description covers the input source and one prerequisite, which is insufficient for a tool of this complexity.

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

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

With only 29% schema description coverage, the description carries much of the parameter-documentation burden and does add real value for scale, glossing the cryptic 1/2 enum values as 'CFA-free super-sampling of rejection' versus 2. It also clarifies the origin and default of xdrz_files through its workflow sentence. But out, kernel, keep_open, and use_local_normalization remain unexplained in both schema and description, so the compensation is only partial.

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 identifies a concrete process — DrizzleIntegration — and its input resource (.xdrz files), and situates it in the pipeline by noting these files are 'written by register and updated by integrate,' which distinguishes it from siblings like integrate and fast_integrate. However, the noun phrasing 'DrizzleIntegration' instead of an explicit verb such as 'perform' or 'combine,' plus dense jargon like 'CFA-free super-sampling of rejection,' makes the purpose less accessible to a non-domain agent.

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 requirement of 'dithered subs' is an implicit precondition that tells an agent when this tool is appropriate, but the description never explicitly contrasts it with alternatives such as integrate, fast_integrate, or local_normalization. There is no 'use X instead when...' routing guidance. The mention of the register-to-integrate file lifecycle implies a workflow position, but leaves the decision of when to choose this over plain integrate 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?

Annotations already signal mutation without destruction; the description adds 'deep-copy' and 'no history', explaining the key effect on the new window and implying the original view is left intact. It does not contradict the annotations and adds useful behavioral nuance beyond readOnlyHint/destructiveHint.

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 clauses communicate the action, an important behavioral caveat, and a usage tip with no filler. Front-loaded action and caveat make it highly scannable.

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

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

The description covers purpose and primary behavior, and annotations cover the safety profile. However, with no output schema and no parameter explanation, an agent still lacks explicit documentation for the required id and optional new_id, so completeness is partial.

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 two parameters, id and new_id, have no schema descriptions and the description does not mention them. An agent must infer from property names alone that id identifies the source view and new_id names the new window; this is likely but undocumented.

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

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

States a precise action ('deep-copy a view into a new window') and an explicit qualifier ('no history') that distinguishes it from simple open/close window tools. The phrase 'Use before experimenting' reinforces that this is a duplication action for safe exploration. No ambiguity about the core operation.

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?

'Use before experimenting' is a clear directive for when to invoke the tool. It does not name alternative tools or explicitly exclude cases, but the experimental-safety context is sufficient for a simple utility.

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

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

Annotations already mark the tool as non-read-only and non-destructive. The description adds that the change is deferred until pipeline_run/stack and is reversible by passing an empty list, which is useful behavioral context beyond the annotation flags.

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 compact sentences front-load the core action and then state timing and clearing behavior. Every clause contributes meaningful information without padding.

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

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

For a simple two-parameter tool with no output schema, the description covers the essential behavior, timing, and reset path. It is nearly complete, though the optional reason parameter is not described and persistence/save implications are left implicit.

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

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

With 0% schema description coverage, the description must carry parameter meaning. It does clarify that indexes are blink indices and that an empty list clears exclusions, but it leaves the optional 'reason' parameter entirely unexplained.

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: 'Drop frames (by blink index) from the light group before stacking.' This clearly identifies the tool's function and distinguishes it from frame-review tools like blink_frames or scan_frames by tying the action to a stacking exclusion list.

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

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

It gives explicit context for use: the exclusion list is 'applied by pipeline_run / stack,' so agents know this tool configures a future step rather than acting immediately. It also explains how to clear the list, but it does not explicitly name an alternative or say when not to use it.

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

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

Annotations mark the operation as non-read-only and non-destructive, and the description adds the useful behavioral detail that results are placed into new views. However, it does not disclose side effects, required input state, or failure 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 short and front-loaded with no filler, but it reads more like a label than an explanatory definition. It is concise without being informative.

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, no parameter documentation, and no usage guidance, the one-phrase description leaves an agent guessing about inputs and expected behavior. It provides only the high-level result of producing new views.

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

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

Schema description coverage is 0%, so the description must compensate, but it only hints at channel/color-space content. It does not explain id, prefix, or the expected values for channels and color_space.

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 channel extraction into new views and names example channel types (RGB / CIE L), making the tool's purpose reasonably clear. It does not use a direct verb phrase, but it is specific enough to distinguish from general image-processing 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?

There is no guidance about when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned. The intended usage must be inferred from the tool name and 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?

The description adds some behavioral context beyond annotations, notably that the operation is asynchronous and performs registration and integration in a single pass. However, it does not describe side effects, output behavior, or what happens to input files, which would be useful given readOnlyHint=false.

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 with no filler. It front-loads the core purpose of the tool, then explains scope and usage context, and ends with the async qualifier. 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?

While the purpose and usage context are clear, the description is incomplete for a tool with four parameterscars and zero schema descriptions. No output schema exists, and the agent is left without parameter semantics, prerequisites, or expected outcomes, making correct invocation uncertain.

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

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

Schema description coverage is 0%, and the description provides no explanation of any of the four parameters: files, out, keep_open, or reference. This leaves the agent without meaningful guidance for constructing a valid 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 names a specific verb ('Quick-look stack'), a specific method (FastIntegration), and explicitly states what is included (registration + integration in one pass) and excluded (no drizzle, no LN). This clearly distinguishes it from related siblings like integrate, drizzle_integrate, and register.

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 context for when to use the tool: 'Good for a 2-minute sanity check of a night's data.' It does not name alternatives or explicitly state when not to use it, but the quick-look framing implies it is not for full-quality final integration.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context: the output includes raw header cards plus a parsed frame record stored elsewhere, and that no PixInsight session is required. It does not go deeper into things like encoding, error conditions, or limits, but for a simple read-only tool this is reasonable.

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

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

The description is a single, compact sentence with no filler. It front-loads the main output and adds the important 'no PixInsight needed' qualification 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 tool with one parameter knob, strong read-only annotations, and a clear output statement, the description covers the essential decision and invocation context. It explains what the caller receives and hints at the non-PI prerequisite. A slightly more explicit statement about 'path' being a filesystem path would make it 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 0%, so the description must compensate for the undocumented 'path' parameter. It clarifies that the parameter refers to a single file whose header cards will be returned, which is helpful. It does not specify path format, file type validation, or whether directories are acceptable, leaving some ambiguity.

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 identifies the resource ('Raw FITS header cards of one file') and the second output ('the parsed frame record'), making the tool's purpose clear. It lacks an explicit verb like 'get' or 'read', but the meaning is unambiguous. It does not explicitly distinguish itself from siblings such as image_keywords, though 'no PixInsight needed' hints at a key 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?

The phrase 'no PixInsight needed' implies this tool is appropriate when the caller wants FITS header data without running a PixInsight session. However, it does not explicitly state when to prefer this over sibling tools like image_keywords or when not to use it. The guidance is present but largely 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?

Annotations already mark this as destructive, and the description reinforces this with 'Checkpoints first.' It also discloses the dry_run behavior (reports DBE sample layout) and the expected post-invocation action (look at the preview). This is useful behavioral context beyond the 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?

Three compact sentences carry the core action, method selection, and workflow guidance without repetition. The method parenthetical is dense but every clause earns its place, and the most critical safety instruction appears early.

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 destructive 12-parameter tool with no output schema, the description supplies method routing, workflow state, and safety behavior. Minor gaps remain around the exact meaning of subtract versus divide correction and the role of the required id, but an agent has enough context to invoke and validate the operation 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 67%, so the description must add value. It clarifies the method enum values, their defaults and preferences, explains what dry_run reports, and introduces checkpoint behavior. It does not explain the correction subtract/divide enum, which would help the agent choose correctly, but the covered parameters are substantially enriched.

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: 'Remove light-pollution gradients on a LINEAR image.' It meaningfully distinguishes the tool from sibling operations like background_neutralize and color_calibrate by focusing on spatial gradients rather than color casts, and it differentiates internal methods (DBE, GradientCorrection, ABE).

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 selection guidance: DBE is the user's preferred method, GradientCorrection is the default when DBE is not requested, and ABE is an alternative. It also tells the agent to checkpoint first and inspect the preview afterwards. It does not, however, state when to avoid this tool in favor of a sibling like background_neutralize.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds one behavioral constraint: the frame group must come from the last scan. It does not describe the exact return structure, path format, or behavior for an invalid group_id, but the annotations reduce the burden.

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

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

The description is a single concise sentence with no filler or repeated information from the schema. It places the key scoping detail ('from the last scan') at the end, but the sentence is short enough that this is not a significant issue.

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 read-only tool with one parameter, the description gives the core return concept (file paths) and an important scope limitation (last scan). However, with no output schema, it does not specify whether the result is a list, how paths are formatted, or what happens when group_id does not match the last scan. It is minimally adequate but not 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 0%, so the description carries the burden of explaining group_id. It only says 'a frame group,' which weakly maps group_id to a frame group identifier. It does not explain how to obtain group_id, what values are valid, or how it relates to the last scan.

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 resource and scope: the file paths belonging to a frame group from the last scan. Although it lacks an explicit verb like 'get' or 'list,' the noun-phrase form still communicates a retrieval action. It is specific enough to distinguish from scan_frames and other frame-processing 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?

The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions. The phrase 'from the last scan' implies a temporal constraint, but the agent is left to infer that this tool is for retrieving paths after a scan. There are no named sibling alternatives or conditions.

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

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

Annotations already declare destructiveHint=true, and the description's 'Checkpoints first' instruction aligns with and reinforces that destructive behavior, adding practical advice. It also clarifies the intended image state (non-linear) and the target (bright cores), which goes beyond the annotation. No contradiction; the description adds extra behavioral context without conflicting with structured hints.

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 concise sentences with no fluff. The purpose is stated first, followed by a critical prerequisite ('Checkpoints first'). Every word earns its place, and the structure front-loads the core function.

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

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

For a tool with 5 parameters, nested objects, and no output schema, this description is too brief. It provides purpose and a precondition but omits essential details: how the image is modified, what the parameters do, return behavior, and when it is appropriate relative to other processing steps. The annotations cover destructiveness but not operational completeness. Given the tool's complexity, key information 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 40% (only 'params' and 'checkpoint' have descriptions). The description does not explain any parameters—neither id, layers, iterations, nor the semantics of the params object. Since coverage is low (<50%), the description should compensate, but it is silent on parameters, leaving the agent to infer from names alone. This is a clear gap.

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

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

The description clearly states the tool applies HDRMultiscaleTransform to recover bright cores (galaxy cores, nebula centres) on non-linear images. It names a specific verb, algorithm, and target, making the purpose unambiguous. It does not explicitly differentiate from siblings, but the specialized nature (HDRMultiscaleTransform for bright cores) is distinct enough among the many processing 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 provides a usage context: it is meant for non-linear images and advises 'Checkpoints first,' implying a pre-execution safety step. However, it does not explicitly state when to use this tool versus alternatives (e.g., other HDR or stretching tools) or when not to use it. The guidance is present but shallow, lacking exclusions or comparisons.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the 'Read-only' statement adds little. The description does add useful context: histograms are per-channel and default to 256 bins. However, it does not disclose return format, behavior when bins is omitted, or how channels are represented.

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 very short and front-loaded with the core purpose. The final 'Read-only' is somewhat redundant with the readOnlyHint annotation, but it does not add meaningful bloat. Overall it is efficient and scannable.

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

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

For a simple read-only tool with two parameters, the description gives enough to guess the basic call, but it lacks details about the return structure, channel ordering, or how the bins parameter is applied. With no output schema, a bit more context about the returned histogram data 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?

Schema description coverage is 0%, so the description must compensate. It adds meaning for bins by noting the default of 256, and 'for a view' gives some context for the id parameter. However, it does not explicitly define id as a view identifier or explain how bins affects the output beyond bin count.

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 that the tool produces per-channel histogram counts for a view and mentions the default of 256 bins. It lacks an explicit verb like 'compute' or 'return,' and it does not explicitly distinguish itself from close siblings such as image_statistics, but the histogram concept is specific enough to be identifiable.

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 image_statistics or scan_frames. It only says 'for a view' and 'Read-only,' which implies a safe inspection use case but does not state exclusions or mention a better-suited 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful context about what data is returned and that it concerns an open view. It does not describe output structure, error conditions, or how the view is selected, but the read-only safety profile is already covered by 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?

The description is a compact, front-loaded phrase with no filler or redundant content. Every word contributes to identifying the resource and the returned data categories.

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 read-only tool with one parameter and no output schema, the description provides the essential domain context and data categories. However, it leaves the id parameter semantics underspecified and does not describe expected return structure, which keeps it from being 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?

The input schema provides no description for the single required 'id' parameter and schema coverage is 0%. The description implies that the id refers to an open view, which is helpful, but it does not explain where such an id comes from, its format, or how it maps to a specific view.

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 resource (an open view) and the specific data returned (FITS keywords, XISF properties, astrometric solution summary), making the tool's purpose understandable despite lacking an explicit verb. It is distinguishable from many siblings by naming these metadata categories, though it does not explicitly contrast with fits_header.

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 'of an open view' supplies an implied prerequisite, indicating the tool applies to a currently open view rather than an arbitrary file. However, it gives no explicit guidance about when to choose this over related tools like fits_header or image_statistics, and no exclusions are stated.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, and the description repeats 'Read-only' without adding much beyond that. It adds some context by framing the tool as a post-processing check, but it does not disclose new behavioral traits like side effects, rate limits, or data dependencies.

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-loads the metric list, which is the core value. The 'Read-only' phrase is redundant with annotations but harmless; overall every sentence contributes.

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 lists the expected output metrics, which is helpful since there is no output schema, but it does not explain how the 'id' parameter selects the image or that 'rect' restricts the region. For a tool with four parameters and rich output, this is adequate but not 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 coverage is 75% with direct descriptions for rect, clip_low, and clip_high; the remaining id parameter lacks schema guidance and is not clarified in the description. The description's mention of clipped and saturated counts loosely relates to clip thresholds, but it does not explain 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 clearly identifies the tool as computing per-channel statistics (median, MAD, mean, σ, min/max, clipped counts, noise estimate, etc.), which makes the purpose obvious. It does not name a sibling tool explicitly, but the metric list differentiates it from tools like histogram 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 description gives explicit usage context with 'Use after every stretch/sharpen step,' which tells agents when to call it. It does not name alternatives or state when not to use it, but the timing guidance is clear and operational.

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

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

Annotations already indicate non-read-only and non-destructive, and the description adds significant behavioral context: it states 'ALWAYS async' (a critical execution trait), the refusal condition for fewer than 3 frames, and that it reports rejected-pixel percentage (useful for diagnosing input quality). These go beyond the sparse annotations, though it doesn't describe all side effects or output details.

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 single sentence packed with information, avoiding fluff. It front-loads the primary purpose and then cascades through algorithmic rules. While it's structured as a run-on, it is still efficient and every clause contributes meaning. It could benefit from bullet points, but for the information density it remains 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 (14 parameters, no output schema, sparse annotations), the description covers the core algorithmic decisions and key constraints but leaves many parameters unexplained (e.g., sigma_low, sigma_high, lnorm_files, drizzle_files, large_scale_clip_high). An agent may struggle with advanced configurations, but the description is sufficient for standard integration tasks with defaults.

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

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

With schema description coverage at only 36%, the description compensates by explaining key parameters: rejection algorithm based on frame count, normalization behavior (additive+scaling or LocalNormalization), and weight source (SSWEIGHT or PSF). It also explains the 'force' param via the refusal condition. However, it doesn't cover many other parameters like sigma_low, drizzle_files, or keep_open, so it's not complete but does add substantial value for critical 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 clearly states 'ImageIntegration of registered frames → master light .xisf', identifying the verb (integrate), resource (registered frames), and output (master light). It is specific and unambiguous, but it does not explicitly differentiate from siblings like fast_integrate or drizzle_integrate, so it earns a 4 rather than a 5.

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

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

The description provides operational constraints ('Refuses < 3 frames without force', 'ALWAYS async') but offers no guidance on when to choose this tool over alternatives such as fast_integrate or drizzle_integrate. There is no mention of when-not or preferred alternatives, leaving selection entirely to the agent's 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?

The annotations already flag destructive behavior (destructiveHint: true). The description adds the useful behavioral note that a checkpoint happens first, which complements the destructive annotation rather than contradicting it. It does not go into further depth about in-place modification, but the simple nature of 'invert' makes that less critical.

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 that each carry useful information. There is no filler or redundancy, and the core 'invert a view' 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?

For a simple single-resource operation, the definition is nearly complete: purpose, target use, destructive safety, and a checkpoint instruction are all present. The main gap is that 'id' is not described, but its role is inferable from 'view' and the required parameter is clearly named in 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?

The description adds no real meaning beyond the input schema. 'Checkpoints first' merely echoes the checkpoint parameter's existing schema description, and the required 'id' parameter is left completely undescribed in both the schema and the description. With 50% schema coverage, the description should compensate but does not.

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

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

'Invert a view (useful on masks)' states a specific verb and resource, and the parenthetical gives a concrete use case. It is not tautological and is distinct enough from the many sibling image-processing tools, though it does not explicitly name a 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?

The description indicates which target it is useful for ('masks') and provides the operational guidance 'Checkpoints first,' which is especially relevant because the annotations mark this as destructive. It lacks an explicit when-not-to-use or comparison to alternatives, so it stops short of a 5.

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

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

Annotations already indicate destructiveHint=true, but the description adds essential behavioral nuance: cancellation is not instantaneous for per-frame operations and is impossible for ImageIntegration. This gives the agent the critical context it needs beyond the annotation.

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

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

Two sentences deliver the core purpose, the behavioral scope, and the alternative tool with no wasted words. The primary action is front-loaded, and the exception is stated immediately after.

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 cancellation tool with no output schema, the description covers purpose, cancellation semantics, and the key alternative. It does not mention what response or status is returned, but that is a minor gap given the simplicity of the operation and the availability of separate job_status/job_wait tools.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented job_id parameter. It does not explain how to obtain or format job_id, nor does it state that it is the identifier of the job to cancel. The meaning is inferable from the tool name, but the description itself adds no parameter-level guidance.

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 ('Request cancellation') and then clarifies the exact behavior: per-frame operations stop at the next frame, while ImageIntegration is not interruptible. It explicitly distinguishes this tool from pi_stop, so an agent can identify it among the many sibling 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 gives clear when-to-use guidance by naming which jobs can be canceled (per-frame operations) and explicitly stating that a running ImageIntegration cannot be interrupted, directing the agent to 'use pi_stop mode:"kill"'. This is an explicit exclusion and alternative in one concise statement.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool's safety is clear. The description adds valuable behavioral context: it streams live while running and extracts rejection lines when present. This goes beyond the annotations and helps the agent understand what to expect. However, it does not mention behavior when the job is not running or error handling, which prevents a higher score.

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 exceptionally concise: two sentences with zero fluff. The main purpose is front-loaded, and the extra rejection-line extraction detail is added without redundancy. Every word earns its place.

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

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

For a simple tool with no output schema, the description covers the core functionality (tail of log, streaming, rejection lines) but leaves gaps: it does not describe the return format (e.g., plain text, structure), behavior when the job finishes, or how to interpret rejection lines. Given the availability of sibling tools like pi_console_log, more clarity on when this is the right tool 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 input schema has 0% description coverage, so the description must explain both parameters. It implicitly explains job_id via 'for a job', but it does not explain the 'tail' parameter at all. The description says 'Tail of the console log' but does not clarify that the 'tail' parameter controls the number of lines returned. This is a significant gap given the lack of 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 description clearly states it is a tail of the PixInsight console log for a job, with the additional feature of extracting ImageIntegration rejection lines. The verb 'tail' and resource 'console log for a job' are specific, and the scope is unambiguous. It does not explicitly differentiate from sibling tools like pi_console_log, but the 'for a job' qualifier provides some distinction.

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 explicit guidance on when to use this tool versus alternatives such as pi_console_log or job_status. The description implies usage for monitoring a job's log output ('streams live while running') but does not state when not to use it or mention any alternative. This leaves the agent to infer the appropriate 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?

Annotations already mark it read-only and non-destructive; the description adds that it is non-blocking and meant to be polled, and enumerates the progress/result fields returned. This is useful context not present in the annotations. It does not detail failure/error semantics, but for a read-only status check that is a minor gap.

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

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

Two short sentences front-load the returned data and then give the polling cadence/alternative. Every phrase earns its place, with no boilerplate or repetition of the title.

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?

It covers what the tool returns (status, progress fields, result), how often to poll, and the blocking alternative, which is adequate to call it correctly. There is no output schema, so the explicit progress/result list is valuable. It omits status enumerations and error cases, but those are not essential for a simple polling call.

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

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

The only parameter, job_id, has no schema description (0% coverage), but its purpose is closely inferable from the tool description's reference to 'an async job'. The description does not explicitly state that job_id must be the ID returned when launching the job, so it only partially compensates for the low schema coverage. The single self-evident parameter keeps this from being a 2.

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 identifies the tool as returning status, progress (current/total, percent, ETA), and result for an async job, which is specific enough to distinguish it from a generic status endpoint. It also names job_wait as the blocking alternative, making the boundary with a key sibling clear. It lacks an explicit verb like 'get' or 'retrieve', and does not separate it from job_log, so not a perfect 5.

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

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

It gives concrete polling guidance ('Poll every 10–30 s for long jobs') and explicitly points to job_wait as the alternative when blocking is preferred. This tells the agent both how and when to invoke it. No exclusion criteria are given, but the core routing question is answered.

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 annotations already declare read-only and non-destructive behavior, and the description adds the blocking nature, the max_seconds bound, and what it returns. It does not detail timeout or error behavior, but the core non-obvious behavior is clearly disclosed.

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

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

The description is two sentences with no filler. The most important behavioral point, blocking and the time bound, is front-loaded, and the guidance about job_status polling is 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?

For a simple read-only wait tool with no output schema, the description covers the main behavior, the key parameter, and the alternative tool. It does not describe the exact shape of the return value or failure cases, but these are less critical given the annotations and the tool's simplicity.

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 provides only names, types, and constraints but no semantic explanations. The description adds meaning for max_seconds ('Block up to max_seconds') but leaves job_id unexplained, though its purpose is inferable from the tool name. This is partial compensation for the 0% schema description 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 uses a specific verb ('Block') with a clear resource ('a job') and describes the outcome: it returns the final result or latest progress. It also distinguishes this tool from job_status by framing it as a waiting operation rather than a polling check.

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

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

The description explicitly says 'Prefer this over tight job_status polling,' giving the agent direct guidance on when to select this tool over its nearest sibling. It does not spell out a when-not-to-use case, such as 'if you only need current status without waiting,' so it falls just short of a 5.

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

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

The description's 'Checkpoints first' adds a warning that aligns with the destructiveHint annotation, providing actionable pre-call guidance. However, it does not state what exactly is mutated or what a linear fit does to the view beyond 'match channel/sessions.' Since annotations already declare destructiveness, this partial addition earns a 3.

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 concise, two-clause sentence captures the core action and immediate safety warning. No extra words, front-loaded with the purpose. It is clear and efficient.

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

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

Given the tool's complexity (3 params, destructive behavior, no output schema), the description is minimal but still lacks clarity on what exactly gets transformed and how 'match channel/sessions' translates into action. It does not clarify the process enough for an agent to anticipate consequences beyond the checkpoint hint.

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 only 33% (only 'checkpoint' has a description). The tool description fails to explain the id, reference_id, or checkpoint semantics in more detail; 'reference view' hints at reference_id but does not elaborate on the id field or checkpoint meaning. This leaves critical parameters underdocumented.

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 action ('LinearFit the view') and a target ('a reference view (match channel/sessions)'). It tells the agent what the tool does and its scope, but does not explicitly distinguish it from siblings like match_calibration. Still clear enough for an agent to infer the operation.

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 such as match_calibration or register. 'Checkpoints first' is a caution, but it does not explain when the tool is appropriate or when another tool should be chosen instead.

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 annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the session-scoped nature of checkpoints, but it does not describe output format, ordering, or how results relate to restore_checkpoint.

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 short phrase with no wasted words. It is easy to scan, but it is a sentence fragment rather than a complete instruction, which slightly reduces structural quality.

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 tool with non-destructive annotations, the description is mostly complete. It names the resource and scope, though it could better specify what data is returned for each checkpoint and how the list supports restore_checkpoint.

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 schema description coverage is 100%, so there is no parameter information the description must add. The parameterless baseline 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 phrase 'Checkpoint files in the current session' identifies the resource and scope, and the tool name supplies the 'list' verb. It is distinguishable from siblings like checkpoint, restore_checkpoint, and undo, though the description itself omits an explicit verb.

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 given for when to use this tool versus alternatives such as restore_checkpoint or checkpoint. The only contextual hint is 'current session', which is scope information but not usage guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the scoping detail that jobs are 'submitted by this server process' and lists the returned fields, which is useful. It does not disclose behavior like whether active_only defaults to false, pagination, or ordering, but the annotations lower the bar.

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, front-loaded with the verb and resource, and includes the key output fields. 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 simple list tool with one optional boolean parameter and read-only annotations, the description is mostly adequate. However, it does not explain the meaning of active_only or the return format beyond field names, and there is no output schema. Given the low complexity, this is a minor gap, but the description could be more complete by noting the default behavior of active_only.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter 'active_only'. The description does not mention active_only at all, leaving its meaning to the schema (which only says it's a boolean). Since there is only one parameter and its name is fairly self-explanatory, the gap is moderate, but the description adds no parameter-level meaning.

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 ('List') and resource ('jobs submitted by this server process') and includes the fields returned (id, op, status, progress). It is clear about what the tool does, though it does not explicitly differentiate from sibling tools like job_status or job_wait, which are also job-related.

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

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

The description implies usage: it lists jobs submitted by this server process, which suggests it is for viewing jobs from the current process. However, it does not explicitly state when to use this tool versus alternatives like job_status (for a specific job) or job_wait (to wait for completion). The context is clear but exclusions are absent.

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

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

Annotations already declare this a read-only, non-destructive operation, so the description only needs to add context. It adds the content-addressing key set, but it also mentions dimensions not present in the input schema (offset, binning, temperature, source frames), which slightly muddies expected behavior; return format and filtering semantics are not disclosed.

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

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

A single compact sentence with no filler. The key scoping idea is front-loaded, and the parenthetical adds detail without bloating the description, though starting with an explicit verb would improve structure.

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 read-only list operation with no output schema and optional parameters, this is minimally adequate. It fails to state whether the parameters act as filters, what the returned master entries include, or how the listed addressing dimensions relate to the schema, leaving some ambiguity.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining the four parameters. It provides a general 'content-addressed by...' clue and names camera/gain/exposure, but it does not map parameters to behavior, clarify that all are optional filters, or explain 'kind'.

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 identifies the resource (master library) and the operation (return its contents), and the parenthetical clarifies the addressing scheme. It is clearly distinct from sibling tools like build_master_bias or list_jobs, though it omits an explicit imperative verb like 'List'.

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

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

There is no guidance about when to use list_masters versus alternatives such as match_calibration, scan_frames, or the build_master_* tools. The usage context is only implied by the name and the words 'master library contents', with no 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?

Annotations already signal read-only/non-destructive behavior. The description adds a concrete return contract by naming the fields provided (linear guess, astrometric solution, mask, etc.), which is useful beyond the annotations. It does not discuss edge cases like no open windows, but that is a modest gap for a no-argument read-only 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 very short with no redundant words or filler. However, the opening fragment is grammatically ambiguous, sacrificing clarity for brevity, so it is not a perfect 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?

For a parameterless, read-only list operation, the field list plus annotations give an agent most of what it needs. The main omission is an explicit statement that the tool enumerates all currently open windows/views, which would have removed the ambiguity around 'Open image windows/views'.

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 coverage is complete, so there is no parameter-semantic burden on the description. 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 identifies the resource ('image windows/views') and the returned fields (id, size, colour space, bit depth, file path, linear guess, astrometric solution, mask), but it never uses an explicit verb like 'list' or 'return'. The opening phrase 'Open image windows/views' can be read as a noun phrase or as an action, which creates ambiguity and does not clearly distinguish it from 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?

There is no guidance about when to use this tool, what conditions apply, or which alternatives to choose. Given many sibling tools (open_image, duplicate_window, image_keywords), an agent is not told why list_windows is the right selection.

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 annotation already marks the tool as destructive, and the description adds a practical safety-related instruction to checkpoint first. It does not contradict the annotations, but it gives little additional behavioral detail about what the equalization actually changes or how it affects 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 extremely short, front-loads the core algorithm, and includes the operational warning 'Checkpoints first' without wasted words. It is more terse than ideal, but every part 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 destructive image-processing tool with five parameters and no output schema, this description is incomplete. It conveys the algorithm and a checkpoint prerequisite, but omits parameter semantics, expected effects, and any guidance on selecting or invoking the operation 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 only 20%: only 'checkpoint' is documented. The description does not explain the meaning, units, defaults, or relationships of 'amount', 'radius', or 'slope_limit', so it fails to compensate for the schema's low coverage. This leaves an agent with little semantic grounding for the key adjustment 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 identifies the operation as LocalHistogramEqualization and notes it is non-linear, which clearly signals local-contrast enhancement through histogram equalization. It lacks an explicit verb and does not distinguish itself from siblings like local_normalization, but the intent is not vague or tautological.

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 instruction 'Checkpoints first' provides a clear procedural prerequisite, which is useful for a destructive operation. However, it does not explain when to choose this tool over alternatives such as local_normalization, curves, or stretch, so the when-to-use 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?

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the description is not contradicting them. The description adds useful behavioral context: it is async and per-frame, and it produces .xnml files. However, it does not disclose what happens to existing outputs, whether it overwrites files, or what the output format/return value is.

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 filler. It front-loads the core purpose and adds the async/per-frame behavior efficiently. It could be slightly more structured, but it 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 tool with 4 optional parameters and no output schema, the description gives enough to understand the general purpose and pipeline position. However, it lacks details on how the tool reports completion (async), what the .xnml output is used for, and whether there are any side effects on existing files. An agent might need to inspect the schema or logs to fully understand the behavior.

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

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

Schema description coverage is 75%, so the schema already documents most parameters. The description adds context that 'files' defaults to registered outputs and 'reference' defaults to the registered reference frame, which is helpful. However, it does not explain the meaning of 'scale' or 'out_dir' beyond what the schema provides.

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 ('LocalNormalization') and resource ('.xnml' files of registered frames against the reference), and mentions it feeds integrate/drizzle. It is clear enough to distinguish from siblings like gradient_correction or integrate, though it doesn't explicitly name a 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?

The description implies usage context: it operates on registered frames and feeds integrate/drizzle, so an agent can infer when to call it. However, it does not explicitly state when to use this tool versus alternatives like gradient_correction or integrate, nor does it mention prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context by stating that the tool reports whether a mask is present ('if any') and whether it is enabled/inverted, going beyond the 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?

A single, compact sentence that packs in the key facts: the resource (window), the queried attribute (attached mask), and the specific details (enabled/inverted). There is no redundant or filler 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 simple one-parameter read-only query, the description covers the return concept reasonably well even without an output schema. However, it omits explicit parameter semantics and any usage context, leaving minor but real gaps for an agent deciding whether and how to call 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?

There is only one parameter, id, with no schema description and 0% schema_description_coverage. The description implies that id refers to a window because it says 'attached to a window', but it does not explicitly state that id is the window identifier. This is inferable but not fully explicit.

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 what is reported: which mask is attached to a window and its enabled/inverted state. It lacks an explicit imperative verb such as 'get' or 'list', but the query phrasing makes the purpose unambiguous and distinguishes it from mask-creation or mask-application siblings like apply_mask and star_mask.

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 about when to call this tool instead of related mask tools such as apply_mask, star_mask, or range_mask. The description states what it reports but not the situations in which an agent should prefer it, nor any exclusions or alternatives.

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