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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world behavior, so safety is covered. The description adds useful output content (tone histogram, grain size) but says nothing about supported formats, cost, or the shape of the returned measurements.

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 front-loaded sentence with no filler, and the key noun phrase leads. The fragment style and 'incl.' abbreviation keep it from a perfect 5, but there is no wasted 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 read-only, single-parameter analysis tool with annotations already covering safety, the description gives partial return-value detail. With no output schema, it should say more about the measurements returned and how they relate to downstream tools like match_style.

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 single required 'path' parameter has 0% schema description coverage, so the description must carry the burden. Saying 'of a (reference) image' only indirectly suggests path points to an image; it does not clarify whether it is a filesystem path, URL, or open-image handle.

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: it measures photographic style of an image and names two concrete outputs (tone histogram, grain size). It does not explicitly differentiate from siblings like inspect_image or match_style, so it falls short of a 5.

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

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

The parenthetical '(reference) image' implies the tool is used to characterize a reference before matching, but there is no explicit when-to-use guidance or named alternative such as match_style or inspect_image. Usage 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 only say it is a non-read-only, non-idempotent, non-destructive mutation, so the description must carry the rest. It does not explain what happens to existing content, what 'append' vs 'replace' does, or whether the preset is copied or referenced. That omission is significant for a non-idempotent 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?

It is one tight, front-loaded sentence with no filler. It is concise, but that comes partly from leaving important details out.

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

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

For a 4-parameter, non-idempotent mutation with no output schema and no parameter descriptions in the schema, the description is too thin. It should cover the effect of 'mode' and what the resulting group step contains.

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 needs to carry the load, but it explains only one of four parameters. 'strength = group opacity 0..1' is genuinely useful, but the 'mode' enum (append/replace) and preset_id/project_id are left undefined.

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 ("Add a preset"), but the destination concept, an "editable group step", is internal jargon that isn't self-explanatory. Siblings like list_presets/save_preset/delete_preset are clearly about preset CRUD, and this one is not, but the description doesn't clarify the distinction explicitly.

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

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

There is no guidance on when to use this instead of apply_to_file, edit_project, or save_preset, and no preconditions are stated. The agent must infer usage entirely from the name.

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

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

Annotations already declare it is a non-read-only, non-destructive, non-idempotent, closed-world operation. The description adds real context beyond that: it writes an output file and discards no project state afterward. However it says nothing about overwrite collisions, what dry_run does, or format/quality handling, which matter for a file-writing tool.

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

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

A single compact sentence with the distinguishing constraint front-loaded after the 'One-shot' label. No wasted words, though the economy comes partly at the cost of the missing parameter detail.

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

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

With 8 parameters, zero schema descriptions, no output schema, and file-writing side effects, the definition is under-specified for correct invocation. An agent still cannot determine dry_run/overwrite/quality semantics or whether steps and preset are mutually exclusive.

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% across 8 parameters, so the description must carry the burden. It only clarifies input, output, steps, and preset; format, quality, dry_run, and overwrite are entirely undocumented anywhere, leaving half the parameters opaque (e.g. is quality a 0-100 scale? does format default from the output extension?).

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

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

States a concrete verb chain (apply steps/preset to an image file and export) plus the key scope qualifier 'without keeping a project', which separates it from the open_project/edit_project flow. It does not name a specific sibling as the alternative, so differentiation is implicit rather than explicit.

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

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

'One-shot ... without keeping a project' hints at when to prefer this over the project-based path (open_image/open_project + edit_project + save_project), but no alternative is named and no when-not condition is given. For a batch of 27 siblings, implied routing is thinner than ideal.

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, and the description explains why cancellation is not fully destructive: 'finished outputs are kept.' That is genuine added context. However, it is silent on what happens to in-progress work, whether cancelling an already-finished job errors (annotations say idempotentHint=false), and whether cancellation is immediate.

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 tight sentence with the core action front-loaded and the state-retention caveat attached. 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 one-parameter, annotation-covered tool with no output schema, the definition is minimally sufficient: it says what is cancelled and what survives. It leaves gaps an agent would care about, specifically where to get a valid job_id and how errors/duplicate cancels behave.

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 never mentions job_id at all. The single parameter is self-named and required, so an agent can infer it, but the description adds no format, source, or validity information to compensate for the empty schema.

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

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

'Cancel a running job' gives a specific verb+resource that is clearly distinct from siblings like job_status and start_batch. The added clause about outputs surviving makes the intent sharper, though it does not name sibling tools or contrast itself with them.

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

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

The phrase 'running job' implies the precondition that the job must be in flight, and the verb implies when to use it. But there is no explicit when-not guidance (e.g., finished/failed jobs), no mention of alternatives such as letting the job complete, and no pointers for obtaining a job_id.

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 as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful return-content context by naming the metrics and side-by-side image, but does not disclose defaults, error behavior, or how versions are resolved.

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 the key metrics front-loaded and no wasted words. Its brevity is effective as a summary, even though other dimensions need more detail.

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

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

With four parameters, zero schema descriptions, and no output schema, the description should carry more of the invocation burden. It partially describes the return content, but leaves parameter meaning, defaults, and usage conditions unclear, so an agent cannot confidently invoke it without inspecting the schema.

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

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

Schema description coverage is 0%, so the description must explain the four parameters, but it does not. It hints at comparing two versions and optionally including an image, yet never explains a, b, project_id, include_image, or their defaults, leaving the required project_id especially undocumented.

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

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

The description clearly states that the tool computes comparison metrics between two versions and produces a side-by-side image, naming specific metrics. It is specific about the resource and output, but does not distinguish this tool from nearby alternatives such as inspect_image or 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 gives no explicit guidance on when to use this tool versus alternatives, nor any conditions or exclusions. At best, usage is implied by the mention of comparing two versions.

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 flag destructiveHint=true and readOnlyHint=false; the description adds real value beyond them by describing the two-step safety protocol (user confirmation then confirm=true). It stops short of saying whether deletion is reversible or what happens to a nonexistent preset_id.

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, the destructive nature is front-loaded right after the action, and there is no filler. 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 two-parameter destructive tool with no output schema and full annotation coverage, the description supplies exactly what an agent needs: what is deleted, that it is destructive, and the confirmation gate.

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

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

Schema coverage is 0%, so the description must carry the semantics. It explains the non-obvious `confirm` flag and when to set it; `preset_id` is left implicit but its meaning is self-evident from the name and the 'user preset' scope.

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 ('Delete') and resource ('user preset'), which is enough to separate it from save_preset, list_presets and apply_preset without opening a schema. It does not name those siblings explicitly, so it stops short of a 5.

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

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

Gives a concrete precondition for invocation: ask the user first, then call with confirm=true. Clear usage context, but no explicit exclusions (e.g. what to do about non-user presets).

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 that this is a safe, read-only, idempotent operation. The description adds useful behavioral context by enumerating what the documentation contains: parameter types, ranges, units, defaults, JSON schema, maskability, and examples.

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 that states the resource, the count constraint, and the returned documentation fields without any 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 simple read-only introspection tool with one parameter and no output schema, the description is largely complete. It explains the returned documentation content and the 1-50 id limit, though it could mention where operation ids come from.

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 0% description coverage for the single ids parameter. The description compensates partially by clarifying that these are operation ids and that between 1 and 50 may be supplied, but it does not explain the id format or where to obtain valid ids.

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 this tool returns full documentation for operation ids, including specific documentation fields. It distinguishes itself from list_operations implicitly by describing documentation retrieval rather than listing, but it does not explicitly differentiate itself from nearby tools such as describe_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?

Usage is implied: call this when you already have operation ids and need detailed documentation. However, the description does not explicitly say when to use this versus list_operations or describe_tool, nor does it state prerequisites such as obtaining ids first.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds no behavioral context beyond that—it doesn't state what is returned, error behavior for unknown tools, or any other runtime 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 fragment, so it is concise but lacks a clear subject-verb structure and does not front-load the action. It is appropriately short but not optimally structured for quick parsing.

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 one parameter and no output schema, the description should at least explain what the tool returns (e.g., a schema and documentation object) and clarify the parameter's role. It does neither, leaving significant gaps 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?

Schema description coverage is 0%, and the single parameter 'name' is undocumented. The description implies the parameter is the tool name via 'of a utility tool,' but this is only an inference and not explicit, leaving the parameter meaning ambiguous.

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 'Parameter schema and documentation of a utility tool' indicates the tool provides schema and docs, but it is a noun phrase without a clear verb and does not specify the resource as a tool name input. It does not distinguish from siblings like list_tools or get_capabilities.

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 on when to use this tool, what alternatives exist, or any prerequisites. The description provides no context to help an agent choose it over siblings such as list_tools or describe_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?

Goes well beyond the annotations by disclosing atomicity (all-or-nothing), the single-undo rollback model, and the complete action vocabulary including 'clear' and 'remove'. That rolls back the risk implied by destructiveHint=false for tools that can clear a project. It stops short of stating what happens on partial validation failure or what error shape returns.

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 critical guarantee (atomic, one undo step) is front-loaded in the first clause, then the action shapes are presented as a compact reference block rather than prose. Dense and reference-style, but every line maps to a real distinction an agent must encode.

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 mutating, non-idempotent tool with no output schema and zero schema coverage, the description covers the input grammar well but omits failure behavior, whether project state must be loaded first, and how this relates to plan_edit/describe_operations for resolving 'op' IDs.

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

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

Schema coverage is 0% and 'actions' is an untyped array of free-form objects, so the description carries the full burden and mostly meets it with a per-action grammar covering op/step_id/index/mask/opacity/blend/label and a mask example with all mask types. However the core 'params':{...} payload is left opaque and project_id/description are never explained, deferring to describe_operations.

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

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

States a specific verb and resource ('apply edit actions') plus a scope guarantee ('atomically, one undo step'), which separates it from plan_edit and apply_preset. It does not explicitly name the sibling it supersedes, so an agent must infer the plan-then-apply pairing on its own.

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

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

Usage is only implied: the atomic batch framing suggests this is the single mutation entry point to use after plan_edit, and the 'one undo step' phrasing hints at batching multiple actions. There is no explicit when-to-use/when-not guidance, no mention of prerequisites like an open project, and no direction to plan_edit or describe_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 description adds useful behavioral context beyond annotations by stating that originals are protected and that existing files require overwrite=true. With annotations already declaring readOnlyHint=false and destructiveHint=false, this is helpful, but it omits behavior for dry_run, save_project, metadata handling, bit_depth, and quality.

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 key constraint and behavior are front-loaded in the first sentence, followed by a compact format list. It is appropriately short, though the format list is somewhat bare and does not tie formats to the format parameter explicitly.

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

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

This is a 9-parameter mutation tool with no output schema and 0% schema description coverage. The description covers file writing and overwrite safety but is incomplete for most optional parameters and the return 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 0%, so the description must carry parameter meaning. It partially explains output, overwrite, and supported formats, but leaves project_id, dry_run, quality, metadata, bit_depth, and save_project undocumented.

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

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

The description states a specific operation: render at full resolution and write a new image file. That distinguishes it implicitly from preview-oriented siblings like render_preview, but it does not explicitly name the sibling or clarify boundaries with apply_to_file.

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 one important usage condition: existing files require overwrite=true, and originals are protected. However, it does not say when to choose export_image versus render_preview, apply_to_file, or other output-related tools.

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

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

The annotations already establish that the operation is read-only, idempotent, non-destructive, and closed-world. The description adds useful context by enumerating the manifest contents and stating that it is a once-per-session call, though it does not detail response structure or caching 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 sentences, front-loaded with 'Manifest:' and immediately followed by the practical call guidance. The enumerated capabilities are dense but necessary, and there is no wasted prose.

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

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

For a no-parameter, read-only discovery tool with rich annotations, the description gives enough to understand what it returns and when to invoke it. It could be stronger by clarifying how it relates to siblings like list_tools or describe_tool, but no critical calling 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?

The tool has zero parameters and an empty input schema, so there are no parameter semantics to clarify. A baseline of 4 is appropriate because the description does not need to compensate for missing parameter documentation.

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

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

The description identifies a specific resource: a manifest covering operation categories/counts, edit-action types, mask types, formats, backends, security policy, workflows, and error codes. It is clearly a capabilities-discovery tool rather than a tautology, though it does not explicitly distinguish itself from siblings such as list_tools or describe_tool.

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

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

It explicitly says to call it once at the start of a session, which gives clear timing and frequency guidance. It does not state when not to use it or name an alternative for already-known capabilities, so it falls short of full when/when-not routing.

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

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, so the safety profile is covered. The description adds value by disclosing the shape of the returned state (ordered steps, per-step params/masks/opacity/blend, undo/redo availability), which the annotations do not. It says nothing about size/cost of the payload or how include_history changes the result.

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 the key content (what state fields come back) front-loaded. Field enumeration is dense but earns its place; only the semicolon-chained style slightly reduces readability.

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

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

There is no output schema, so the description has to convey return contents, and it does so reasonably for the step list and undo/redo flags. However it omits the parameters entirely, and does not say whether include_history expands the payload or how large the state can be – gaps an agent must guess at before calling.

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 neither parameter is mentioned in the description. The 'undo/redo availability' phrase hints at history but does not explain what include_history toggles or that project_id is the required target. For a 0%-coverage schema the description needed to compensate and 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?

States precisely what the tool returns: the complete editing state, with the constituent fields enumerated (ordered steps with ids, params, masks, opacity, blend, plus undo/redo availability). This differentiates it from project_history and list_operations, which cover history/log views rather than current state. It lacks an explicit verb, but the name 'get_project_state' and the field list make the resource unambiguous.

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

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

No guidance on when to call this versus siblings such as project_history, list_operations, or plan_edit. An agent must infer from the field list alone that this is the snapshot call. No preconditions, no 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?

The annotations already declare this as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful behavioral context by listing the measured outputs and explaining that include_thumbnail returns a small preview image, but it does not cover supported formats, error behavior, or how the file is accessed.

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 main purpose before listing measured properties and the optional thumbnail behavior. The dense list of measurements is efficient, though it could be organized more clearly into returned values versus parameter behavior.

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

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

For a two-parameter, read-only inspection tool with no output schema, the description does list the main returned measurements and the thumbnail option. It remains incomplete around path requirements and sibling differentiation, which matters because several other tools appear to operate on images or style analysis.

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 both parameters. It explains include_thumbnail reasonably well, but it does not clarify the required path parameter, accepted file types, path format, or whether the path must point to a local image file.

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 the kind of result: metadata and measured style of an image file, including specific measurements such as tone, white balance, saturation, grain, vignette, palette, and descriptors. It does not, however, differentiate this tool from nearby siblings like analyze_style, open_image, or 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?

There is no explicit guidance on when to use inspect_image versus alternatives such as analyze_style, open_image, or render_preview. The description implies it is used to inspect image properties, but it gives no exclusions, prerequisites, or alternative routing.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds useful behavior: optional blocking via wait_seconds and the fallback to listing all jobs when job_id is null. It says nothing about return shape or the include_items flag.

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

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

A single front-loaded sentence that packs in the two operating modes and the wait behavior with zero 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?

No output schema exists, so the description carries the burden of explaining returns, and it only says 'status/progress' without detail. Combined with the undocumented include_items flag, an agent has gaps before calling 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 0%, so the description must compensate. It explains job_id semantics (omitted means all jobs) and wait_seconds (optional wait), but include_items is left entirely undocumented in both schema and 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?

Specific verb+resource: reports status/progress of a job, and it also covers the distinct listing mode when job_id is omitted. It is distinguishable from cancel_job and start_batch, though it doesn't name those siblings explicitly.

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

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

The description implies the when: use it to check on a running job, and optionally block via wait_seconds. It doesn't state when not to use it or point to alternatives such as list_operations for browsing.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the return is a 'compact list' with id, title, group, which is useful context beyond annotations, but it omits pagination behavior and any filtering edge cases.

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

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

Two sentences, front-loaded with the tool's purpose and return shape, followed by filtering examples. Every sentence earns its place with no wasted wording.

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 list tool with 0% schema description coverage and no output schema, the description should cover pagination and all filters. It addresses category, group and query well but leaves limit/offset unexplained and does not contrast with describe_operations, leaving 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 explains category and group with an example pairing and gives query examples, but it says nothing about limit or offset, leaving two of five parameters completely undocumented in both schema and 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 specific verb and resource ('Compact list of editing operations') and names the compact fields returned (id, title, group). It does not explicitly distinguish this tool from the sibling describe_operations, so it stops short of a 5.

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

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

It gives concrete filtering examples (category='filter', group='blur', query='vignette') which guide invocation, but it never states when to use this tool versus describe_operations or get_capabilities. Usage is implied rather than explicitly scoped.

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 that this is read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds that the catalog contains both built-in looks and user presets and can be searched by mood, which is useful behavioral context, but it does not describe return contents, sorting, or whether user presets are mixed with built-ins.

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, two sentences, and front-loads the catalog contents before the search hint. The parenthetical list of examples is somewhat long but earns its place by making the semantic-look category concrete.

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, two parameters, and 0% parameter description coverage, the description should do more to explain what is returned and how kind/query interact. It covers the general domain but leaves the agent guessing about the enum semantics and the result shape, which is a significant gap for a discovery tool.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning but largely does not. It mentions built-in looks and user presets, loosely mapping to kind=look/user, but never explains the kind enum (all/look/user) or the difference between listing all versus only looks or only user presets. The query parameter is only hinted at with 'Search by mood words'.

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 as built-in looks and user presets and implies searching by mood words, but it never states the action (list/search) explicitly or distinguishes this from siblings like apply_preset, save_preset, or delete_preset. An agent can infer the purpose from the name plus examples, but the description itself is more a catalog blurb than a clear verb+resource statement.

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 only a thin hint for the query parameter ('Search by mood words') and no when-to-use guidance, no exclusions, and no comparison to alternatives such as apply_preset. There is no indication whether to use this to discover presets before applying one, or how it relates to save_preset/delete_preset.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description need not restate it. The description adds the content scope of the catalog (the categories of tools returned), which is modest but real value. It omits what the response actually looks like (names only vs. names plus descriptions vs. pagination), which matters for a discovery call whose whole point is the return payload.

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

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

It is compact and dense with real content, so no sentence is padding in the literal sense. However it is not front-loaded with a purpose statement — the sentence opens mid-catalog and trails off with an ellipsis ('... rename...'), signalling an incomplete enumeration rather than a defined contract. A one-line 'Returns the utility tools available, optionally filtered by query' would do more work than the list.

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-config discovery tool with no output schema, the description should explain what comes back and how to use 'query' to narrow it; it does neither. Given that the agent's next move (describe_tool → run_tool) depends entirely on reading this result, the omission is more consequential than it would be for a leaf operation.

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

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

The single optional parameter 'query' has 0% schema description coverage, and the description says nothing about it — not whether it is a substring match, a keyword filter, or semantic search, and not what omitting it returns. With one param and no schema documentation, the description was the only place this could be explained and it is silent.

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 never states a verb or what the tool returns; it enumerates a catalog of utility tools (palette, histogram, OCR, PDF, etc.), which only implies 'lists tools' when combined with the tool name. The enumerated domains are genuinely informative about scope, but the purpose itself must be inferred rather than read. It also gives no signal distinguishing it from describe_tool or run_tool, which are the natural next steps in a discovery flow.

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 when-to-use guidance at all: nothing says to call this before describe_tool/run_tool, nothing about how it relates to get_capabilities or list_operations, and no conditions under which to prefer it. The agent is left to infer the entire discovery workflow from sibling names alone.

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

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

Annotations establish a non-readonly, non-destructive, non-idempotent mutation; on top of that the description discloses the pipeline stages that will be altered and states the return payload (steps plus a report with similarity, confidence and limitations), which correctly signals that results may be approximate. It stops short of saying how changes interact with project history or whether the fitted grade is reversible.

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

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

Four tight sentences in a deliberate order — what it builds, mode semantics, strength default, then return values. No filler, and the core operation is front-loaded before the mode detail.

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

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

For a 9-parameter mutating tool with no output schema, the description covers the conceptual model and returns but omits the apply-vs-dry-run behavior, what 'parametric+lut' mode changes, the meaning of preserve_skin, and the accepted form of the reference parameter. Adequate to start, not sufficient to call confidently without reading the schema.

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

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

Schema description coverage is 0%, so the description must carry the burden, and it only partly does: matching and strength are explained well, and the stage list hints at include_grain/include_vignette. The mode enum (parametric vs parametric+lut), apply, preserve_skin, project_id and reference are left entirely to bare schema titles.

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

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

It states a specific verb and resource — 'fit an editable grading pipeline' — and enumerates the pipeline stages it builds (white balance, tone curve, 3-way grade, saturation, HSL, grain, vignette), so the agent knows exactly what is produced. It never names a sibling, so the boundary with analyze_style or apply_preset has to be inferred.

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 for the matching parameter, explaining that 'look' transfers the grade without copying scene content while 'exact' targets the same-scene case, and it explains what strength=null does. It does not say when to prefer this tool over analyze_style (analysis only) or apply_preset, which is a real gap given how many style-related siblings exist.

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 readOnly=false, destructive=false, idempotent=false, and openWorld=false, so the safety profile is covered. The description still adds real value beyond them: it says edits are non-destructive, which reinforces the safe mutation model, and it names the return values (project_id and state) since there is no output schema. Missing detail on permissions or failure modes keeps it from a 5.

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

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

Two sentences with zero filler; the action and the return contract are both stated immediately. Nothing is wasted and the key facts are 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?

Return values compensate for the absent output schema, which is helpful. However, for a tool with two completely undocumented parameters and no annotations covering the semantics of inputs, the description leaves an agent guessing about the path format and the purpose of name.

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 has to carry the burden of explaining parameters, but it mentions neither path nor name. There is no indication of what format path takes (absolute, URI), whether the file must exist, whether name defaults to the filename, or what happens when name is null.

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

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

States a specific verb and resource ('Open an image') plus the resulting artifact ('new non-destructive editing project'), which separates it from mutation tools like edit_project or export_image. It does not explicitly distinguish itself from the sibling open_project, so the boundary between opening an image versus opening a project is left implicit.

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

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

Usage is only implied: 'as a new non-destructive editing project' signals this is the entry point for starting work on a file. There is no explicit when-to-use or when-not-to-use guidance, and the agent must infer the difference from sibling open_project on its own.

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, destructiveHint=false, and idempotentHint=false, but the description adds no behavior beyond the verb — notably it never says whether opening replaces the current in-session state, whether an already-open project is discarded, or what happens if the path is invalid. With no disclosure of state effects for a non-idempotent mutation, the added value is minimal.

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 front-loaded sentence with no wasted words, and the GUI-edited parenthetical is useful context. However, the brevity comes at the cost of substance rather than being maximally 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?

No output schema exists, so the description must carry the burden of explaining the result of opening a project and the effect on current state — it does neither. For a state-mutating loader with 0% parameter documentation, the one-line description leaves real 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 coverage is 0%, so the single 'path' parameter is undocumented in both the schema and the description. The description only implies it points to a .lazyroom file; it says nothing about relative vs absolute paths, whether the file must exist, or whether a .lazyroom extension is enforced.

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

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

States a specific verb ('Open') and resource ('saved .lazyroom project'), and the file-type qualifier implicitly distinguishes it from the sibling open_image, which handles raw images rather than project files. It stops short of explicitly naming that sibling, so it is not 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 parenthetical 'one a human edited in the GUI' hints at the scenario (reloading externally modified work), which implies when to use it. But there is no explicit statement of when to prefer open_project over open_image, save_project, or get_project_state, and no prerequisites given.

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, destructiveHint=false, and idempotentHint=false; the description usefully adds that resolution happens via a rule engine or a local/remote LLM, which explains the non-idempotency. However, it never states that the 'apply' path actually mutates project state, nor whether that write is reversible or what gets 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?

Two compact sentences, front-loaded with the core transformation and grounded by one well-chosen example. The parenthetical about LLM backends is slightly parenthetical clutter but still earns its place by explaining variability.

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

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

This is a mutation-capable tool with no output schema and 0% schema description coverage; the description should at least clarify the apply flag and what a returned plan looks like. Neither is covered, so an agent cannot confidently choose apply=true versus reviewing first.

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 carry the load. It does add real meaning for 'request' via an illustrative example, but 'apply' and 'project_id' are never mentioned — the most behaviorally significant flag is left 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 specific verb and transformation: natural-language request into editable steps, with a concrete example. It implicitly contrasts with the applying siblings ('Review, then apply') but never names edit_project or apply_preset, so the boundary is inferred rather than stated.

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?

'Review, then apply' sketches a two-phase workflow, implying this is the planning entry point before mutation. There is no explicit statement of when to prefer this over edit_project, apply_preset, or match_style, and no prerequisites or exclusions are given.

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 a non-read-only, non-destructive, non-idempotent mutation, and the description adds one genuinely useful behavioral fact: revert is itself undoable, which materially changes the risk calculus. It says nothing about how many steps of history exist, whether undo is scoped to the project or to the session, or what revert does to entries after the target.

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 dense sentence with no filler, and the primary capability (list) is front-loaded. The three modes are packed into one clause, which is efficient but leaves no room for the qualifiers an agent needs.

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

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

This is a state-mutating tool with four parameters, zero schema documentation, and no output schema, and one sentence is far too thin. Nothing tells the agent what list returns, what happens on undo past the beginning of history, or what a successful revert response looks like.

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 carry all parameter meaning, yet it only gestures at 'steps' (the N) and the action names. history_id is never explained (which entry identifier list returns), project_id is never mentioned, and the interaction between steps and history_id for revert is left ambiguous.

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

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

Names the resource (history) and enumerates the four operations it supports (list, undo, redo, revert), matching the action enum exactly. An agent can tell it is the history-management tool rather than a general project editor, though it does not explicitly differentiate itself from siblings like compare_versions or edit_project.

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 each mode applies (list vs undo/redo vs revert) but never states selection criteria, prerequisites, or when to prefer a sibling such as compare_versions. The reader must infer the branching from the action enum.

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 readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds valuable return-content detail (image, per-step timings, result statistics), but says nothing about render cost, latency, or what include_image/max_size change behaviorally.

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

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

Two tight sentences, front-loaded with the core action and followed by the notable option. No filler, though slightly telegraphic.

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

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

With no output schema, the description usefully sketches the return values, and safety is covered by annotations. The remaining gap is undocumented tuning parameters (max_size, include_image), which keeps it from being 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 0%, so the description must compensate, and it only partially does: it explains 'version' format and 'compare=side_by_side' semantics, but leaves max_size and include_image entirely undocumented in both schema and 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?

States a specific verb and resource (render the project → preview image) plus the returns (timings, statistics). It implicitly distinguishes itself from export_image and compare_versions by scoping to previews, though it doesn't name those siblings explicitly.

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

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

Gives useful context for version selection ('original' or a history id) and mentions the side_by_side option, but never says when to choose this over export_image or compare_versions, nor any prerequisites.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the safety profile is covered structurally; the description's genuinely additive content is that some target tools are destructive and need confirm=true. It does not mention that wrapped calls can mutate state despite the outer tool's destructiveHint=false, nor how results/errors are surfaced. Note the mild tension with destructiveHint=false, but the annotation describes run_tool itself, not its payloads, so this is not a strict contradiction.

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-loaded with the action and the discovery pointer, with zero filler. It is arguably under-specified rather than over-long, but nothing is redundant.

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

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

For a generic dispatcher with an open-ended nested params object and no output schema, the description needs to explain the indirection contract (discover schema, pass params verbatim, confirm for destructive targets). It covers the confirm rule and points to discovery but leaves return format and error handling unstated.

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

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

Schema description coverage is 0% for two required params (name, params object), so the description must compensate; it does partially by implying 'name' is a tool name resolved via list_tools/describe_tool and that 'confirm' belongs inside params. It never states the params object must conform to the target tool's schema, nor how nested/arbitrary properties are validated.

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

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

States a specific verb and resource ('Run a utility tool') and routes the agent to list_tools/describe_tool for discovery, which distinguishes it from the concrete sibling tools. It stops short of 5 because 'utility tool' is never defined and it doesn't state what a utility tool is versus e.g. plan_edit or 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 parenthetical '(see list_tools/describe_tool)' implies the discover-then-run workflow, and the confirm=true rule gives one concrete precondition. However, it never says when an agent should use this dispatcher instead of calling a capability directly, nor what to do when a named tool is unknown.

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 a non-read-only, non-idempotent, non-destructive write, so the safety profile is covered. The description adds the two sourcing modes but omits the key behavioral detail an agent needs: how name collisions are handled and what overwrite 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?

A single front-loaded sentence with no filler; the verb and resource come first and the qualifying detail follows immediately.

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 six-parameter mutation tool with 0% schema coverage and no output schema, the description is far too thin. Overwrite semantics, tags, description, and step object shape are all left for the agent to guess.

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

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

Schema coverage is 0%, so the description carries full burden; it only implicitly covers project_id and steps and says nothing about tags, description, or overwrite (including what overwrite=false on a name collision does). The structure of individual step objects is also 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?

A specific verb and resource plus the two supported sources (a project's pipeline or explicit steps) make it easy to separate from list_presets, apply_preset, and delete_preset. It stops short of explicitly naming those siblings as alternatives.

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 'project's pipeline or explicit steps' hints at two input modes, but there is no statement of when to use this versus apply_preset or save_project, and no prerequisites or exclusions are given.

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 it is a non-read-only, non-destructive, non-idempotent, non-open-world operation. The description usefully adds that the output is human-readable JSON and interoperable across tools, but says nothing about overwrite behavior when the target file exists, what happens with the default path, or whether directories are created.

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

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

A single front-loaded sentence with the verb first and zero filler; nothing is repeated from the schema or annotations. It is well structured for its length.

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

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

The description conveys the output format and portability, which is the main payoff, and annotations cover the safety profile. Still missing for a file-writing mutation tool: where the file goes by default, overwrite semantics, and any return value (no output schema exists to fill that gap).

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

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

Schema description coverage is 0% for both parameters. The description mentions no semantics for project_id and gives no clue about path (default null behavior, absolute vs relative, overwrite of an existing file). With low coverage the description needed to compensate and 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?

Uses a specific verb (save) and resource (the project) and names the concrete artifact produced: human-readable JSON with the .lazyroom extension. An agent understands what it gets, though the description never contrasts it with the related open_project / export_image / apply_to_file 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 clause about the GUI, CLI and other agents being able to open the file implies the use case (producing a portable, shareable project state). However, there is no explicit when-to-use vs when-not, no mention of alternatives such as export_image for rendered output, and no prerequisites 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?

Beyond annotations, it discloses important behavior: background execution, immediate job_id return, required polling via job_status, per-file failure isolation, and a JSON report written to output_dir. It does not clarify overwrite/skip_existing behavior or permission requirements, but it adds substantial operational context.

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

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

The description is compact and front-loads the core async batch behavior before covering normalize, match_reference, failure handling, and reporting. The semicolon-heavy style is dense but every clause carries relevant 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 15-parameter batch-processing tool with 0% schema description coverage and no output schema, the description is too thin. It adequately explains async execution and failure reporting, but most parameters and their effects on the batch pipeline are left unspecified.

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

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

Schema description coverage is 0% across 15 parameters, so the schema provides almost no semantic help. The description explains only normalize, match_reference, and output_dir reporting; it leaves steps, preset, format, naming, dry_run, quality, metadata, overwrite, recursive, project_id, skip_existing, and inputs largely undocumented.

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

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

The description states a specific operation: batch-processing files/folders/globs through one pipeline in the background. It clearly frames the tool as asynchronous batch processing, though it does not explicitly contrast itself with siblings like apply_to_file or run_tool.

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

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

It gives clear usage context: the call returns a job_id immediately and the agent should poll job_status. This effectively tells the agent how to use the tool after invocation, but it does not explicitly say when to prefer it over single-file or synchronous alternatives.

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