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

With no annotations, the description carries the full burden and does well: it discloses replace-vs-merge behavior (copy replaces the entire mask, luma_range replaces existing luma components), the reset/paste actions, zero-based indexing excluding Background, and that gradients use normalized RAW rather than rotated viewer coordinates. It does not cover failure modes, auth/permission needs, or whether writes are reversible, which keeps it short of a 5.

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

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

There is no filler, but the content is a dense semicolon-delimited wall with per-module schemas interleaved with behavioral rules rather than front-loaded or grouped into call-workflow-first sections. An agent must parse the whole block to find the ordering constraints that matter most.

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

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

An output schema exists, so return values need not be described, and the description supplies the module vocabulary, numeric domains, and coordinate conventions a caller needs. The remaining gap is the observation_token contract and the target object's expected shape, which are central to making a valid call.

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

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

Schema description coverage is 0%, so the description must explain all five parameters. It richly documents 'module' tokens and the 'patch' payload shape, and touches 'target' via target.layer, but the required 'observation_token' (its format and provenance) and the optional 'request_id' are never explained, leaving two of five parameters undocumented by any source.

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

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

The opening line gives a concrete verb and scope: apply exactly one numeric or structured module using its observed module token. That distinguishes it from read/context/preview siblings in practice, though no sibling is named explicitly and terms like 'qualified module' remain internal jargon an agent must infer.

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 real workflow conditions: read the destination module before applying, select a layer then re-read, target.layer binds the write, and native qualification is still required. What is missing is an explicit negative case (when not to call this, e.g., non-module edits) or a named sibling as the alternative path.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Read' implies non-mutation, but the description says nothing about cost, size, whether the snapshot is cached or live, or whether 'unresolved operations' reflects pending writes — all relevant for a context 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 terse sentence with no filler, and the enumeration is front-loaded. It is arguably over-compressed for the ambiguity it needs to resolve, but nothing in it is wasted.

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

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

An output schema exists, so return values need not be explained. Still, with no annotations and a generic name shared with a sibling 'read' tool, the definition leaves the agent without the when/why context needed to choose it confidently.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a parameterless snapshot by not referencing any inputs.

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

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

The description does name what the tool returns (application, target, capabilities, shared editing workflow, unresolved operations), which is more than a tautology of the bare name 'context'. However, it is a noun list with only the verb 'Read' rather than a stated resource and scope, so an agent cannot easily tell how it differs from the sibling 'read' or 'operations' 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?

There is no statement of when to call this versus the sibling 'read' or 'operations' tools, and no prerequisites or exclusions. The agent must infer that this is an initial session-context fetch, which is a guess rather than guidance.

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

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

With no annotations, the description must disclose behavior; it does add that listing includes offscreen photos, create_candidate clones the selected variant, edits are restricted to registered copies, and macOS has restrictions. However it omits side effects and permissions for select, prepare_adjustments, and prepare_tool and does not clarify mutation safety.

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 list/select idea, but it is a dense set of jargon-laden sentences rather than an action-oriented structure. Terms like native collection, offscreen photos, registered copies, and collection_token are not defined.

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

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

For an 11-parameter, seven-action tool with no annotations and no schema descriptions, this description is far from complete. It offers useful hints for a few paths but leaves most of the action surface undocumented; the output schema only removes the need to explain return values.

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% across 11 parameters, so the description must compensate. It only touches variant_uuid and collection_token (plus output next_offset), leaving action, scope, limit, offset, target, request_id, variant_id, observation_token, and tool enum values 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 first sentence names list and select on a native collection, but the tool exposes seven actions (prepare_adjustments, prepare_tool, next, previous, etc.) and the generic name 'images' does not establish the overall purpose. It is not clear how this differs from siblings such as read or 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?

It gives action-specific operational guidance (same collection_token for pagination, next/previous on filtered collection, create_candidate behavior, macOS-only listing/selection) and points to context for platform restrictions. It does not say when to choose this tool instead of siblings or explain the prepare_* actions.

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

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

With no annotations, the description carries the full behavioral burden and does so extensively: it distinguishes read-only actions from mutations, states request_id and target/token requirements, explains that restore writes saved color parameters without restoring layer structure/mask pixels, and clarifies that anchor_analysis does not write C1. It also discloses coordinate-system and color-space assumptions, including normalized EXIF-oriented boxes and ICC/assume_srgb 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 content is front-loaded with the core get/list/reconcile behavior before the task-action detail, and much of the density is justified by the tool's 15 task_actions. However, the semicolon-heavy wall of text is difficult to parse and could be organized more clearly.

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

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

An output schema exists, so return values do not need description, and the tool's complexity is matched by substantial behavioral and payload detail. The remaining gaps are the lack of explicit sibling-tool selection guidance and incomplete coverage of a few top-level parameters.

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 supply parameter meaning, and it does so richly for task_action payloads, checkpoint/review structures, IDs, request_id/task_id conditions, and coordinate boxes. It still leaves some top-level parameters such as operation_id and the general target/token shape unclear, so it is strong but not fully complete.

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

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

The description names the primary actions (get/list/reconcile) and explains that action=task adds persistent photographic briefs and versions on Mac, so the broad purpose is understandable. It does not explicitly differentiate this tool from siblings such as read, adjust, or preview, which keeps it below 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 some usage conditions, such as get/diagnose/compare being read-only, mutations requiring a unique request_id and fresh target/token, and stop only needing task_id. However, it never states when to choose this tool over the sibling tools or when not to use it, leaving selection guidance 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?

With no annotations, the description carries the full burden and does substantial work: it discloses async behavior on Windows, platform-specific export requirements, id invalidation on photo/layer/revision change, and retention limits (one preview job, eight PNG cache files). It stops short of saying whether kind=render writes files to disk or what side effects/restore_destination entail.

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?

Roughly a hundred words with no wasted filler, but the structure is poor: it opens with a prerequisite rather than the purpose, then interleaves platform notes, per-kind behavior, and coordinate math in run-on sentences with hard-wrapped fragments. Front-loading what the tool does would fix most of it.

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, nested-target, no-output-schema tool, the description covers the highest-risk semantics: async behavior, id invalidation, cache retention, and coordinate mapping. Gaps remain around the opaque `target`/`observation_token` contract and unexplained actions, which an agent would have to guess at.

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 partly does: `kind` modes, `max_size` range 128..1600, `points` as pixel-edge {x,y} coordinates with the RAW normalization trick, `preview_id` reuse/invalidation, and `direction` implied via the divide-by-raw_dimensions note. `target`, `request_id`, `observation_token`, and three of five `action` values get no explanation at all.

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 makes clear this tool produces previews/renders of Capture One content across several modes (native adjustments, layer masks, JPEG exports, display capture), and it names the `context` sibling as a prerequisite. It never states the purpose in one declarative sentence, though — it opens with a directive ("Check context capabilities first") and lets the resource be inferred from the per-kind notes.

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 real routing guidance: check `context` first, macOS requires explicitly enabled kind=render, map_points must reuse the same kind/max_size and preview_id. But there is no guidance on when to choose `preview` over siblings like `read`, `images`, or `adjust`, and the `action` values prepare/render/restore_destination are never explained, so mode selection is only half-covered.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses that results include provenance, module guidance/units, an observation token, that fields=[] avoids loading adjustment parameters, and that targets are absolute rather than deltas. However, it does not explicitly state read-only/no side effects, permissions, or other operational constraints.

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-loads the core action, followed by practical usage notes. There is little wasted text, though the line break and terseness make some guidance feel compressed rather than fully structured.

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 output schema exists, so return values need not be explained in depth. Still, for a generic 'read' tool with no annotations and 0% schema description coverage, the description leaves sibling routing, parameter value formats, and some operational behavior unclear.

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 all four parameters. It adds meaningful semantics for fields (empty array behavior), module (read before edits), target (absolute, not delta), and modules (skip modules without a visible purpose), but it does not specify accepted values, target object structure, or the relationship between module and modules.

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: reading native parameters, including provenance, module guidance/units, and an observation token. It is clear what the tool does, but it does not differentiate itself from siblings such as context or preview, and 'native parameters' is somewhat domain-specific.

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

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

It gives explicit usage guidance: use fields=[] for target/preview without loading adjustment parameters, read module=... before edits, and skip modules without a visible purpose. It does not name alternative sibling tools for comparison, but it establishes clear when-to-use conditions and one exclusion.

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