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

With no annotations, the description must carry the full behavioral burden, and it does disclose several important traits: output is editable vector (not raster), bare elements use canvas pixel coordinates, and external references are restricted to #ids and data: URIs. It omits what happens to pre-existing content on the target layer, what the call returns (shape ids? layer name?), and error behavior, which are material for a mutation tool with zero annotation coverage.

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

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

Four short sentences, front-loaded with the core capability and the element list, then the coordinate rule, then layer targeting, then constraints. No filler; the element enumeration is dense but earns its space as a validity constraint.

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 3-parameter, no-output-schema, no-annotation mutation tool, the description covers input content rules and layer targeting well but leaves the return value and post-call state unaddressed. An agent could invoke it correctly but could not predict the result or verify success from the definition alone.

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

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

Schema coverage is 0%, so the description has to compensate and largely does: `svg` is defined by allowed element set, coordinate convention, and reference restrictions; `layer` is constrained to a vectorlayer; `name` is explained as the name for a newly created vector layer. The `name`/`layer` interaction is clarified, though the precedence when both are supplied is only implied by the ordering.

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 ("Add") and resource (SVG elements as editable vector shapes), and enumerates the supported element types, which lets an agent distinguish this from raster drawing tools like draw_shapes. It stops short of naming the closest sibling (e.g. draw_shapes or import_image) explicitly, so the differentiation is inferable 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?

The layer-resolution rule (explicit `layer`, else active vector layer, else new layer named `name`) is a concrete usage rule that guides invocation. However, there is no statement of when to prefer this over draw_shapes or import_image, and no exclusions or failure conditions.

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

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

With no annotations, the description carries the full burden, and it does disclose the key behavioral trait: the effect is applied to a new layer on top, so it is non-destructive and reversible via opacity or deletion. That is genuinely useful beyond what structured fields provide. It does not say whether the tool needs an active selection, what the new layer is named, or what the result looks like on failure.

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 core effect front-loaded and the lifecycle note trailing. Nothing is redundant or padded. It is arguably too terse for a four-parameter tool, but as prose it is well-formed.

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?

Four parameters with zero schema descriptions, no annotations, and no output schema mean the description is the only documentation — and it explains none of the inputs. For a tool with adjustable size, color, strength, and blend mode, the definition leaves the agent guessing at nearly every argument.

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% — the four parameters (size, color, strength, blend_mode) have only titles and defaults. The description compensates only obliquely: 'darken' and 'tint' imply color, 'edges' implies size, and 'darken' implies strength, but no parameter is named or explained. An agent cannot learn valid ranges, units, or what blend_mode values are legal from this definition.

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 pairs a specific verb ('Darken (or tint)') with a specific effect ('the edges') and states the mechanism ('on a new layer on top'). That is far clearer than the bare name 'add_vignette' and an agent can predict the visual result. It stops short of distinguishing itself from sibling effect tools like apply_filter or adjust_image, so it lands at 4 rather than 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?

Usage is only implied: the phrase 'adjust its opacity or delete it later' signals a non-destructive workflow, which hints at when this is preferable to a baked-in filter. There is no explicit statement of when to choose add_vignette over apply_filter, nor any prerequisite such as an open document or active layer. The agent must infer the context.

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

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

With no annotations, the description carries the full burden. It does disclose meaningful behavior: non_destructive=true creates an editable filter mask rather than baking pixels, and 'exact tone tools (pixel-precise)' vs 'Krita filters' signals a fidelity distinction. However it never states what happens when layer is null (presumably active layer), whether the default path is destructive/undoable, or what the call returns — significant gaps for a mutation tool with zero annotation coverage.

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?

Purpose is front-loaded in the first clause, followed by a tightly formatted catalog that is dense but scannable and where each line names a distinct valid operation. There is minor redundancy — gamma appears both standalone and inside levels — and the bulk of the text is reference material an agent must read in full, but nothing is padding.

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

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

For a complex, four-parameter tool with 0% schema coverage and no output schema, the description supplies nearly everything an agent needs to construct a valid call, including the escape hatch to apply_filter. It falls short only on layer resolution semantics and on any hint of return/result behavior, which matter because there is no output schema to fall back on.

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, and it largely does: the operation vocabulary is enumerated exhaustively with per-operation settings keys and numeric ranges (e.g. brightness/contrast -100..100, curves points 0-255, dodge/burn exposure 0-1). The notable gap is the `layer` parameter, which is never explained despite defaulting to 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?

The opening line gives a specific verb and resource — 'Photo adjustment on a paint layer (limited to the selection if any)' — and the closing line explicitly routes non-listed Krita filters to the apply_filter sibling. What's missing is differentiation from other adjustment-flavored siblings such as auto_enhance, add_vignette, or colorize_lineart, so the agent must infer that those are separate 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 a real routing rule: any filter not enumerated here should go to apply_filter, and the selection caveat tells the agent when the effect is scoped. There is no explicit 'use this when / don't use this when' for the overlapping siblings (auto_enhance, add_vignette), so guidance is clear but incomplete.

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

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

No annotations are provided, so the description carries the full burden. Its 'Which services are connected' framing implies a read-only discovery operation, and it discloses the categories of returned data (models, samplers, upscalers, workflows, avatars and voices when details=true). It says nothing explicitly about side effects, permissions, or cost, and does not describe the response shape.

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, front-loaded with the core purpose, and the actionable call-before-generate_image rule is placed last for emphasis. The long vendor enumerations are informative but slightly heavy; trimming them would lose useful completeness, so this is close to optimal.

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

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

With no output schema and 0% schema coverage, the description must serve as documentation, and it does name the returned categories and the workspace workflows path. However, it does not describe the response structure (key names, per-backend shape, error when nothing is connected), leaving gaps for an agent that needs to consume 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?

Schema coverage is 0%, so the description must compensate for the single undocumented boolean. It does: 'details=true lists HeyGen avatars and voices' explains what the flag adds. It is incomplete because it does not say whether details affects other backends or what the default (false) yields, but it still adds real meaning beyond the bare boolean.

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 a discovery query for connected generative-AI services, enumerating image backends, video backends, vision models, and ComfyUI workflows. It has no single leading verb like 'list' or 'get', but the enumerated scope distinguishes it well from siblings such as generate_image, generate_video, and ask_vision.

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 an explicit precondition: 'Call this before generate_image.' That is a concrete when-to-use rule tied to a named sibling. It does not mention generate_video or ask_vision, even though the tool also reports video backends and vision models, so the guidance is clear but not exhaustive.

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. It usefully discloses that analysis can target the whole image, a region, or a single layer, and it describes the shape of the returned metrics. It does not state that the operation is read-only/non-mutating, nor mention cost or performance characteristics of the pixel-heavy metrics.

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

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

Front-loaded with the returned content, then the usage hint. Parentheticals ('or a region / one layer', 'top row first') each add real information rather than padding. It is dense but no sentence 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?

For a 7-parameter, unannotated, no-output-schema tool, the description does substantial work by enumerating the returned metrics. Gaps remain around the coordinate space for x/y/width/height, default behavior when no region or layer is given, and whether region and layer can be combined — details an agent needs to call it correctly.

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

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

Schema coverage is 0% and parameter titles are bare tokens (X, Y, width, height, grid, layer, palette_size). The description partially compensates: 'a region' implies x/y/width/height, 'one layer' maps to layer, '(top row first)' explains grid ordering, and 'dominant palette with shares' relates to palette_size. However, it never says x/y are the region origin, how width/height default when omitted, what grid=3 vs other values means, or how region and layer interact.

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 resource and enumerates the measurements returned (dominant palette with shares, mean colour, brightness, contrast, sharpness, non-transparent coverage, content bounds, grid of mean colours), which makes it clearly distinct from siblings like sample_color or palette_colors. It never names those siblings explicitly, so differentiation is inferred from the output list 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?

The final sentence gives one positive usage condition: 'Use it to judge and match colours and lighting.' There is no guidance on when to prefer sample_color, palette_colors, read_pixels, or ask_vision instead, and no prerequisites or exclusions are stated.

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

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

No annotations are supplied, so the description carries the full disclosure burden and covers very little beyond the visual layout. It does not say whether the call is read-only or side-effect free, what form the result takes (rendered image versus data), how ranges exceeding 48 frames are handled (truncation, sampling, or error), or what the default step is.

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

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

A single tight sentence with the useful detail (max 48, labelled grid) front-loaded and no filler. It is efficient, though its brevity is part of why key parameter and behaviour details are absent.

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?

A five-parameter, all-optional tool with no annotations and no output schema leaves the description responsible for range/default semantics and for what the returned artifact is, neither of which it addresses. The max-48 note is helpful but not enough for an agent to call it confidently with a non-default range.

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 five parameters, and the description supplies almost no compensating meaning beyond the implicit frame-count cap. Start/end/step and columns/cell_size are guessable from their names, but there is no stated default behaviour for omitted values or interaction between step and the 48-frame limit.

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

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

The description states a concrete output artifact (a labelled grid of frames, max 48) and its purpose (reviewing motion and consistency), which goes beyond restating the name. It doesn't explicitly contrast with neighbouring preview tools such as view_image, canvas_snapshot, or export_animation_frames, so the boundary is inferable 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?

The stated intent 'to review motion and consistency' implies when the tool is appropriate, but there is no explicit when-not guidance or named alternative (e.g. use export_animation_frames for full-resolution output, view_image for a single frame). The max-48 cap is the only hard constraint 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?

No annotations are supplied, so the description carries the full behavioral burden. It implies a read-only retrieval by listing fields, but never states that it is non-mutating, whether it requires an active document or animation, or what happens if no animation exists. For a zero-annotation tool this is a meaningful gap.

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

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

It is a single short fragment with no wasted words, but it is under-specified rather than concise: a bare field list with no framing sentence. Front-loading is fine, but the fragment lacks a subject or verb to anchor 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?

With no output schema, the description must convey return values, and the field enumeration does that partially. However, it omits the shape of the response (units, structure, whether layers are names or objects) and any precondition, leaving the agent with an incomplete picture of a simple but undocumented 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The field list does at least signal what the call surfaces, though it is not parameter information.

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

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

The description is a noun phrase enumerating returned fields (frame rate, playback/clip range, current frame, animated layers) rather than a verb+resource statement. The resource is inferable from the name 'animation_info', but the description never says 'retrieves' or 'returns', so the agent must infer that this is a read operation distinct from animation_set or list_keyframes.

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: no mention of when to call this versus animation_set, keyframe, list_keyframes, or video_info. The agent is left to infer usage purely from the tool name and the field list.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that going to a frame makes subsequent edits apply to that frame, but it omits whether setting fps or frame range affects existing drawings, whether the operation is undoable, and what permissions or setup are required.

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 covering purpose and key parameters without waste. The parentheticals add needed clarification, though the sentence is slightly dense.

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 four-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description is minimally viable. It explains the purpose and broad parameter meanings but omits behavioral details like side effects, undoability, and constraints, which leaves meaningful 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?

With 0% schema description coverage, the description must clarify the four parameters. It maps each one reasonably: fps is frame rate, start..end is frame range, and frame is the navigation target. However, it does not add constraints such as valid fps values, start/end ordering, or frame bounds.

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 ('Set') and resources ('frame rate, frame range, and/or go to frame'), making the tool's intended action clear. It does not explicitly differentiate from siblings such as animation_info or keyframe, but the setter semantics are evident.

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 that the parameters can be combined ('and/or') but gives no explicit when-to-use guidance, no prerequisites, and no instructions on when to use animation_info instead. It leaves usage decisions to inference.

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

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

With no annotations at all, the description carries the full burden for a mutation tool. It discloses selection-restricted application, but not whether the edit is undoable, whether it mutates the layer in place, what happens if the target is not a paint layer, whether an omitted layer means the active layer, or what the call returns on failure.

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

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

Two sentences, front-loaded with the action and scope, with no filler. The second sentence's param note earns its place, though the phrasing is slightly compressed to the point of ambiguity about the 'name' parameter.

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 mutation tool with no annotations and no output schema, the definition covers the essential workflow (discover filter properties, then apply). Gaps remain around layer defaulting, return values, and undo/error behavior that an agent would need before committing a destructive edit.

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 does partially: it explains that params holds filter properties obtained from describe_filter and that only string/number/bool values are accepted. However 'name' allowed values are only hinted ('blur, levels, invert, ...'), 'layer' semantics with default null are never explained, and 'ignore_selection' is only obliquely implied by 'restricted to the selection if any'.

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

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

The description gives a specific verb and resource ('Apply a Krita filter') plus scope ('to a paint layer, restricted to the selection if any'), with example filters (blur, levels, invert). It implicitly separates itself from describe_filter/list_filters by consuming their output, though it never explicitly contrasts with the sibling adjust_image family.

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 note that params come 'from describe_filter' tells an agent to call describe_filter first, which is a useful workflow hint. There is no explicit statement of when to prefer this over adjust_image/auto_enhance, no preconditions, and no when-not guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does explain how ordering and parenting work, including precedence when `to`/`above` are provided, but it omits mutation-related details such as required target identification, failure behavior, and whether restacking affects grouping or rendering 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-loaded with the core action, then efficiently defines the key parameter interactions. Every clause contributes directly to invoking the tool correctly.

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 layer-ordering tool with no annotations, no output schema, and no schema descriptions, the description covers the main placement semantics adequately. However, it is incomplete because the target `layer` parameter is never explained and there is no clarification of required versus optional combinations.

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 define the parameters. It usefully explains allowed `to` values, sibling placement via `above`, and group placement via `parent`, but it does not describe the `layer` parameter at all, leaving a central input 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 a specific action and resource: 'Restack a layer.' It also explains the main restacking modes, making the tool distinguishable in practice from layer creation, deletion, or transformation tools, though it does not explicitly contrast itself with those 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?

Usage is implied by 'Restack a layer' and by the descriptions of `to`, `above`, and `parent`, but there is no explicit guidance on when to choose this over sibling layer tools or when not to use it. The parameter modes provide some context, but the agent must infer the appropriate 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?

With no annotations, the description carries the full burden. It usefully discloses that calls go to an external provider (Anthropic, OpenAI-compatible servers, Gemini) and that canvas scope can be narrowed to a region or single layer, implying a read-oriented operation. It omits critical operational context: whether API keys/backends must be configured, latency/cost, what happens when no region is given (full canvas?), and whether the call has any side effects.

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

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

Roughly three sentences: purpose and output forms are front-loaded, followed by the provider enumeration. There is little waste, though the provider list is dense and could be better separated from the capability statement.

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 nine-parameter tool with no annotations and no output schema, the description covers purpose and provider choice but leaves credential setup, default capture scope, image downscaling behavior, and return-shape expectations unstated. It is workable but not complete enough that an agent could invoke it confidently without trial and error.

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 nine undocumented properties. It explains provider (with concrete values), model (implicitly via Claude/GPT/Gemini), and that a region or single layer can be targeted, which maps loosely to x/y/width/height/layer. It says nothing about max_size (default 1024), coordinate units, or how width/height interact with x/y, leaving several parameters unexplained.

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

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

The description uses a specific verb and resource ('Ask another vision AI about the canvas and get its answer as text') and enumerates the output kinds (critique, caption, image-model prompt). It implicitly differentiates from local siblings like analyze_image or read_pixels by emphasizing 'another vision AI', but never names those alternatives explicitly, so an agent must infer the split.

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 three listed use cases (second opinion/critique, caption, prompt generation) give implied usage context. However, there is no explicit when-not guidance, no mention of how this differs from local analysis tools in the sibling list, and no mention of prerequisites like configured API credentials.

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 full burden. It implies a destructive tonal change but doesn't say whether it modifies the active layer, creates a new one, is undoable, or how it interacts with the layer parameter; the mechanism of clipping is only hinted at.

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 effect front-loaded; the parenthetical adds useful detail without waste. It is short, though its brevity is also the source of its gaps.

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

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

For a mutation tool with no annotations, no output schema, and 0% schema description coverage on three parameters, the description is far too thin. An agent cannot know how the parameters alter behavior or what the operation does to the document.

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 all three parameters (layer, per_channel, clip_percent) need explanation. The description only partially explains per_channel's effect (removing colour casts) and says nothing about what layer selects or what clip_percent controls or its valid range.

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 ('stretch the tonal range') and names the additional effect of the per-channel mode ('removes colour casts'). It is distinguishable from siblings like adjust_image or match_colors, though it doesn't explicitly say it contrasts 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?

There is no guidance on when to use auto_enhance versus adjust_image, match_colors, or colorize_lineart. The phrase 'one-click photo fix' implies a quick automatic correction, but the agent gets no conditions for choosing this over manual adjustment 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?

No annotations exist, so the description carries the full behavioral burden. It does disclose ordering, the 200 cap, non-recursiveness, and that images come back after the summary, but it says nothing about failure semantics: whether a failing operation aborts the remainder, whether completed operations persist, or whether any of this is destructive or reversible. For a tool that can execute up to 200 mutating calls, that is a major omission.

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

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

Three dense sentences, no filler: capability, payload format with a concrete example, then return behavior and the performance rationale. Front-loaded and sized well for a tool whose schema is nearly empty.

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 annotations, the description does cover return shape ('one result per operation', images after the summary) and the nesting restriction. It falls short on error handling and on 'stop_on_error', which is exactly the information an agent needs to decide whether a long batch is safe.

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%, yet the description fully explains the shape of 'operations' via the inline example (tool name plus args object) and its bound. The second parameter, 'stop_on_error', is never mentioned in the description, and the JSON schema carries only a title and default true — so its behavior on partial failure is undocumented in both places.

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 several tool calls in one go, in order'), shows the literal argument shape with an example, caps it at 200, and excludes the recursive case ('Any tool except batch itself'). An agent immediately knows this is a meta-dispatch tool distinct from every single-purpose 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?

It implies usage conditions ('Much faster than one call per step') and states the one hard exclusion, but never says when batching is wrong — notably whether later calls can depend on earlier results, or whether the agent should fall back to individual calls when it needs intermediate output. That missing negative guidance matters for an orchestrator tool.

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

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

With no annotations, the description carries the full burden and does much of it: it discloses that pressure only works with a pressure-sensitive preset, that strokes are clipped to the current selection, and that the user's own brush settings are restored afterwards (an important side-effect guarantee for a mutation tool). It still omits the return value and whether the stroke is undoable as a single step.

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?

Compact and front-loaded with the core action, then grouped parameter notes. The telegraphic style ('size in px, opacity/flow 0..1') is efficient rather than bloated, though the fragmentary formatting is slightly harder to parse than full sentences.

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 12-parameter mutation tool with no annotations and no output schema, this covers the critical calling semantics well, including the settings-restoration side effect. The remaining gaps are the undocumented color/layer parameters and the lack of any statement about what is returned or how failures surface.

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 does for most parameters: points accept [x,y] or [x,y,pressure], preset takes a name or unique fragment and defaults to the current brush, size is in px, opacity/flow are 0..1, eraser paints with the brush in erase mode, smooth interpolates a curve, and closed/fill/outline are explained. It leaves 'color' and 'layer' entirely undocumented, which matters for a tool with 12 parameters.

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

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

States a specific verb and resource ('Paint ONE stroke with Krita's real brush engine'), and the emphasis on ONE stroke plus the texture/wet-mixing phrasing distinguishes it from vector siblings like draw_shapes and from fill_selection. An agent can tell immediately that this is the raster-brush painting 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 rather than stated: it points to list_brush_presets for preset discovery and notes that painting respects the current selection, which is use-relevant context. However, it never says when to choose this over draw_shapes, fill_selection, or krita_action, and there are 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?

With no annotations, the description carries the full burden. It does disclose two important behaviors: a new document is created by default, and render_path additionally renders the result to a file. It does not state whether the source document is modified, whether the operation is undoable, or how long rendering takes, leaving meaningful gaps for a mutation tool.

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

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

The core purpose is front-loaded in the first clause, and the long move list is compactly enumerated rather than prose-wrapped. The text is dense and slightly run-on, but nearly every token carries 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 7-parameter tool with no annotations and no output schema, the description covers the key creative controls and the side effect of document creation, but omits output dimensions, frame rate, and duration semantics. An agent could call it correctly with defaults but would be guessing on several 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 compensate, and it does for the most important parameters: it enumerates all 19 valid 'move' values (the schema has no enum), gives the intensity range 0.1-3, and shows a render_path example. It leaves fps, width, and seconds undocumented, so it is strong but not 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?

States a specific verb and resource ('renders the current picture through a moving virtual camera into an animation') and explicitly distinguishes itself from AI-based siblings with 'without any AI model', which separates it from generate_video/generate_image. An agent can identify the tool's function without opening the schema.

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

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

The phrase 'without any AI model' implies this is the non-generative alternative to generate_video, and 'a new document by default' hints at the default workflow. However, there is no explicit when-to-use/when-not guidance or named alternative, so the routing signal is only implied.

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

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

With zero annotations the description carries the full burden, and it does disclose real behavior: the frame option temporarily switches animation frame and restores the current one (a side effect worth knowing), layer blanking makes everything else transparent, grid burns labelled coordinate lines into the returned image, and max_size caps the longest side. What is missing is the return channel (image content vs. path) and whether output is cached or re-rendered per call.

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

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

The core purpose is front-loaded in the first clause, then each optional behavior gets exactly one compact clause. No filler, no repetition of the schema, and the parenthetical layout makes scanning for the parameter of interest trivial.

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

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

For an 8-parameter, zero-annotation, no-output-schema tool this is close to self-sufficient: all options are explained and the frame-restore side effect is called out. Minor omissions remain – the layer value format and the response format – but neither would likely cause a failed 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 do all the work, and it covers nearly every parameter: x/y/width/height are in canvas pixels, max_size caps the longest side with a stated 64-4096 range, and grid/layer/frame each get a one-line meaning. The gap is the layer parameter, whose accepted value form (name vs. id/index) is never specified, and no hint that x/y/width/height must be supplied together as a region.

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?

"Return the current composite image so you can SEE the canvas" names a concrete verb (return) and resource (composite canvas image), and the follow-on options (zoom, layer isolation, grid overlay, frame) describe capabilities that clearly are not those of siblings like view_image or export_image. It stops short of explicitly naming which sibling it replaces, so the differentiation is inferred from capabilities 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?

Usage is implied through purpose clauses – "so you can SEE the canvas", "to read off exact positions" – which tell the agent the intended scenarios for grid and zoom. However, no alternative is named: an agent choosing between canvas_snapshot, view_image, read_pixels, and analyze_image gets no explicit when-to-pick-this guidance, and no 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?

With no annotations, the description carries the full burden; it usefully explains the flood-fill behavior and the semantics of transparent_color for leaving areas empty. However it never says whether a new layer is created (the 'name' default of 'Colourise' hints at it), whether the operation is destructive or undoable, or how it interacts with an existing layer.

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 with the core action and the region format front-loaded, no filler. The inline JSON fragment is slightly awkward but earns its space as the only specification of the regions structure.

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

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

For a six-parameter mutation tool with no annotations and no output schema, the description covers only the regions shape and transparent_color. It omits return values, whether a layer is created or modified, and the meaning of cleanup/edge_detection, which an agent needs 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 description coverage is 0%, so the description must compensate, and it does well for 'regions' — supplying the exact object shape with color/points or color/rect, which the schema only types as a generic object array. But 'name', 'layer', 'cleanup' (default 0.7), and 'edge_detection' are entirely unexplained, leaving four of six parameters opaque.

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?

Opens with a specific verb+resource: "Flat-colour line art with Krita's Colourise Mask," and explains the underlying mechanism (flooding each scribble's colour up to the lines). An agent can distinguish this from generic painting tools like brush_stroke or fill_selection, though no sibling is named 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?

No statement of when to use this versus alternatives such as fill_selection, apply_filter, or brush_stroke, and no prerequisites (e.g. whether a line-art layer must be active). Usage is only inferable from the mechanics described.

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

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

With no annotations at all, the description carries the full behavioral burden and leaves the most important traits unstated: whether the conversion is destructive or in-place, whether it applies to the whole document, the active layer, or a selection, and whether it returns a new image. It does add one useful default ('Profile defaults to sRGB'), but that is closer to parameter semantics than to 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 verb and resource are front-loaded, and every clause carries information — the depth examples, the model list, and the profile default all earn their place. It is dense to the point of terseness (the line break mid-sentence and compressed phrasing), but there is no filler.

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

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

For a mutation tool with no annotations and no output schema, the definition covers parameters well but omits scope of effect (document/layer/selection) and return behavior. An agent could call it with plausible arguments yet be unsure what it is actually converting or what state it leaves behind.

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, and it largely does: it enumerates valid model values (RGBA, GRAYA, CMYKA, LABA, XYZA), states the profile default (sRGB), and gives depth examples (U16/F16/F32, RGBA/U8). The gap is that depth's valid values are only shown by example rather than enumerated, and the profile's accepted form (path vs. name) is never clarified.

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

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

The description names a specific verb and resource ('Convert the image colour space') and grounds it with concrete examples (U16/F16/F32 depth for grading, RGBA/U8 for pixel tools), which distinguishes it from siblings like adjust_image or match_colors. It stops short of explicitly contrasting with those siblings, but the operation is unambiguous.

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

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

Use cases are implied rather than stated: 'for high-precision grading' and 'back to RGBA/U8 for pixel tools' hint at when a caller would reach for this tool. There is no explicit when-not guidance, no mention of alternatives such as adjust_image or match_colors, and no prerequisites (e.g. whether the document must be in a certain mode).

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

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

With no annotations, the description carries the full burden and does well: it discloses that painting mode returns a plan rather than an image, that style defaults to a guess from the prompt, and that count defaults to 4 on local GPU but 1 on paid cloud services that charge per image. It does not say what happens to an existing document or how failures surface, which 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?

Front-loaded with the trigger condition and the generate-vs-paint fork, then parameter guidance, then the follow-on workflow. Dense but nearly every clause carries information; the inline enumeration of 20+ style values is long but genuinely useful given the schema has no enums.

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, no-annotation, no-output-schema tool, the description covers the decision logic, the mode-dependent return shape, cost behavior, and the downstream workflow. The unexplained name/seed/model/backend parameters are the main omission, but they are secondary to correct invocation.

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

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

Schema coverage is 0%, so the description must compensate, and it does for most parameters: it enumerates approach values with their decision logic, lists style and aspect options with defaults, explains count's cost tradeoff, and notes width/height as an alternative to aspect. It leaves name, seed, model, and backend entirely unexplained, which is a real gap across 11 parameters.

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

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

States a specific verb and resource ('Creates the document') and immediately splits the two modes: GENERATES with an image model or sets up for PAINT with Krita brushes. The 'START HERE' framing plus the explicit contrast with generate_image and the painting siblings makes it unmistakable which tool to pick.

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 explicit routing rules: 'auto' decides realism/connected model -> generate, hand-made/graphic or no model -> paint, plus hybrid. It also names the follow-on tools (brush_stroke, draw_shapes, add_svg, canvas_snapshot) and the escape hatch to generate_image with a control layer, so the agent knows both when to use this and what comes next.

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

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

With no annotations, the description carries the full burden and does well: it discloses the side effect that the new layer becomes active, that fill/filter layers are non-destructive, that clonelayers and filelayers stay live-linked, that masks attach to parent (defaulting to the active layer), and that creation is clipped to the current selection. It omits failure conditions (no open document, invalid filter name) and whether the operation is undoable.

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

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

The core purpose is front-loaded and the length is defensible given 12 undocumented parameters, but the body is a dense run-on enumeration with dangling fragments ('type:', 'parent = ...; above = sibling to stack over.'). Bullet-per-type formatting would preserve the same content with far better scanability.

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 12-parameter creation tool with no annotations and no output schema, the description covers nearly everything an agent needs to construct a valid call, including nested config shapes. The remaining gap is return behavior — it never says what comes back (e.g. the new layer's id/name), which matters since no output schema exists.

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 12 parameters, so the description must compensate and largely does: fill, path, parent, above, filter, filter_params, source, pattern, generator, generator_config, and type each get concrete meaning, including worked generator_config examples for seexpr, screentone, and gradient. Only 'name' (default 'Layer') is left to obvious inference.

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 up front ('Create a layer or mask') and then enumerates every creatable type (paintlayer, vectorlayer, grouplayer, filllayer, filterlayer, clonelayer, filelayer, filtermask, transparencymask). This makes it unmistakable versus siblings like update_layer, duplicate_layer, or delete_layer, and the 'becomes the active layer' clause fixes the resulting state.

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?

Guidance is embedded per type: filllayer for non-destructive colour/pattern, filterlayer for non-destructive adjustment of everything below, clonelayer for live mirroring, filelayer for a live-linked image, plus the selection caveat and the parent default of 'active layer'. It never names a sibling to use instead (e.g. update_layer for modifying an existing layer), so the when-not path is left implicit.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It never says that cropping discards pixels outside the rectangle, whether the operation is undoable, or what happens if only some of x/y/width/height are provided. For a destructive canvas mutation with zero annotation coverage, this is a substantial gap.

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

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

A single well-formed sentence with the primary behavior front-loaded and the fallback clause second. Nothing is wasted and nothing is buried.

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 annotations, no output schema, and four completely undocumented parameters, the description should explain coordinate semantics and the destructive nature of the operation. It covers the high-level intent but leaves an agent unable to call it correctly with confidence.

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 four parameters (x, y, width, height) are documented nowhere. The description only alludes to a 'rectangle' without specifying coordinate origin, units, whether all four must be supplied together, or how partial values are handled.

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

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

The description gives a specific verb (crop) and resource (the canvas), plus the two modes of operation: an explicit rectangle or the current selection's bounds. It implicitly distinguishes itself from siblings like resize_canvas and scale_image, which change dimensions rather than discarding pixels, though it never names 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?

It states the fallback condition clearly: with no rectangle, the selection bounds are used. That is a real usage rule, but there is no guidance on when to prefer crop over resize_canvas or scale_image, and no mention of prerequisites such as an active selection being required for the fallback 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 supplied, so the description carries the full burden for a destructive mutation. It does not say whether the deletion is undoable, what happens to pixel content on the layer, whether it errors when the target is missing, or what the response contains. Only the default-target behavior is disclosed.

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

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

One short sentence with the key behavior front-loaded and no filler. Nothing is bloated, though the brevity leaves the definition thin for a destructive operation.

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

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

For a destructive tool with no annotations, no output schema, and an undocumented parameter, the description is too sparse. An agent cannot tell whether the call is reversible, what identifier to pass, or what it returns.

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

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

Schema description coverage is 0%, and the schema only shows a nullable string with default null, which gives an agent little to work with. The description partly compensates by explaining that omitting the argument targets the active layer, but it never states what form the 'layer' value should take (name, id, index).

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 ('Delete a layer'), which clearly separates it from siblings like create_layer, update_layer, and merge_down. It does not explicitly name those alternatives, but the action is unambiguous.

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

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

The only usage signal is the parenthetical '(default: active layer)', which explains fallback behavior when no argument is given. There is no guidance on when to prefer this over merge_down, update_layer, or remove_vector_shapes, and no mention of prerequisites or cautions before deleting.

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. It does not say this is a read-only, side-effect-free lookup, does not describe the shape of what comes back (parameter names, types, defaults), and does not say how an unknown filter name is handled.

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 efficient sentence with the purpose front-loaded and no redundant wording. It is tight, but tightness here borders on under-specification given the schema documentation gaps.

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

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

The tool is simple, with one parameter and no output schema, and the description does convey the essential contract: return defaults so the agent can construct an apply_filter call. The missing pieces, where `name` comes from and what the returned structure looks like, are noticeable but small 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?

Schema coverage is 0% and the single required parameter `name` has no description in the schema. The description only hints that it identifies 'a filter'; it adds no format, source, or validity information beyond that, so the agent is left guessing what to supply.

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 resource, a filter's default parameters, and frames the tool as introspection aimed at apply_filter. An agent can distinguish it from apply_filter and list_filters, though it never states the retrieval verb explicitly or that the result is keyed by filter name.

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 use case, finding out which params apply_filter accepts, so it is clearly upstream of apply_filter. It never says when not to call it, and it does not tell the agent where the required `name` value comes from (presumably list_filters), leaving a real step to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state whether the switch is reversible, what happens on an out-of-range or stale index, whether unsaved changes matter, or what the tool returns; the only behavioral hint is that indices come from krita_status. For a state-mutating focus switch, this is a significant gap.

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

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

A single short sentence with the action front-loaded and the parameter hint in a parenthetical; 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?

The tool is simple (one required parameter, no nested objects, no output schema), so the description does not need to explain return values. What is missing is only failure behavior for invalid indices, which is a modest gap given the tool's low 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?

Schema coverage is 0% and the schema only declares a bare integer named "Index". The description partially compensates by anchoring the value to krita_status output, but it leaves the base (0- vs 1-based) and the validity range unstated, so the agent still cannot be certain of the correct value to pass.

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?

"Switch the active document" is a specific verb+resource pair that is clearly distinct from sibling document operations such as document_new, document_open, document_info, and document_close. The parenthetical reinforces that this is a focus/selection change rather than a file operation, though it doesn't explicitly name a sibling it is not.

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 "index from krita_status" implies a prerequisite workflow (call krita_status first to obtain valid indices), which is genuinely useful routing information. However, there is no explicit when-to-use/when-not guidance and no mention of what to do if the target document is not yet open (e.g., use document_open instead).

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

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

With no annotations provided, the description carries the full burden and does the most important part: it warns that unsaved changes are discarded and names the flag that prevents that loss. It leaves unstated what happens afterward (whether another document becomes active, or what is returned), which keeps it below 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 short sentences with zero waste, and the destructive default is placed where it will be read rather than buried. Nothing could be removed without losing information.

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

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

For a one-parameter tool with no annotations and no output schema, the description covers the essential risk (data loss) and the escape hatch. It is only slightly short on post-close state, which matters little for correct invocation.

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

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

Schema coverage is 0% and the single parameter `save` has no description, but the prose explains its effect (save=true preserves changes, default discards). That covers the semantics, though it does not state the default explicitly or what a save failure would mean for the close.

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

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

The description gives a specific verb and resource ("Close the active document"), which is immediately distinguishable from siblings like document_open, document_new, or save_document. It does not explicitly contrast itself with save_document, which also concerns the active document, 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?

Usage is only implied by the action itself — an agent can infer it closes whatever document is currently active. There is no statement of when to prefer save_document instead, nor any note that another document must be activated first if a different one should be closed.

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 supplied, so the description carries the full behavioral burden. It contributes one genuinely useful, non-obvious fact – the layer tree is ordered bottom-to-top – and implies a side-effect-free read. It does not state that the call is read-only, what happens with no active document, or how large the returned tree may be.

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 ordering parenthetical is the one addition and it earns its place.

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

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

With no output schema, the description must explain the return value, and it only names two components while 'Active document details' leaves the rest unspecified (dimensions, color space, filename, behavior when nothing is selected). Adequate for a zero-parameter info call, but not fully self-contained.

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 and the baseline of 4 applies. The schema is trivially 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?

States a specific resource (the active document) and enumerates the key payload: the full layer tree and selection bounds. It is clearly a read-only info tool, distinguishable from mutating siblings like update_layer. It stops short of naming a sibling like list_layers, so an agent must infer the distinction itself.

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 by 'info' and 'Active document details' – you call it to inspect the current document. There is no explicit when-to-use, no statement about when to prefer list_layers or krita_status instead, and no note that no document must be open for it to fail.

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 does real work: it fixes the color model, bit depth and colorspace (RGBA 8-bit sRGB, none of which are parameters) and discloses the side effect that the new document becomes active. It does not say what is returned (document id/info), whether creation can fail, or how the document is named on disk.

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 core action and format constraints, then the one parameter nuance. No filler, nothing 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 create tool with zero annotations, zero schema descriptions and no output schema, the description is thin: an agent still cannot tell what the call returns, the units for width/height, or what happens to the previously active document. Only the color-model and background semantics are filled in.

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 5 parameters, so the description must compensate, yet it only clarifies one: background accepts a colour or 'transparent'. Name, width, height and resolution_ppi are left without units (pixels? PPI semantics) or bounds, despite having silent defaults.

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

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

The description gives a specific verb and resource ("Create a new ... document and make it active") and pins down the document format as RGBA 8-bit sRGB. The verb "new" implicitly separates it from document_open and document_activate, though it never names 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?

There is no guidance on when to use this versus document_open (open existing file) or import_image, and no stated prerequisites or restrictions (e.g. whether it's valid with no active workspace). Usage must be inferred entirely from the verb.

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 supplied, the description carries the full burden. It does disclose a meaningful side effect — the opened document becomes the active document — which is real behavioral context an agent needs. It says nothing about what happens to any already-open document, whether the file is locked or read-only, or what errors occur on a bad path, so it is only partially transparent for a state-changing operation.

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

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

A single front-loaded sentence with no filler; each clause (supported formats, workspace source, active-document effect) carries distinct information. Nothing is redundant or re-stated from the schema.

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

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

For a one-parameter tool with no annotations and no output schema, the description covers what is opened, from where, and the resulting state change. It omits the return value entirely (no output schema exists to document it) and does not address interaction with already-open documents, leaving an agent unable to predict the response shape.

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 `path` has no schema-level description, so the description must compensate. It does add one useful constraint — the path is relative to "the workspace" rather than an arbitrary filesystem location — but gives no format, relative-vs-absolute rules, or extension handling.

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

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

The description gives a specific verb ("Open") plus the resource (a file from the workspace) and enumerates supported formats (.kra/.ora/.psd or image), which tells an agent exactly what kinds of files are accepted. It also states the post-condition ("make it active"). It stops short of distinguishing itself by name from close siblings such as document_new, document_activate, or import_image, so a 4 rather than a 5.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no named alternative, despite a dense sibling set where confusion is likely (document_new for creation, document_activate for switching, import_image for bringing in raster content). The format list only weakly implies usage. The agent must infer selection criteria 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?

With no annotations the description carries the full burden, and it discloses a lot: draw order, a 5000-shape cap, anti-aliased rasterization onto a paint layer, coordinate convention (baseline-left for text), and the fill/stroke fallback for color. It still omits whether drawing mutates or overwrites existing pixels, whether the result is undoable, and what happens if the named layer does not exist.

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

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

Front-loaded with the core action and limits, then a compact per-type field table that earns its space as a payload specification. The density is justified by the unstructured item schema, though the type block is reference-manual style rather than narrative.

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

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

Given no annotations, no output schema, and a free-form array payload, the description supplies nearly everything needed to construct a valid call. Missing only return-value expectations (shape ids/counts) and failure behavior for bad layer references or malformed points.

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 does: it enumerates every shape type with its exact field set, documents the 1+3n bezier point rule, the gradient object forms, and defines the layer parameter as an id or name with active-layer default.

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 ('Draw vector-style primitives ... onto a paint layer') plus the ordering and volume bounds. The closing line distinguishes it from brush_stroke, so an agent can pick between the two without opening either schema.

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

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

Names the sibling alternative and the condition selecting it ('for painterly marks use brush_stroke'), and gives the default-targeting rule ('default: active layer'). It does not address how it relates to other shape tools such as add_svg, list_vector_shapes, or remove_vector_shapes.

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 supplied, so the description carries the full disclosure burden, and all it conveys is placement ('directly above the original'). It does not say what the duplicate is named, whether it becomes the active/selected layer, whether the source is the given `layer` or the current selection, or what happens if the layer does not exist. For a mutation tool with zero annotation coverage this leaves significant behavioral gaps.

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 key outcome (placement above the original) is stated immediately. Nothing is wasted or 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?

The tool is conceptually simple and has no output schema to explain, so a short description is defensible. Nevertheless, with two undocumented optional parameters, no annotations, and no note about how the layer is identified or what the duplicate inherits, it falls short of what an agent needs to invoke 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?

Schema description coverage is 0% for both parameters and the description never mentions `name` or `layer`. An agent must infer that `layer` selects the source (and how – by name? by identifier?) and that `name` names the copy, which is exactly the kind of ambiguity the description should resolve. The phrase 'the original' hints at a layer selector but adds no real semantics.

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

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

States a specific verb and resource ('Duplicate a layer') plus the resulting placement ('directly above the original'), which distinguishes it from create_layer or arrange_layer without opening a schema. It does not explicitly name those siblings, 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?

Usage is strongly implied by the word 'duplicate' – use this instead of create_layer when you want a copy of an existing layer. However, there is no explicit when-to-use / when-not-to-use statement, no mention of alternatives like create_layer or transform_layer, and no precondition such as an active layer being required.

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 supplied, so the description carries the entire behavioral burden. It reveals the output format and destination but omits important behavior: that it writes files (a mutation with side effects), what happens on filename collisions or to existing folder contents, whether the range is inclusive, and likely runtime cost for long ranges.

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, front-loaded with the verb and the output artifact, with no filler. Nothing could be trimmed without losing 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 file-writing export tool with four undocumented parameters, no annotations, and no output schema, one sentence is far from sufficient. An agent cannot determine defaults behavior, range semantics, or overwrite risk before invoking it.

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

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

Schema description coverage is 0%, so the description must compensate; it only partially does. 'Numbered' hints that start/end select a frame range and 'workspace folder' maps to folder, but the meaning of start/end (frame indices, inclusive/exclusive, null = all frames) and the role of prefix are left entirely unexplained.

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

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

States a specific verb ('Render') plus the resource ('frames') and the output form ('numbered PNGs into a workspace folder'). It implicitly separates this from render_video or export_image by describing a sequential PNG frame dump, though it never names an alternative 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 when-to-use guidance: no mention of prerequisites (e.g., an animation/document must be active), no indication that leaving start/end null exports the whole timeline, and no pointer to export_image, render_video, or animation_contact_sheet as alternatives.

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

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

With no annotations, the description carries the full disclosure burden and does well: it explains extension-driven format selection, that layer export is cropped to content unless full_canvas, and that quality applies only to jpg/webp. It omits whether the export is non-destructive to the document, whether it overwrites existing files, and what the call 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?

Four compact sentences in a front-loaded "param = meaning" format with zero filler; the core export statement comes first, then parameter modifiers. Nothing can be cut without losing 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 an 8-parameter export tool with no annotations and no output schema, the description covers the call semantics well enough to invoke it correctly. Minor gaps remain around path resolution (relative vs absolute, workspace root behavior) and whether a return value/path is produced.

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 8 parameters, and it does: path/format via extension, layer, full_canvas, quality range, and the x/y/width/height region quad with a practical example. Each optional parameter's effect on the output is explained in a way the bare schema titles ("X", "Y", "Width") never could.

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 (export) and resource (flattened image), lists the supported formats, and scopes the output to the workspace with format inferred from the file extension. The word "flattened" distinguishes it from sibling exports like export_selection_mask and export_animation_frames.

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

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

Gives concrete usage contexts through the parameter notes: layer export for per-layer output, region export "for the area to send to an inpainting model". It does not explicitly steer the agent away from sibling tools (export_selection_mask, canvas_snapshot), so routing requires some inference.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It does reveal the output format and the white=selected polarity, which is genuinely useful, but says nothing about what happens with an empty/absent selection, whether the target file is overwritten, or what the call returns — all material for a write-to-disk tool.

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

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

A single front-loaded sentence that identifies the saved artifact and its pixel convention with no filler. It is appropriately sized, though the brevity comes partly at the cost of the missing parameter and behavior detail noted above.

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 side-effect tool with no annotations and no output schema, the description covers the core purpose and output encoding but leaves the path contract, the invert flag, and failure/overwrite behavior undocumented — enough to attempt a call, not enough to call 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?

Schema description coverage is 0% across two parameters, so the description must compensate and largely does not: 'path' is never identified as an output file path (versus a directory, with or without extension), and 'invert' is never explained, only indirectly hinted at by the 'white = selected' convention.

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 ('Save the current selection as a greyscale PNG mask') plus the encoding convention (white = selected), which clearly separates it from the generic export_image sibling. It stops short of naming export_image or set_selection explicitly, so the differentiation is implied 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?

The trailing phrase 'for inpainting models' implies the intended downstream use, but there is no explicit statement of when to pick this over export_image or whether a selection must first be created via set_selection. Usage is inferable but not spelled out.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool only affects paint layers and that omitting the colour destroys the selected pixels (an erase), which is valuable context. However, it does not say what happens when no selection exists, whether the operation is undoable, or what the response contains.

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

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

A single well-structured sentence with the primary action front-loaded and the erase case attached after a semicolon. No filler or redundant restatement of the tool name.

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

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

For a two-parameter destructive-ish paint operation with no annotations and no output schema, the description covers the main action and the erase mode but leaves the layer target and no-selection edge case unexplained. Adequate but with 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% – both parameters have only titles and null defaults. The description meaningfully explains that an omitted/null colour means erase, covering the most important ambiguity of 'color'. But the 'layer' parameter is never addressed: whether it takes a name, id, or index, nor what the active layer fallback is.

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: fill the current selection on a paint layer with a colour. An agent can distinguish it from brush_stroke or draw_shapes because it operates on an existing selection rather than drawing new geometry. It does not explicitly name a sibling alternative, 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?

The 'omit colour to erase' clause is genuine usage guidance for one mode of the tool, but there is no statement of when to prefer this over related tools (set_selection, modify_selection, brush_stroke) or any prerequisite such as an active selection being required.

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 and no output schema, the description usefully discloses the response structure and ordering ('connected regions... largest first, plus total coverage'), which the agent would otherwise have to guess. It stops short of behavioural detail: nothing about how tolerance affects region merging, what limit truncates, or whether omitted x/y/width/height default to the whole canvas.

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 with the core question front-loaded and the return shape immediately following. The fragment-style opening is slightly cryptic but costs no words that could be spent on parameters.

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

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

For an 8-parameter tool with zero schema coverage, no annotations, and no output schema, the definition is under-specified: the search scope parameters (x/y/width/height/layer) and tolerance semantics are the main risk of a mis-call and are unaddressed. Only the return value side is adequately covered.

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. The description only implicitly covers 'color' and hints at ordering (relevant to 'limit'); x, y, width, height, layer, and tolerance — the parameters that determine search scope and matching strictness — carry no explanation anywhere. This is a substantial gap the description should compensate for but does not.

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

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

The description states a specific operation (finding where a colour occurs) and enumerates the return shape (bbox, share, centroid, largest first, total coverage). It is clearly distinguishable from sample_color or match_colors by describing regions rather than pixel or palette operations, though it never names 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?

One implicit usage cue is given: 'Good for locating objects before editing them.' There is no statement of when not to use it, no mention of alternatives such as sample_color or analyze_image, and no prerequisites or ordering advice.

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 disclosure burden and does meaningful work: it describes the cost profile ("Cheap") and the return shape ("names and one-line descriptions only"), which tells the agent this is a lightweight discovery call, not a content fetch. It does not mention permissions, failure modes, or result ordering, so it is not fully complete.

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

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

Three short sentences, front-loaded with what a skill is, then the call pattern, then the cost/return note. Every sentence adds information an agent needs to choose and invoke the tool correctly; 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 two-parameter discovery tool with no output schema, the description covers the essentials: the entity being searched, the search style, the follow-up tool, and the shape of results. The only omission is any hint about how limit affects behavior or how results are ranked.

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 the query parameter's intent well ("a few words about the task"), replacing the vague schema default of an empty string. However, the limit parameter and its default of 8 are never explained, leaving a real 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?

States a specific verb and resource ("Find skills") and immediately defines what a skill is: "step-by-step know-how for kinds of Krita work," with example domains. It is clearly distinguished from the sibling use_skill, which it frames as the follow-up action rather than a competitor.

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 concrete when-to-use guidance ("Search with a few words about the task") and explicitly routes to the alternative ("load the one that fits with use_skill"), establishing a clear two-step workflow. It lacks any when-not-to-use guidance, such as skipping the search when the skill name is already known.

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 supplied, so the description carries the full behavioral burden, yet it omits that flattening is destructive and discards layer structure. It also does not say whether hidden, locked, or non-visible layers are included, or whether the operation requires an active document.

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 six-word sentence that front-loads the action and names the scope; nothing is redundant and nothing pads the definition.

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

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

For a destructive, no-argument canvas operation with no annotations and no output schema, the description should at minimum warn that the change collapses all layers irreversibly and note undo availability. It conveys the action but none of the risk context an agent needs before invoking it.

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

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

The tool takes zero parameters and the schema is empty, so there is no parameter meaning for the description to add. Baseline 4 applies for a no-argument tool.

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

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

"Merge all layers into one" states a specific verb (merge) and resource (all layers) plus the resulting state, so an agent knows exactly what the operation does. It does not, however, distinguish itself from the close sibling merge_down, which a caller must resolve by name inference alone.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no mention of the obvious alternative merge_down for collapsing a single layer. Usage is only inferable from the action itself, leaving the agent to guess which merge tool matches its intent.

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 supplied, so the description carries the full behavioral burden. It never states whether the flip is applied in place, whether it is undoable, whether it affects the active selection or canvas dimensions, or what the caller receives back; for a mutating image operation this leaves significant gaps.

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 operation and its scope split, then the direction options. Every clause carries useful information and nothing is padded.

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 zero required parameters, no annotations, and no output schema, the description covers the happy path of target and direction but omits what happens on success, how the layer argument is resolved, and what defaults do when arguments are omitted.

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

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

Schema description coverage is 0% and no parameter has an enum, so the description legitimately adds value by enumerating target=image/layer and direction=horizontal/vertical. However, the `layer` parameter is never explained: it is unclear how a layer is identified (name vs id) or that it only applies when target=layer.

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?

"Mirror the whole image (target=image) or one layer (target=layer)" names a specific verb (mirror/flip) and resource, and immediately splits the operation by scope. An agent can distinguish it from rotate_image or crop_image without opening any schema, though no sibling is named 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?

Usage is implied by the operation itself: call this when a mirror is wanted on the image or a single layer. There is no explicit when-not guidance and no pointer to alternatives such as rotate_image or transform_layer for other transforms.

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 supplied, so the description carries the full disclosure burden. It does disclose valuable operational limits (max 1000 frames, 20 operations) and the default frame range (playback range), which no structured field provides. It says nothing about cost, latency, undo behaviour, or whether the original frames are replaced or a new result is produced.

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 core action, followed by the example payload and the limits. The example is long but earns its space by resolving the undocumented 'operations' format. Nothing reads as 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 4-parameter, no-annotation, no-output-schema tool, the description covers the essentials: what gets operated on, the operations payload format, the default range, and the hard caps. The remaining gap is behavioural (what happens to source frames, cost of a 1000-frame run), which is a real but secondary 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?

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: it specifies the exact shape of each element in 'operations' ({tool, args}) with a concrete worked example, and explains that start/end default to the playback range. That is meaning an agent cannot derive from an array-of-objects schema. Only 'step' is left to the default value.

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 the same tool calls to every frame of an animation or imported video. The example (colour-grading a clip) pins down the kind of work it is for. It does not explicitly distinguish itself from the sibling 'batch' tool, which is the one nearby capability an agent might confuse it with.

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

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

Usage is conveyed by example ('colour-grade a clip') rather than by an explicit when-to-use rule, and there is no statement of when not to use it. With 'batch' among the siblings, the absence of any routing guidance between the two leaves a real decision to inference.

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

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

There are no annotations, so the description carries the full burden, and it discloses substantial behavior: results are new layers in one undo step, generation is clipped to the selection so nothing outside it changes, count>1 produces a group plus a numbered comparison sheet, and backend resolution falls back to KRITA_MCP_IMAGE_BACKEND or the first available backend. Control-guide handling is explicitly differentiated per provider (real ControlNet on comfyui/a1111, sketch/structure on stability, image-to-follow on openai/gemini). It still omits failure modes, credential/API-key requirements, and speed or cost characteristics of the remote backends.

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 text is a single dense block, but it is telegraphic rather than padded — nearly every clause conveys a distinct fact (a default, a range, a fallback rule, a provider caveat). The purpose leads the paragraph and the mode rules come next, so the most decision-relevant content is front-loaded, though the wall-of-text layout makes scanning harder than it needs to be for a tool this complex.

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 24-parameter tool with no annotations, no output schema, and zero schema descriptions, the definition is unusually complete: it explains mode routing, region geometry, variation grouping, backend fallbacks, workflow templating, and control-guide semantics. The remaining shortfall is the undocumented sampling knobs (cfg, steps, sampler, scheduler, seed) and the name parameter, which an agent must 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 description coverage is 0% across 24 parameters, so the description must compensate and largely does: mode, region/x/y/width/height, padding, count, backend, model (with per-provider id formats), size, strength, workflow (file path plus the placeholder list), extra, control (object keys, types, defaults, start/end), and style presets are all explained. Gaps remain for cfg, steps, sampler, scheduler, seed, and name, which are never mentioned, though several are conventional diffusion settings an agent can infer.

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 states a concrete verb and object — generate pixels with an image model and place them as NEW layers — and adds the side-effect detail (one undo step). It is clearly distinguishable from sibling tools such as upscale_image, outpaint, create_artwork, and generate_video.

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 mode enumeration gives real decision guidance: auto picks inpaint when a selection exists and otherwise txt2img; img2img 'rework the region' with strength controlling how much changes; inpaint regenerates only selected pixels with soft-edge blending. The count section even routes the agent to pick_variation for choosing a result. However, it never says when to prefer this tool over its close siblings (outpaint for extending the canvas, upscale_image, create_artwork), so the alternative-selection rule is incomplete.

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 disclose meaningful behavior: the result is saved to the workspace, optionally imported into Krita as an animation layer stack, and 'Generation can take several minutes' warns about long latency. It does not say what is returned (path? document handle?), what happens on backend failure, or whether partial artifacts are left behind.

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

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

Front-loads the core action and side effects in the first sentence, then uses compact labeled fragments for backend, camera and style. The parenthetical asides and trailing '(No video model? ...)' note make it denser than ideal, but nearly every clause carries distinct 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 an 18-parameter generative tool with no annotations and no output schema, the description covers the workflow and backend routing well but omits return values, resolution/duration parameter behavior (width, height, seconds, max_frames) and the meaning of path/extra. An agent could call it with defaults but would be guessing on several knobs.

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 18 parameters, so the description must compensate, and it does for the high-ambiguity ones: backend, use_canvas, camera (full enumerated list of moves), style, character, model. However path, extra, width, height, seconds, max_frames and negative_prompt are never explained, leaving roughly half the surface 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 resource ('Make a video with a video model') plus the full lifecycle: saved in the workspace and by default opened in Krita as an animation. It also differentiates itself from siblings by naming camera_move as the local no-model alternative and by referencing generate_image semantics for style.

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 concrete selection rules: use_canvas=true means image-to-video for most backends and background-behind-avatar for HeyGen, and per-backend requirements (heygen needs script + avatar_id + voice_id; replicate/fal need a model id). The fallback 'No video model? camera_move animates the picture locally' names an alternative with its condition, but there is no explicit statement of when not to use this tool (e.g. cost/quality tradeoffs vs. render_video or import_video).

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. It usefully states that results combine user undoable edits and Krita's undo stack and that done=false means undone, but it does not state read-only behavior, ordering, pagination, or side effects.

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

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

The definition is a single compact sentence with the key content front-loaded. It wastes no words, though the noun-phrase phrasing makes the action less explicit than it could be.

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

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

There is no output schema and no annotations, while the description explains only what the history contains. It omits return structure, limit behavior, ordering, and the relationship to undo/redo, leaving meaningful gaps for an agent that must call it correctly.

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

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

Schema description coverage is 0%, and the only parameter, limit, is not mentioned in the description. Its name and default value make it somewhat intuitive, but no behavioral semantics are added.

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 undoable edits plus Krita's own undo stack, so an agent can infer it retrieves history. However, it gives no verb such as list or get and does not explicitly distinguish the tool from sibling undo/redo operations.

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 undo or redo, nor any stated prerequisites. The content implies inspection rather than mutation, but the agent must infer that.

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

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

With no annotations, the description carries the full burden and does well: it discloses that textures tile by default, that hdris/photos cover the canvas, the allowed fit and texture_map values, and that the return includes the layer plus photo attribution. It omits permission requirements and what happens to existing layers or how parent/opacity interact with the new layer.

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

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

The core action is front-loaded in the first sentence, and the parenthetical enumerations of fit and texture_map values are compact. The workflow sentence is slightly dense but every clause adds usable 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 10-parameter tool with no annotations and no output schema, the description covers the asset-type-dependent behavior and return value but leaves several parameters (parent, opacity, resolution, name) undocumented. It is adequate but not complete for the tool's 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?

Schema description coverage is 0% across 10 parameters, so the description must compensate. It explains tile_size, texture_map, and fit well, and implies kind via the textures/hdris/photos distinction, but leaves id, name, parent, opacity, blend_mode, and resolution entirely unexplained.

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

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

The first sentence states a specific verb and resource ('Put a search_assets result on a new layer'), which both names the operation and ties it to the sibling that produces its input. An agent can distinguish it from import_image or import_image_from_url without opening the schema.

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

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

It clearly routes the agent from search_assets into this tool and gives a concrete follow-up workflow (import, then update_layer with clipped=true and overlay/multiply above the shape). It does not explicitly contrast with import_image or import_image_from_url, so the alternative-selection guidance is incomplete.

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

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

With no annotations at all, the description carries the full burden, and it does disclose the key behavioral facts: a mutation that creates a NEW layer (non-destructive to existing content) and that file order maps to frame order. It says nothing about frame-size compatibility, failure handling for missing paths, what happens if the document lacks an animation timeline, or what is returned.

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 no filler; every clause carries information. It is efficient, though the terseness trades away detail that this 3-parameter tool 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?

For a mutation tool with no annotations, no output schema, and zero parameter documentation, the description is too thin. An agent cannot determine what 'step' and 'first_frame' do or what constraints apply to the imported images, so it would have to guess on a call that creates document content.

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 all three parameters are undocumented in structured data. The description only implicitly touches 'paths' via '(in order)'; 'step' (presumably a frame sampling interval) and 'first_frame' (presumably a starting frame offset) are never explained, leaving their meaning to guesswork.

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

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

The description gives a specific verb ('Load') and resource ('image files from the workspace') plus the resulting artifact ('frames of a new animated layer'), which clearly separates it from siblings like import_image or import_video. It stops short of explicitly naming those alternatives, but the animated-layer outcome makes the intent 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?

Usage is only implied: an agent can infer this is for building animation from an ordered image sequence, and '(in order)' hints the paths list is sequenced. There is no explicit when-to-use guidance, no prerequisite (e.g., an open document), and no mention of when to prefer import_video or batch instead.

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

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

With no annotations, the description carries the burden and does well: it discloses that a NEW paint layer is created (a document mutation), that the path must be inside the workspace, and which byte formats are accepted. It omits what happens if neither source is supplied or both are, and does not mention undo/reversibility.

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

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

Front-loaded with the core action, then input sources, then fit modes; the parentheticals ('soft edges included - for inpainting') add real selection guidance rather than filler. Slightly dense in the fit enumeration but nothing 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?

For a 9-parameter, zero-annotation, mutation tool with no output schema, four parameters (name, width, height, parent) go entirely undocumented and error behavior for missing sources is unstated. The image-import path itself is well covered, so it is adequate but with 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% across 9 parameters, so the description must compensate and only partially does. It fully documents fit (all five modes with semantics) and the path/image_base64 exclusivity, and implies x/y meaning through the 'none' mode, but name, width, height, and parent are never explained.

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

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

States a specific verb and resource ('Put a raster image on a NEW paint layer') plus a constraint that separates it from siblings: 'raster' distinguishes it from add_svg, and 'path OR image_base64' distinguishes it from import_image_from_url. An agent can identify the right tool without opening the schema.

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

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

The closing sentence gives a clear when-to-use context ('how images from an image-generation model get into Krita for further editing'), and the fit-mode list implies the inpainting use case via the 'selection' mode. No explicit when-not or named alternative, but the input-source rule (path OR base64) is a usable routing cue.

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 load and does it well: it discloses network constraints (no redirects, 25 MB cap, private-address blocking) and the side effect of creating a new layer. It does not say what happens on failure, timeout, or unsupported content types, and doesn't state that this is a network operation with latency.

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 with the source-type constraint front-loaded and limits in a compact parenthetical. 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 7-parameter, zero-coverage, no-annotation, no-output-schema tool, the description covers the risky part (fetching from a URL) thoroughly but delegates six placement/name parameters to a sibling reference. Adequate but not self-contained.

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 clarifies 'url' semantics well, and 'Same placement options as import_image' gives indirect meaning to x/y/fit/width/height, but that requires consulting another tool, and 'name' (default 'Imported image') is never addressed.

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 ('Download a PUBLIC http(s) image URL and place it on a new layer') and implicitly separates itself from the file-based sibling via 'Same placement options as import_image.' An agent can tell this is the remote-source variant without opening either schema.

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

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

'PUBLIC http(s)' and 'private addresses blocked' effectively exclude internal/local targets and point to import_image for local files. However, the routing to import_image is only implied by the placement-options reference rather than stated as 'use import_image for local files.'

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

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

With no annotations at all, the description carries the full burden and does substantial work: it discloses the side effect of creating a new document, the frame cap (max 1000), fps resampling, and aspect-preserving width scaling. It stops short of stating what happens past the frame cap, whether an error is returned, or what the result looks like, which are meaningful gaps for a resource-heavy import.

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

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

Three tight sentences, front-loaded with the core action and formats, then the document-creation rule, then a compact parameter clause. No filler, and the most decision-relevant fact (new document vs into_current) lands early.

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

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

For an 8-parameter tool with no annotations and no output schema, the description covers side effects, limits and most parameter meanings well enough to call it correctly. It leaves the return value and failure behavior unspecified, and the 'name' parameter ambiguous, which keeps it just short of complete.

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

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

Schema description coverage is 0% with 8 parameters, so the description must compensate, and it does for most: start/duration units (seconds), fps resampling effect, width scaling with aspect preserved, into_current's document behavior, and max_frames (with a 1000 cap vs the 240 default). 'path' and 'name' are left unexplained — notably whether 'name' labels the document or the resulting layer.

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 ('Decode a video ... into an animated layer') plus the supported formats, and the phrase 'so every frame can be painted, filtered or adjusted' distinguishes it from import_frames, import_image and video_info without opening any schema.

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

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

It clearly frames the use case (bring a workspace video in as an editable frame layer) and gives the key decision rule: 'Opens a new document sized to the video unless into_current'. It never explicitly names alternatives such as video_info for inspection or import_frames for image sequences, so the routing is implied rather than spelled out.

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

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

No annotations are provided, so the description carries the full burden. It does useful work here by disclosing the downstream side effects of the mutating kinds (remove_and_pull and hold shift later frames), and by stating 'The layer becomes animated'. It omits other behavioral facts an agent needs: whether the operation is undoable, whether layer must be a currently active paint layer, what happens when frame is out of range, and what is returned.

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 operation list and ending with the practical consequence. The parenthetical glosses are dense but every one earns its place by defining a value the schema leaves untyped. Minor cost: the kind enumeration is a long comma run that could be easier to scan as a 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 three-parameter mutation tool with no annotations and no output schema, the definition covers the operation kinds and the frame target but leaves the layer parameter, the return value, and undo/permission behavior undescribed. Adequate to attempt a call, but an agent would have to experiment to learn what layer=null does.

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, and it does so well for kind — a bare string with no enum in the schema, whose six legal values are only defined in the description. It also clarifies frame as the target position. However, the layer parameter (nullable, default null) is never mentioned, so its meaning is left entirely to guesswork.

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 a specific resource (a paint layer) and a specific frame target, and enumerates the six operations the tool can perform, so an agent knows exactly what it does. It does not, however, disambiguate itself from close siblings such as list_keyframes, export_animation_frames, or animation_set, so the boundary 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 through the parenthetical glosses on each kind (e.g. 'duplicate (copy of the previous drawing)', 'remove_and_pull (shift later frames back)'). There is no explicit when-to-use versus when-not-to-use guidance, and no sibling (animation_set, list_keyframes) is named as an alternative for related tasks. The trailing sentence 'draw on it while at that frame' is the only real workflow hint.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the execution model (native Krita command, no dialogs, acts on the active document/layer), but it does not flag that several listed commands are destructive or irreversible in effect (flatten_layer, clear_selection_pixels, trim_to_image, cut_selection_to_new_layer), nor does it mention error behavior for unknown names or whether operations land in undo history.

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 one-sentence preamble is front-loaded and the enumeration is grouped into labeled categories, so scanning is easy. Length is justified because it is the only source of the allowed command values, though the compressed alternative-syntax notation adds avoidable parsing burden.

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 command dispatcher with no output schema and no annotations, the description covers the input value domain well but leaves the agent guessing on several practical points: the meaning of the optional layer argument, return content, and failure modes. It is adequate but not sufficient to invoke confidently in edge cases.

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 'name' field has no enum, so the description is doing real work by supplying the entire allowed value domain, grouped by category. It falls short on the 'layer' parameter, which is never explained (whether it overrides the active layer and what 'null' means), and the pipe/underscore notation such as 'select_opaque(_add|_subtract|_intersect)' and 'rotate_layer_90_cw|90_ccw|180' must be decoded by the agent rather than listed as literal values.

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: 'Run one of Krita's own commands on the active document/layer (curated, no dialogs)', and then enumerates the exact command set by category. It never distinguishes this from overlapping siblings such as rotate_image, flip, flatten_image, view_control, fill_selection or set_selection, so an agent cannot tell which surface is authoritative for a given operation.

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

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

There is no explicit when-to-use or when-not-to-use guidance. The word 'curated' hints that only a subset of Krita commands is exposed, but nothing tells the agent whether to prefer this tool or the dedicated sibling (for example rotate_image, flip, or view_control) for the same effect, or what to do when a command is not in the list.

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

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

With no annotations, the description carries the full burden, and it does disclose the returned content (version, workspace folder, per-document index/size/active). However, it never states that the call is read-only and side-effect free, and since no output schema exists, the return structure is only loosely implied by a parenthetical.

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 short sentence with no filler, and the three main return elements are front-loaded. The parenthetical field list is terse but readable.

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 status tool the description is mostly sufficient, listing the three categories of data returned. Because there is no output schema, it should specify more about the document entry structure (e.g. what 'size' represents, or the shape of the list) to fully compensate.

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 schema to document and the baseline of 4 applies. The description instead spends its words on return content, which is appropriate for a parameterless status call.

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

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

The description names a specific resource set — Krita version, sandboxed workspace folder, and open documents with index/size/active — so an agent knows exactly what it returns. It does not explicitly differentiate itself from overlapping siblings like document_info or list_workspace, which keeps it from 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?

There is no guidance on when to call this versus document_info or list_workspace, both of which appear to cover overlapping information. The agent must infer that this is a lightweight environment/status probe rather than a detailed document query.

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 supplied, so the description carries the full behavioral burden. Beyond implying a read, it says nothing about result ordering, whether all presets are returned or a truncated subset, or how the default limit of 200 affects output — meaningful gaps for a listing 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 resource stated first and the optional filter behavior nested in parentheses. Nothing is wasted, though the parenthetical could be split into a clearer second sentence.

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

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

With no annotations and no output schema, the description should still cover truncation behavior and what the returned names are for. It handles the core purpose and filter semantics adequately but leaves the agent guessing about result size and downstream use.

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

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

Schema coverage is 0%, so the description must compensate. It does well for `filter` by explaining substring containment and giving concrete examples ('ink', 'pencil', 'airbrush'), but it says nothing about `limit` or the default truncation at 200, leaving one of two parameters undocumented everywhere.

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 exact resource (Krita's brush presets) and states that names are returned, which separates it from siblings like list_filters, list_resources, and pick_variation. It reads as a noun phrase rather than an explicit verb, but the intent (enumerate preset names) is unmistakable.

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 alternatives such as list_resources or pick_variation, and no prerequisites or exclusions are given. The only usage hint is that the `filter` argument matches substrings, which is parameter guidance rather than tool-selection 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 provided, the description carries the full disclosure burden. It does disclose the essential behavioral fact — the result is names only, not filter parameters or presets — but it says nothing about whether a document must be open, ordering, or whether the call is a pure read.

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 short sentence with zero padding, and the key scoping cue ("usable with apply_filter") lands immediately. It is a sentence fragment without an explicit verb, which is a minor structural weakness but costs no clarity.

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-argument enumeration tool with no output schema, the description supplies exactly what an agent needs: what is listed and what the list is for. There is no meaningful complexity left unexplained.

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 and the schema is an empty object, so there is nothing for the description to disambiguate. 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?

The description names a specific resource ("Names of all Krita filters") and ties its scope to a named sibling ("usable with apply_filter"), so an agent can distinguish it from describe_filter and apply_filter. It is a noun phrase rather than a verb+resource statement, which keeps it just 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?

Usage is only implied: the phrase "usable with apply_filter" signals this is a discovery step that feeds filter application. It never states when not to use it, nor does it point at describe_filter, the sibling an agent actually needs once it has a name in hand.

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 supplied, so the description carries the full burden and discloses almost nothing. It does not say whether the result is sorted, whether it covers the whole timeline when start/end are null, whether omitting the layer returns all layers, or what happens for a layer with no keyframes.

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

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

It is a single short, front-loaded phrase with no wasted words, but the brevity reflects under-specification rather than discipline. Structurally it is not even a complete sentence, and no key information is prioritized because none is provided.

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 listing tool with three optional parameters and no output schema, an agent mainly needs to know the scope semantics of the nullable parameters. The description leaves those unspecified, which is a real gap, though the low complexity of the operation keeps the omission from being severe.

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 all three parameters (layer, start, end) are optional with null defaults. The description only hints at the 'layer' parameter and adds nothing about the meaning or default behavior of start and end, so it fails to compensate for the schema 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 text is a noun fragment ('Frames at which a layer has keyframes') that essentially restates the tool name list_keyframes. It never states a verb such as 'list' or 'return', and it does not distinguish the tool from siblings like 'keyframe' or 'animation_info', which plausibly overlap in the same animation domain.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives such as animation_info (for general timeline data) or keyframe (for setting keyframes). The only guidance is an implied 'use this to see keyframes on a layer', which an agent could infer from the name alone.

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

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

With no annotations, the description carries the full burden. It discloses a genuinely useful behavioral detail — children are ordered bottom-to-top — and that the active layer id is included, but it says nothing about ordering of top-level layers, failure behavior with no open document, or whether the tree is flat or nested.

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 that front-loads the primary return value and appends the secondary one in parentheses. No filler words.

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

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

For a zero-parameter read tool with no output schema, the description should more fully characterize the returned structure (names vs ids, nesting shape, node count), which it only partially does. It is adequate but leaves an agent guessing about how to parse the result.

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