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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by disclosing the comparison scope, the nature of the report (differences and unavailable fields), and the inclusion of decision IDs. It also explicitly lists limitations, which is useful context beyond the annotations.

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

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

Two sentences with no redundancy. The action is front-loaded, and the coverage limitation is stated concisely. Every sentence contributes to understanding what the tool does and what it does not do.

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 comparison tool with no output schema, the description covers the key elements: what is compared, what is reported, and what is excluded. The phrase 'expected document' is slightly ambiguous but understandable in context. It does not mention prerequisites or error conditions, but for a read-only operation with clear annotations, this is acceptable.

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 mentions 'source and candidate variants' and 'same image in the expected document,' giving some context about the relationship between the variant IDs, but it does not explicitly map each parameter (document_id, source_variant_id, candidate_variant_id) to its meaning. The parameter names are self-explanatory, but the description adds no direct semantics for them, leaving a gap.

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

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

The description clearly states the action: 'Compare readable settings of source and candidate variants from the same image in the expected document.' It also specifies the output: differences, unavailable fields, and IDs for keeping or reverting. This distinguishes it from sibling tools like co_get_variant or co_list_variants, which retrieve or list but do not compare.

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

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

The description gives clear context on what the tool does and explicitly states what is out of scope ('Mask contents, curves and luma ranges are outside comparison coverage'). However, it does not name any sibling tools or provide explicit when-to-use vs. when-not-to-use guidance beyond its inherent purpose.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a scoping qualifier ('current document') and lists the returned settings, but it does not disclose additional behavioral traits such as error behavior, freshness guarantees, or potential side effects. No contradiction with annotations.

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

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

One concise sentence with a clear lead phrase and a colon-delimited list of contents. Every phrase contributes meaning, and there is no redundant or filler 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?

With no output schema, the description carries the burden of describing the return payload. It enumerates the major setting groups, which is adequate for a zero-parameter read-only tool. Some details, such as the exact types or formats of paths and counters, remain implicit, but nothing essential for invoking the tool is missing.

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

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

The input schema has zero parameters, so parameter semantics are trivially covered; the description needs no additional parameter explanation. The listed settings describe the return payload, which is appropriate given the absence of an output schema.

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

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

The description clearly identifies the tool as returning detailed settings for the current document and enumerates what those settings include, such as kind, paths, folders, formats, counters, and queue depth. This distinguishes it from list-oriented siblings like co_list_documents, though it does not explicitly contrast itself with any sibling.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as co_status or co_list_documents. The description states what the tool returns but not when it should be preferred, nor does it mention exclusions or prerequisites. The only implicit signal is the phrase 'current document'.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the scope of the returned data but does not disclose additional behaviors such as failure modes, persistence effects, or access requirements, which is acceptable given the annotations.

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

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

The entire description is one compact, front-loaded sentence that immediately identifies the resource and spells out the contained settings. There is no filler, repetition, or unnecessary qualification.

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, idempotent single-parameter lookup, the description provides enough detail to set agent expectations about the rich response. A slightly more explicit mention of the return nature could push it to 5, but the field list already forms a useful mental model.

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

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

The schema already documents the only parameter, 'name', with a description and 100% coverage. The tool description confirms the object is 'one output recipe' but does not add new detail about the parameter. The baseline of 3 applies because schema does the heavy lifting.

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

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

The description states a specific resource ('one output recipe') and enumerates the content of the returned settings (file format, quality, scaling, sharpening, destination, metadata, crop, watermark). This clearly distinguishes it from siblings such as co_list_recipes and co_get_variant, which operate on different data.

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

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

The use case is implied: call this when you need the full configuration of a specific recipe, not when you need the list of recipes. However, it does not explicitly say when not to use it or name an alternative such as co_list_recipes, leaving some inference to the agent.

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

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

Description consistently implies a read-only getter, matching readOnlyHint and idempotentHint. It adds substantial specificity about return contents (EXIF, IPTC metadata, layers, output files) which is useful beyond the generic annotations. No 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?

A single sentence beginning with 'Everything scriptable' conveys the full scope in eleven words. No wasted words; the enumerations are informative without bloat.

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 getter with one well-specified parameter and no output schema, this supplies the full return scope. It is slightly incomplete in not mentioning error behavior or that some listed fields could be empty, but those are minor given annotations cover safety.

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 parameter id is already described in the schema as 'Variant id, as returned by co_list_variants' – clear provenance and type. The description doesn't add parameter detail, but with 100% schema coverage, credit is not required beyond the existing 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 clearly identifies the resource (one variant) and the action (retrieve everything scriptable), followed by an explicit list of contents such as source image, EXIF, adjustments, layers, and output files. This separates it unambiguously from siblings like co_list_variants and co_get_document. Though it does not name a sibling, the scope of 'everything scriptable about one variant' is precise and self-differentiating.

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

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

The description implies use when you need comprehensive details of a single variant, but it does not explicitly state when to prefer this over alternatives like co_list_variants or co_get_document, nor does it mention preconditions. It lacks routing guidance like 'use co_list_variants first to obtain IDs.' It is adequate but not explicit.

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

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

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds important behavioral context beyond that: the ranges were recovered by probing the live app rather than from the scripting dictionary, and the tool discloses any 'quirks'. This explains the nature of the data and sets expectations about reliability.

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

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

The description is two sentences of dense but efficient information: what the tool returns, the exact provenance of some data, and a directive for when to use it. It is front-loaded with the purpose and then adds the contextual hint about co_adjust_variants. Every clause contributes value, and there is no filler or redundancy.

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

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

This is a lightweight discovery tool with a single optional parameter and no output schema. The description still fully answers what is enumerated, that the data is source-proxied from live probing, and how the results should be used (to feed co_adjust_variants). It is complete for a tool of this complexity.

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

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

The only parameter, 'filter', is already fully described in the input schema ('Substring match on the property name'). With 100% schema description coverage and no enums or nested objects, the schema itself does the work, so the description does not need to add parameter-level semantics. This meets the baseline for a well-documented schema.

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

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

The description uses a specific verb ('List') and resource ('every writable adjustment property') and names the exact content it returns ('with its type, description-type, valid range and any quirks'). It clearly differentiates this from other list tools, which operate on documents, variants, recipes, etc., by focusing specifically on *adjustment* properties and framing them as 'writable'.

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

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

The description explicitly tells the agent when to invoke this tool: 'Call this before co_adjust_variants to get exact parameter names and limits.' This is a direct usage instruction with a concrete alternative tool and the reasoning for calling it first. It also implies when not to use it (i.e., not when you want to actually adjust something), which is all an agent needs.

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, and destructiveHint=false, so the safety profile is covered. The description adds the useful scoping detail 'in the current document' and enumerates collection types, but it does not disclose behavior like ordering, return shape, or whether hidden/empty collections are included.

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

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

A single sentence that front-loads the core action and scoping, followed by a useful list of collection types. There is no redundant or filler content.

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

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

For a simple, safe read-only listing operation with fully documented parameters, the description covers the essential scope. There is no output schema, so a brief mention of what each returned collection entry contains could improve it, but the verb 'List' sufficiently implies a collection list.

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

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

Schema description coverage is 100%, and the sole parameter include_counts has a thorough schema description including its performance tradeoff. The tool description itself does not need to repeat parameter details, so the baseline 3 applies.

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

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

The description uses a specific verb ('List') and a clear resource ('collections in the current document'), and enumerates the collection types (albums, projects, groups, smart albums, catalog folders, session favorites). It is immediately distinguishable from sibling tools like co_list_variants or co_list_documents.

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

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

The description gives no guidance on when to use this tool versus alternatives such as co_list_documents, co_set_current_collection, or co_list_variants. It only states what it does, leaving the agent to infer the appropriate context from sibling names.

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, and destructiveHint=false, covering the safety profile. The description adds useful context about scope (only open documents) and frontmost state, but does not explain return shape or how 'frontmost' is represented.

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

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

A single concise sentence that front-loads the main verb 'List' and includes only necessary scope information. No filler or redundancy.

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

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

For a zero-parameter, read-only list tool with safety annotations, the description is sufficient for correct invocation. It tells the agent exactly what the tool returns—open sessions and catalogs plus the frontmost one—and no arguments are needed.

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

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

The tool has zero parameters and the schema is complete at 100% coverage, so the description carries no parameter burden. Baseline 4 applies.

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

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

States a specific verb and resource: lists currently open Capture One sessions/catalogs and identifies which is frontmost. This clearly differentiates it from sibling list tools like co_list_collections and co_list_variants, which enumerate different object types.

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 phrasing 'currently open' and 'frontmost' gives clear context for when to call this tool, such as discovering available documents or determining the active one. It does not explicitly name alternatives or exclusion conditions, but the use case is self-evident for a zero-parameter list tool.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the 'current document' scoping context but does not explain how that document is selected or what the response shape is, so it provides only modest value beyond the annotations.

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

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

One short sentence with no filler; the resource and scope are front-loaded and every word carries meaning. This is appropriately sized for a simple read-only list tool.

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

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

For a one-parameter, read-only, idempotent list operation, the description covers the essential operation and scope. It is slightly incomplete because it does not describe output shape or how 'current document' is established, but these are minor for such a simple 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% and the description makes no mention of the limit parameter, so it adds no meaning beyond the input schema. The schema itself is clear (optional integer with default 500, min 1, max 5000) and the parameter name is intuitive, but the description fails to compensate for the missing parameter context.

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

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

The description names the resource (keywords) and the scope (current document), so an agent can tell it apart from sibling list tools. It is phrased as a noun phrase rather than an explicit action like 'Lists all keywords...', which keeps it from being a perfect 5.

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

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

It offers only implied usage: for reading keywords in the current document. There is no explicit statement of when to use this versus co_list_variants, co_list_documents, or other list siblings, and no exclusions or prerequisites are mentioned.

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 reveal readOnlyHint/idempotentHint/destructiveHint, so the description only needs to add behavioral detail beyond safety. It adds valuable context: layers lack ids and are accessed by index, with the background layer fixed at index 0. This goes beyond what annotations provide and helps agents reason about addressing.

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

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

Two sentences deliver the core purpose, layer atypical identity, and addressing scheme without filler. The most important information is front-loaded, and no words are 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?

Although the description thoroughly explains what a layer looks like and its index-based identity, it omits parameter semantics. Since there is no output schema and no explanation of the two parameters, the agent is left without crucial invocation information. The description is adequate for a simple idealized read but not complete enough for a real tool 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%: neither `variant_ids` nor `use_current_selection` are described in the schema or the tool description. The description refers to 'variants' but does not explain the parameters, their roles, defaults, or interplay such as when one vs. the other is used. With two parameters and no property descriptions, an agent has to guess how to fill out the request.

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 starts with a specific action, 'List the layers on variants', and names the output fields (kind, enabled state, opacity, luma-range settings). It clearly distinguishes this from sibling tools like co_list_variants by focusing on layers, and adds useful identity details (no id, index addressing, background at index 0).

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

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

The description implies usage on variant layers and indicates that layers are addressed by index, but it does not explain when to prefer this over alternatives like co_get_variant, nor does it mention exclusions. There is no explicit 'when to use this vs. that' guidance, only the implied context of variants having layers.

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, and destructiveHint=false, so the safety profile is covered. The description adds value by clarifying the tool returns 'type and allowed values' for writable properties, which tells the agent what kind of output to expect despite there being no output schema.

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

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

The entire description is one focused sentence that leads with the action and resource, then adds the key qualifier ('writable') and the output content ('type and allowed values'). Every word earns its place.

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

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

For a parameterless, read-only listing tool, this description is complete: it identifies what is listed, the depth of the information returned, and why an agent would call it. No additional context is necessary to invoke it correctly.

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

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

The tool has zero parameters and an empty input schema, so there are no parameter semantics to document. The baseline for zero parameters is 4, and the description sensibly focuses on output rather than 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 states a specific verb ('List') and resource ('every writable recipe property'), including the useful detail that it reports type and allowed values. It also connects to a specific downstream tool (co_configure_recipe), making its purpose unambiguous and distinct from siblings like co_list_recipes or co_get_recipe.

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 'for use with co_configure_recipe' gives an explicit usage context and tells the agent why it would invoke this tool. It does not explicitly name alternatives to avoid or conditions for not using it, but the intended use case is clear enough.

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 read-only, idempotent, non-destructive nature, so the description does not need to repeat those. The description adds useful behavioral context by naming what the returned list contains (format and enabled state), which is material since the schema is not provided. It doesn't reveal hidden behaviors like pagination or ordering, but none are clearly warranted for a zero-argument list tool.

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

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

The description is one compact sentence that front-loads the verb and resource, then supplies the two key fields and the document scope. It is immediately scannable and contains no filler or redundancy.

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

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

For a zero-parameter, read-only list tool with annotations covering safety and with no output schema, the description gives a sufficient scope and an indicator of the returned fields. It could have been slightly more precise about the relationship between 'output recipes' and the similar recipe-related siblings, but the tool is simple enough to invoke correctly from the shown definition.

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

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

There are zero parameters, so the schema is entirely descriptive. Since 0 params get a baseline of 4 under the rubric, the description doesn't need to add parameter details. The 'current document' scoping is contextual rather than parameter information, so no additional justification is needed beyond the baseline.

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

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

The description identifies a clear verb ('list'), a resource ('output recipes'), the scope ('current document'), and the fields returned ('format and enabled state'). It is specific enough to convey what the tool does, but it does not explicitly differentiate itself from siblings like co_list_recipe_properties or co_get_recipe, so it doesn't earn 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 phrase 'in the current document' gives a usage context, implying this is the right tool for the current document's recipe overview. However, there is no explicit guidance about when to choose co_list_recipes over alternative listing tools, and no when-not-to-use instructions.

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 read-only, idempotent behavior, and the description adds a meaningful limitation: only names are exposed, not the contents of styles or presets. This helps set agent expectations about what the query can return.

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 compact sentence immediately states the output and then adds the key limitation. No filler, no repetition of the tool name, and the most decision-relevant detail is front-loaded.

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

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

For a zero-parameter read-only listing tool, the description covers scope and output shape well enough. It omits details like sorting or error behavior, but those are not essential given the simple nature and the annotations.

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 parametersasi and an empty schema, so there is no parameter detail to add. The baseline of 3 applies because the description does not need to supplement any input definitions.

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

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

The description states the exact output (names of styles and presets) and the product domain (Capture One). It is clearer than just the tool name, though it does not explicitly contrast with sibling list tools such as co_list_recipes or co_list_documents.

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

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

No guidance is provided about when to choose this tool over alternatives. The intended use is implied by the name and resource type, but the description does not mention exclusions, alternatives, or selection criteria.

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 read-only, idempotent, and non-destructive behavior, lowering the bar. The description adds a useful behavioral trait beyond those annotations: extra field groups cost an additional round trip per variant. This is actionable cost information that the agent would not otherwise know.

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

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

The description is compact and front-loaded, with each sentence earning its place: what the tool lists, its primary role, supported filters, and the round-trip cost caveat. There is no filler or redundancy.

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

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

For an 11-parameter tool with no output schema, the description covers the core listing/filtering purpose and an important performance tradeoff, while defaults and scope values are already available in the schema. It does not explain response shape or pagination edge cases, but the read-only annotations and conventional list-tool behavior make it sufficient for correct invocation.

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

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

The description translates several schema parameters into concrete filter categories: rating to min_rating/max_rating, color tag to color_tags, pick flag to pick, filename to name_contains, extension to extensions, and field groups to fields. This meaningfully compensates for the partial schema description coverage, though limit/offset semantics are only lightly implied by 'pagination'.

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

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

The description states a specific verb and resource: list variants, and clarifies what variants are with the parenthetical 'editable instances of images'. It also distinguishes this tool as 'the main way to find images', separating it from sibling list/get tools.

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

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

The description gives clear usage context by positioning this as the primary image-finding tool and advises requesting extra field groups only when needed. It does not explicitly name alternatives or exclusion conditions, so it stops short of full when-to-use/when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds the semantic detail of what the status reflects, but it does not mention behavior such as caching, staleness, or whether the response is a snapshot. No contradiction exists.

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

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

A single concise sentence that front-loads the key information. There is no filler, repetition, or unnecessary 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 zero-parameter, read-only status tool, the description is almost complete: it states what is measured and what is reported. The only minor gap is the exact representation of 'jobs still pending' (e.g., count vs. list), but since there is no output schema and no input requirements, this is a small omission.

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

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

There are zero parameters and schema coverage is 100%, so the description has no parameter burden to carry. Per the baseline for parameterless tools, it does not need to add anything further.

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 (the processing queue) and the specific metric (current depth and pending jobs). It lacks an explicit verb like 'returns' or 'gets,' but the intent is unambiguous and it is easily distinguished from sibling tools like co_status by naming the queue specifically.

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

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

The description implies usage for monitoring queue state, but it provides no explicit guidance about when to use this tool versus co_status or other siblings, and it offers no exclusions or alternatives. The use case is inferable but not stated.

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

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

The annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true) indicate a mutating selection operation. The description adds the crucial clarification that only view state changes and no image data/metadata/library is modified, which meaningfully tempers the destructive hint. It does not detail side effects of replace/add/remove beyond the schema, but the disclosure is solid. No contradiction with annotations.

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

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

Three sentences, all dense with meaning: purpose, behavioral qualifier, and use cases. No filler or repetition. The key constraint (view state, non-destructive to data) is front-loaded near the verb.

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

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

The description covers purpose, side effects, and likely usage intents. With no output schema, a tool that mutates selection state needs to clarify what happens and what doesn't; it does. It doesn't mention how selection interacts with the current document/collection context, but that's inferable from sibling names and the variant_ids parameter.

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

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

Schema coverage is 100% with clear per-parameter descriptions ('Variant ids from co_list_variants', mode enum with 'replace, add, remove'). The description adds no parameter-level detail beyond the schema, so baseline 3 is appropriate.

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

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

Clearly states the action ('Change which variants are selected'), the target system ('in Capture One'), and immediately distinguishes it from data-modifying operations ('Selection is view state — no image data, metadata or library structure is modified'). This is a specific verb+resource description that leaves no ambiguity about what the tool does.

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

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

Provides concrete use cases ('stage a set for the user to look at', 'set up a subsequent selection-scoped call'), giving clear context for when to invoke it. It does not explicitly name sibling alternatives or when not to use it, which prevents a 5.

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

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

Description explicitly states 'no image data is touched' and 'changes only what is displayed', while annotations mark destructiveHint=true. This directly contradicts the annotation's implication of destructive side effects, so per rubric this dimension must score 1.

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

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

Two tight sentences; the first states the action and lookup key, the second preempts concerns about data mutation. 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 setter with no output schema, the description gives enough information to invoke it and states its only side effect. It doesn't explain whether the focused collection becomes the active context for subsequent sibling calls, but that is a minor gap given the tool's simplicity.

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

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

Schema covers 100% of the single parameter, describing it as 'Collection name (case-insensitive) or its id'; the tool description merely repeats 'by name or id' without adding format, examples, or disambiguation. Baseline 3 applies because the schema does the heavy lifting.

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

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

States a specific action ('Focus a collection') on a specific resource ('in the Capture One browser') plus the selection key ('by name or id'). It differentiates itself from sibling collection/list tools by clarifying it changes the browser view rather than returning or modifying collection data.

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

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

The description conveys the intended use: switching the current collection in the browser. It doesn't name alternative tools or explicit exclusion conditions, so it stops short of 5, but the context ('changes only what is displayed') provides enough guidance for an agent to select it over data-returning sibling tools.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context beyond annotations by specifying what signals the status reports, particularly 'whether Apple Events are actually getting through' and which write tiers are enabled.

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

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

Two tight sentences: the first front-loads the scope with a colon-delimited list of contents, and the second gives the key usage rule. Every part earns its place with no redundancy.

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

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

For a zero-parameter, read-only status tool, the description covers what the tool reports and when to call it. The missing output schema does not create a gap because the described status fields are sufficient for an agent to interpret the result.

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

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

The input schema has zero parameters and 100% schema description coverage, so there is no parameter semantics for the description to add. This matches the 0-parameter baseline of 4.

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

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

The description names a specific diagnostic resource and enumerates concrete contents: running state, Apple Events delivery, app version, open document, and write tiers. It is clearly distinguishable from sibling tools, which focus on documents, variants, recipes, and selection actions.

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

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

The instruction 'Call this first when anything else times out' provides an explicit, actionable trigger for using this tool. It does not name a specific alternative or state when not to use it, but it supplies clear context for the primary diagnostic scenario.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context by clarifying that results come from Capture One's output history and include whether each file still exists on disk. However, it does not disclose return ordering, pagination, or failure behavior, so it is adequate but not rich.

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 focused sentence with no filler, and the most distinguishing detail—output history plus existence status—is front-loaded. It is appropriately terse, though it sacrifices useful context.

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

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

With no output schema and no parameter guidance, the tool is incomplete for safe invocation. Annotations cover the mutation/safety profile, but the selection-mode ambiguity and lack of return-shape information leave significant gaps.

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

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

Schema description coverage is 0%, and the description does not explain variant_ids or use_current_selection at all. The boolean switcher's relationship to the variant_ids array is entirely undocumented, forcing the agent to guess how to select variants.

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—previously written output files for variants, sourced from Capture One's output history, with existence-on-disk status. This distinguishes it from sibling tools like co_list_variants or co_get_variant, though it lacks an explicit verb such as 'list' or 'retrieve'.

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

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

There is no guidance on when to use this tool versus related sibling tools, nor any explanation of when to supply variant_ids versus set use_current_selection. The description states what the tool returns but not how an agent should choose between the available selection modes.

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