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

There are no annotations, so the description carries the full burden. It does disclose one useful trait, that undo history is preserved, but says nothing about whether a live session is required, what happens if the job_id is stale, or whether the underlying artwork is mutated.

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. It is efficient, though its brevity is achieved largely by omitting necessary detail rather than by tight editing.

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

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

An output schema exists, so return values need not be explained, but for an unannotated mutation tool with two fully undocumented required parameters the description is too thin. Nothing tells the agent what a valid job_id looks like or how this interacts with the surrounding job/session tools.

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

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

Schema description coverage is 0%, so both parameters (job_id, prompt) are undocumented anywhere. The description's phrases "existing session" and "art direction" only loosely gesture at them and add no format, source, or constraint 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 verb+resource ("apply a follow-up art direction to the existing session") is parseable, but "follow-up art direction" is vague and it never distinguishes itself from close siblings like artwork_make_it_cooler or artwork_job_create. An agent cannot confidently tell when this applies a new direction versus creating a fresh job.

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 when-to-use, when-not-to-use, or alternative routing is given. With siblings such as artwork_job_create, artwork_make_it_cooler, and session_undo in the same family, the description leaves the agent to guess which one fits.

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

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

The description discloses a meaningful behavioral trait: cancellation is cooperative and deferred to the next safe step boundary rather than abrupt. With no annotations, however, it does not cover permissions, reversibility, side effects on output, or whether cancellation is idempotent – important context for a state-changing job 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?

One sentence, front-loaded with the verb and resource, with no filler. It is appropriately sized for the action and every word earns its place.

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

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

An output schema exists, so return values need not be explained. But with no annotations, a mutation tool, and an undocumented parameter, the definition should do more to explain prerequisites, effects on a running job, and result handling.

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

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

The single job_id parameter has 0% schema description coverage and the description does not explain its expected format or source. The parameter name is self-evident, but the description adds no semantic detail beyond the schema and does not compensate for the coverage 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, 'cancel', and resource, 'artwork job', and the 'next safe step boundary' scope hints at a distinction from an immediate kill. It does not name sibling tools such as artwork_job_pause or artwork_job_resume as alternatives, so differentiation is only partial.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The safe-boundary phrasing implies cancellation is not immediate, but it does not tell the agent when cancel is preferable to pause/resume or how to handle an already finished job.

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 useful traits: the job is persisted (state-creating side effect) and it does not execute anything yet (no immediate work). However it says nothing about permissions, provider/model requirements, whether persisted jobs must later be run/cancelled, or error 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?

A single tight sentence with the verb front-loaded and no filler. The one weakness is that its brevity comes partly from omitting needed detail rather than from disciplined editing.

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

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

The output schema relieves the description of explaining returns, but with 5 params at 0% schema coverage and no annotations, the definition is too thin for a state-persisting creation tool. It omits parameter meaning and the lifecycle context (that persisted jobs are later run/paused/cancelled).

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 should compensate and does not. It never mentions prompt, mode, model, provider, or session_id, nor how the provider/model defaults interact with the AI generation step.

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 has a specific verb (create/persist), a specific resource (AI-to-GIMP artwork job), and the qualifier 'without running it yet' which meaningfully separates it from artwork_job_run. It is clear and differentiated, though it doesn't fully flesh out what an 'artwork job' entails.

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?

'Without running it yet' implies the workflow relationship with artwork_job_run, but the description never states explicitly when to prefer this over artwork_job_run or the other artwork_job_* siblings (run/pause/resume/cancel). Usage is inferred rather than 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 provided, so the description carries the full burden. It discloses sort order ('newest active jobs first') and that jobs are persisted, but says nothing about filtering behavior, pagination/limits, how long jobs persist, or whether inactive jobs are included.

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

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

A single front-loaded sentence with zero filler. The ordering behavior is conveyed compactly without redundant phrasing.

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

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

An output schema exists, so return values need not be explained, and there are no parameters to document. Minimum viable, but for a tool sitting in a dense cluster of artwork_job_* siblings, the description should at least signal how it relates to artwork_job_status.

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 the schema-baseline of 4 applies. There are no parameter semantics for the description to clarify, and the schema coverage is 100%.

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 ('List persisted artwork jobs'), and the ordering clause clarifies scope beyond a bare restatement of the name. However, it does not differentiate itself from the closely named sibling artwork_job_status, which an agent could easily conflate with this 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?

There is no when-to-use guidance and no mention of alternatives such as artwork_job_status (single job) versus this list tool. The only contextual hint is the ordering clause, which is not usage guidance.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the pause is cooperative and occurs at the next safe step boundary, which is meaningful context beyond the schema. However, it omits permissions, reversibility, failure modes, and the effect on job status, so the disclosure is partial.

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

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

The description is a single, front-loaded sentence with zero wasted words. It states the action, the resource, and the key behavioral constraint in one efficient clause.

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

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

An output schema exists, so return values need not be explained. However, for a pause operation that sits alongside cancel and resume siblings, the description does not provide enough contextual routing guidance or parameter meaning to be fully complete. It adequately describes the mechanism but leaves selection and invocation details to inference.

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

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

There is one required parameter (job_id) with 0% schema description coverage. The description does not mention the parameter at all, so it fails to compensate for the schema's lack of parameter documentation. While 'job_id' is fairly self-explanatory, the description adds no semantic meaning beyond the name.

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 (pause) and resource (artwork job), and further specifies the cooperative, safe-step-boundary nature of the pause. This clearly distinguishes it from sibling operations like artwork_job_cancel or artwork_job_resume without needing to open 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?

Usage is implied: pause an artwork job. However, the description does not explicitly say when to use this tool versus alternatives such as artwork_job_cancel or artwork_job_resume, nor does it state prerequisites like the job must be running. No explicit when/when-not guidance is provided.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses that this only clears a flagged state and does NOT itself resume execution, which prevents a misuse. However, it omits permissions, idempotency, and behavior when the job is not paused or 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?

Two short sentences, zero waste, with the core action front-loaded and the follow-up chained immediately after. Sized exactly to the tool's simplicity.

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

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

An output schema exists, so return values need not be explained. For a one-parameter state-clearing tool, the description covers the action and the required follow-up call; only the precondition and error behavior are unstated.

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

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

Schema description coverage is 0% for the single required job_id parameter, and the description says nothing about the identifier's format or source (e.g., from artwork_job_list or artwork_job_create). The meaning is largely inferable from the name, but the description does not compensate for the coverage 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: 'Clear the pause flag for an artwork job.' This cleanly distinguishes it from siblings artwork_job_pause (sets the flag) and artwork_job_run (executes), so an agent can route 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?

Gives a clear next-step instruction ('Call artwork_job_run to continue execution'), which defines the tool's place in the workflow and names the alternative action. It does not explicitly state the precondition (the job must currently be paused) or what happens if it is not, so it falls short of full when/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?

No annotations are provided, so the description carries the full burden. It does not disclose whether execution is blocking or asynchronous, how long an AI-driven job may run, whether it mutates documents irreversibly, or whether it consumes provider credits — all material for an execution 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 with no filler, stating the action first and the execution mechanism second. Nothing wasted, though it is arguably too terse given the missing behavioral detail.

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

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

An output schema exists so return values need not be described, but for an execution tool with no annotations the definition omits prerequisites, async/blocking behavior, and failure conditions — the agent cannot call it confidently without opening sibling tools.

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

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

Schema description coverage is 0%, so the description must compensate and does not: job_id is never mentioned or characterized (format, source, whether it must reference a paused job). The name is largely self-evident from sibling tools, which keeps this above a 1.

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+resource ('Run a queued/paused artwork job') plus the execution channel (AI provider and semantic GIMP tools). It is reasonably distinguishable from artwork_job_create/status/pause/resume/cancel siblings, though it does not explicitly name them.

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

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

The qualifier 'queued/paused' implies the precondition that the job must already exist in one of those states, but the description never says when to choose this over artwork_job_create, resume, or followup, nor what happens if the job is in another state.

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 add that the state is persistent and includes progress, which hints at retrieval from durable storage rather than a live session. However, it does not state whether the operation is read-only, whether it blocks, what permissions are needed, or how fresh the state is.

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

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

The description is a single, front-loaded sentence with no filler. It is appropriately sized and immediately communicates the tool's core action. No sentence 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?

An output schema exists, so return values need not be explained, but the input parameter has no documentation and the description provides no usage guidance. With no annotations and many sibling job-lifecycle tools, the definition is too thin to fully guide correct invocation. It omits basic context such as whether the job_id is required and how status relates to other job operations.

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 required parameter job_id is not mentioned in the description. The description does not clarify the expected identifier format, where it comes from, or any constraints. Because the schema provides no parameter documentation, the description should compensate but does not.

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

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

The description clearly states a specific verb and resource: it returns the state and progress of an artwork job. This distinguishes it from lifecycle siblings like artwork_job_create, run, pause, or cancel. However, it does not explicitly differentiate itself from artwork_job_list or artwork_followup, which also relate to job tracking.

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 tool versus alternatives such as artwork_job_list or artwork_followup. The only implied usage is querying a job's status, but no conditions, prerequisites, or exclusions are provided. With many related sibling tools, this omission leaves the agent to infer usage.

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 mentions 'safe semantic GIMP actions', suggesting non-destructive or guarded execution, but does not state required permissions, reversibility, side effects, or what happens to the existing artwork. This is insufficient for a mutation-style tool.

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

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

The description is a single, front-loaded sentence with no filler. It is efficiently sized, though it could be slightly more structured by specifying the model selection and GIMP action scope.

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

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

For a tool that orchestrates AI-driven improvements, likely with side effects, the description is thin. It omits parameter meaning, prerequisites, and execution flow. Although an output schema exists, the description still leaves critical context about model selection and safe action boundaries unaddressed.

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

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

Schema description coverage is 0%, and the description does not mention either parameter (job_id, preset). It does not explain what a job_id refers to, what preset defaults or alternatives exist, or how the model is selected. It fails to compensate for the complete lack of schema documentation.

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

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

The description states a clear two-step purpose: ask the selected model for improvements, then execute them through GIMP actions. It conveys the tool is an AI-assisted enhancement operation, but it does not differentiate itself from the many other GIMP/artwork siblings (e.g., artwork_job_run, filter_apply) that could also modify artwork.

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

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

There is no explicit guidance on when to use this tool versus alternatives like artwork_job_run, followup, or manual filter operations. The only implied context is that it is for making artwork 'cooler', but no when/not conditions or prerequisites 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a destructive mutation of the document canvas but does not say whether the crop is undoable, whether it affects only the current layer or the whole document, or what permissions/session state are required. Only the minimum (what the operation does) 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?

A single well-formed sentence with the core action front-loaded and the optional modifier trailing. No wasted words, though it is arguably too terse for a mutation tool.

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

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

The output schema exists so return values need not be described, and the core action is conveyed. However, for a document-mutating tool with zero annotations and zero schema descriptions, the definition omits session_id semantics and any reversibility or scope information, leaving noticeable gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does add real meaning for layer_id by explaining it acts as the 'reference drawable' for the autocrop bounds, but session_id is left entirely unexplained (presumably the target document session). Partial compensation for a two-parameter tool.

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

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

States a specific verb (autocrop) and resource (the image/document), and clarifies the operation targets non-empty content rather than a manual region. It is clear on its own but never references the closely related sibling document_crop, leaving the agent to infer the distinction between automatic and manual cropping.

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 choose autocrop versus document_crop, document_scale, or document_resize, all of which appear in the sibling list. The 'optionally using a specific layer' clause hints at a mode but does not state when that mode is warranted.

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 discloses the coordinate space ('canvas pixels'), which is useful, but says nothing about whether cropping is destructive to the document or layers, undo behavior, or how it interacts with the session.

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. It is efficient, though its brevity comes at the cost of the missing guidance noted elsewhere rather than being tight but complete.

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 5-parameter mutation tool with no annotations and zero schema description coverage, this is under-specified. An output schema exists so return values need not be explained, but the missing coordinate and side-effect semantics leave real gaps.

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

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

Schema description coverage is 0% across 5 parameters, and the description only partially compensates by establishing that dimensions are in canvas pixels. It never clarifies that x/y is the top-left corner of the rectangle, nor what session_id identifies.

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 (crop) and resource (the image) plus the scope (bounded rectangle in canvas pixels). It does not differentiate itself from the sibling document_autocrop, which is the most likely confusion point for an agent.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative document_autocrop for automatic cropping. The agent must infer selection criteria entirely from the name.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the operation is snapshot-undoable and that only visible content is flattened, but it does not explain hidden-layer handling, destructiveness, permissions, or session requirements.

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

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

The description is two short, front-loaded sentences with no wasted words. The core effect is stated first and the undo behavior follows immediately.

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

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

The description covers the primary operation and undoability, and an output schema exists so return values need not be explained. However, for a mutation tool with no annotations, it omits important context such as hidden-layer behavior and the role of session_id.

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

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

The schema has 0% description coverage and the only parameter is session_id, yet the description adds no information about it. The parameter name is somewhat self-explanatory, but the description does not compensate for the missing schema semantics.

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

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

The description states a specific verb and resource: flatten all visible image content to one layer. It is clear enough to distinguish from most document tools, but it does not explicitly differentiate itself from similar siblings like layers_merge_visible or layer_merge_down.

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

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

There is no guidance on when to use this tool versus alternatives such as layers_merge_visible or layer_merge_down. The description implies the operation but provides no context, prerequisites, or exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that pixels are not scaled and that offsets position the old image within the new canvas, but it omits whether the operation modifies the session in place, permission requirements, and edge case behavior for resizing to smaller dimensions.

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 tightly written sentences with the core operation front-loaded and the offset behavior as a clarifying second sentence. 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?

With no annotations and a 0%-covered input schema, the description covers the main operational distinction and offset meaning but leaves gaps around session requirements, mutation side effects, and what happens when the new canvas is smaller than the old image. The output schema handles return values, so that is not a gap.

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

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

Schema description coverage is 0%, so the description must compensate. It explains offset_x and offset_y ('position the old image within the new canvas') and implies width/height set the new canvas size, but session_id is not described and width/height semantics rely on inference from the purpose statement.

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 ('Resize') and resource ('canvas'), and the phrase 'without scaling pixels' distinguishes it from a scale operation like document_scale. The distinction is clear, though no sibling tool is named explicitly, so it falls 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?

The description implies when to use it: to change canvas dimensions without scaling the image content. However, it does not explicitly name alternatives such as document_scale, document_crop, or state exclusions or prerequisites, leaving usage guidance 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, the description carries the full burden and does disclose two useful traits: it refuses overwrites unless explicitly enabled, and it restricts writes to an allow-listed XCF path. It omits failure modes, whether the session document state changes, and any permission requirements.

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 primary action and followed by the key safety constraint. 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?

An output schema exists, so return values need not be described. However, with no annotations and 0% parameter coverage, the description should say more about session_id and about the consequences of the operation on session state to be fully actionable.

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 does add meaning for two parameters (overwrite's refusal semantics and output_xcf's allow-list restriction) but leaves session_id completely unexplained in both schema and description.

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

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

States a specific verb (commit/save) and resource (the current session document) with a destination constraint (an allowed XCF path). This is clear enough to separate from export_image at a glance, though it never names the sibling it most resembles.

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 use this tool versus export_image or any other save/export sibling. The only conditional in the text is about overwrite refusal, which is behavior, not 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?

No annotations are provided, so the description carries the full burden. It does disclose that the operation affects all layers, which is useful scope information, but it omits whether the change is destructive/undoable, what resampling or interpolation is used, and what permissions or session state 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?

A single short sentence with the scope stated up front and no filler. It is appropriately sized, though there is little structured detail to front-load.

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

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

An output schema exists, so return values need not be explained. But for a mutation tool with no annotations and 0% parameter documentation, the description should cover session requirements and the irreversible/side-effect profile of scaling all layers; those gaps leave it incomplete.

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 there are three required parameters. The description only echoes width and height (whose names are already self-explanatory) and says nothing about session_id, the units, constraints, or behavior on non-integer/odd 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 (scale) and resource (full image and all layers), which is clearer than a bare name. However, it does not differentiate from the sibling document_resize, leaving the agent unsure which operation to pick. Scope is stated but the resize/scale distinction is left unresolved.

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

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

There is no guidance on when to use this tool versus document_resize or the layer_resize tools. Nothing indicates prerequisites such as an active session or when scaling is preferable to resizing.

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, yet it only says the events are 'recent' and 'live'. It does not disclose pagination behavior, ordering, whether results are capped, whether it blocks, or any auth/permission requirements for an observation surface.

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 resource and audience front-loaded and no wasted words. It is arguably too terse for the burden it must carry, but the structure itself is clean.

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

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

An output schema exists, so return values need not be explained, but for a parameterized observation tool with zero annotations and zero schema description coverage, the description leaves the agent guessing about filtering scope and result limits. It is under-specified relative to 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%, and the description never mentions either parameter. The meaning of 'limit' (default 100) and especially 'session_id' (does omitted mean all sessions?) is left entirely undocumented, so the description fails to compensate for the coverage 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 ('Return recent live operation events') and names the audience ('observers and control UIs'), which tells an agent what it gets back. It does not differentiate itself from siblings like session_list or gimp_status, 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 phrase 'for observers and control UIs' implies a usage context (polling for live state rather than inspecting a session or a status tool), but no explicit when-to-use or when-not-to-use guidance is given relative to the many sibling tools. The agent must infer that this is a monitoring/polling surface.

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 says nothing about overwrite semantics, whether the source artwork is modified, whether the exported XCF flattens layers, or what permissions/state the session must be in — all material for a write-to-disk operation with an overwrite flag.

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

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

A single front-loaded sentence with no filler; the format list is the useful payload. It is arguably too terse given the undocumented parameters, 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?

An output schema exists so return values need not be described, but for a four-parameter file-export tool with zero schema coverage and no annotations, the description omits overwrite behavior, path requirements, and session prerequisites — the agent lacks enough to call it confidently against the alternatives.

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

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

Schema description coverage is 0%, so the description must compensate, but it only echoes the format options. The required session_id and output_path and the overwrite boolean are left completely unexplained, including path resolution rules and what overwrite=false does when the file exists.

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 (current artwork) plus the three output formats, which maps exactly to the format enum. However, it does not distinguish itself from the sibling export_image, so an agent cannot tell from the description alone which export 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?

No when-to-use or when-not-to-use guidance, no prerequisites (e.g., an active session), and no routing against the near-synonymous sibling export_image or publish_artwork_downloads. The agent must infer selection from name similarity 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?

No annotations are provided, so the description carries the full burden. It does disclose one genuine behavioral trait — the output format is inferred from the file extension — but says nothing about what happens when output_path already exists and overwrite is false, permissions, or whether the session is mutated.

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 core action and the format-selection behavior front-loaded. No filler, though it is short enough that the missing guidance is conspicuous rather than trimmed.

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

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

An output schema exists, so return values need not be explained, and the mutation nature is clear from 'Export'. However, for a write-to-disk tool with zero annotations and undocumented overwrite semantics, the description should address file-collision and session-state requirements.

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 3 parameters. The description adds real meaning for output_path (its extension determines the encoded format), which is more than the bare schema, but session_id and especially overwrite (default false, unclear collision behavior) are left undocumented.

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

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

States a specific verb (Export) and resource (the session) plus the target artifact (image in PNG/JPEG/WebP/other GIMP format). It does not explicitly differentiate itself from the sibling document_save_as, which is the nearest ambiguity, 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?

There is no guidance on when to choose this over document_save_as or any other sibling, no prerequisites, and no note about requiring an open/active session. Usage must be inferred entirely from the name and the word 'session'.

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 clearly indicates the operation is non-destructive (creates a DrawableFilter), which is valuable behavioral context. However, it omits permission requirements, whether the filter is applied immediately or requires a render step, and effects on the layer's state.

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

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

Two sentences, front-loaded with the core action and the key non-destructive attribute. Efficient and no wasted words.

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

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

For a 5-parameter mutation tool with nested objects and no annotations, the description is insufficient. It references discovery but doesn't detail parameter usage or expected outcomes, and an output schema exists but the description doesn't leverage it to clarify return behavior.

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

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

Schema description coverage is 0%, so the description must compensate for all parameter semantics, but it only hints at the 'operation' and 'parameters' fields indirectly. It doesn't explain 'session_id', 'layer_id', 'name', or the expected structure of the 'parameters' object, leaving critical parameters 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 (Apply) and resource (GEGL operation as a non-destructive GIMP DrawableFilter) on a specified target (a layer). This distinguishes it from filter_list and filter_describe, which are read-only discovery tools, and from structural tools like layer_delete.

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 'Discover parameters first if uncertain' implies a workflow involving filter_describe, but it doesn't explicitly say to use filter_list/filter_describe as the alternative. No when-not-to-use or prerequisites (like session/layer existence) 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 provided, so the description carries the full behavioral burden. 'Describe' strongly implies a safe read operation and the existence of an output schema covers return values, but the description never confirms it is read-only (no side effects on GEGL state) or mentions any constraints. It is adequate but thin for a zero-annotation 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 with no filler. The purpose and the downstream benefit are both stated compactly.

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

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

For a simple one-parameter describe tool with an output schema, the description covers what it does and why it is useful, which is nearly sufficient. Minor gaps: no note on the operation-name format or a pointer to filter_list for valid names.

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 'operation' parameter has no description in the schema. The description only obliquely indicates the parameter is a GEGL operation, but gives no expected format or example (e.g. 'gegl:blur'), so it fails to compensate for the coverage 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 ('describe') and resource ('a GEGL operation's configurable properties'), and even names the downstream goal (constructing a valid filter_apply call). An agent can clearly distinguish it from siblings filter_list and filter_apply 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 'so an AI can construct a valid filter_apply call' implies this is a prerequisite step before filter_apply, which is useful implied guidance. However, it never explicitly states when to call this vs filter_list (to discover operation names) or filter_apply, nor any ordering or exclusion, leaving the workflow inference-based.

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 implies a safe, read-only discovery operation but does not state the result size behavior (limit defaults to 100) or that results may be truncated, and says nothing about auth or rate limits. Adequate but with a clear gap for a no-annotation 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?

Two tight sentences with the purpose front-loaded and the routing guidance second. Every clause earns its place.

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

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

An output schema exists, so return values need not be described, and the core purpose/routing is covered. However, the two undocumented parameters and the absence of any result-count or truncation context leave gaps for a discovery tool.

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

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

Schema description coverage is 0%, so the description must compensate, but it never mentions the limit or query parameters. An agent cannot learn from the description that query filters operations by name or that limit caps results, so meaning is left entirely to bare schema fields.

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 (discover) and resource (GEGL operations), and explicitly names the two sibling tools it relates to (filter_describe/filter_apply). An agent can distinguish this listing tool from the describe/apply tools 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?

Gives an explicit precondition: use this before filter_describe/filter_apply when the exact operation name is unknown. That is a concrete when-to-use rule tied to the 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?

No annotations are provided, so the description carries the full disclosure burden; it declares read-only, which is the key safety fact. However it says nothing about failure modes, what happens if GIMP is missing, or performance characteristics of the probe.

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 with zero waste: the verification scope, the safety profile, and the usage trigger are all front-loaded and each earns its place.

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

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

For a no-param diagnostic with an output schema (which need not be described), the description covers what it verifies and when to call it. Only minor gaps remain, such as what a negative result implies or what remediation to consider next.

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 to document and the schema is fully covered. Baseline of 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?

States a specific verb (verify) and resource (the real GIMP binary, Python GI bridge, PDB), so the agent knows exactly what is checked. It does not explicitly distinguish itself from similarly named siblings like provider_status or triforce_status, though naming GIMP does implicitly scope it.

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?

Explicitly says to use it first when diagnosing setup problems, giving clear situational guidance. It stops short of naming the alternatives or stating when not to use it.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a document mutation but does not say whether the guide is undoable, which session/document is affected, whether permission or active-session prerequisites apply, or whether it modifies the live 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, front-loaded sentence with no filler. It is appropriately sized but so terse that it omits information the agent needs, which is an underspecification issue rather than a verbosity one.

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

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

An output schema exists, so return values need not be explained. However, for a mutation tool with three required parameters at 0% schema coverage and no annotations, the description omits parameter meaning, prerequisites, and effects, leaving significant gaps.

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

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

Schema description coverage is 0%, and the description only echoes the orientation concept already encoded in the enum. It adds no meaning for session_id (which session?) or position (units, origin, range), leaving two of three required parameters undocumented.

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

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

The description states a specific verb (Add) and resource (horizontal or vertical image guide), which clearly separates it from sibling guide_list and guide_delete. It does not explicitly name or contrast those siblings, though the noun 'guide' plus verb makes the intent inferable.

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 add a guide versus listing or deleting one, nor any prerequisites (e.g., an active session, an open document). The agent must infer usage entirely from the verb and sibling names.

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

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

No annotations are provided, so the description carries the full burden. 'Delete' implies a destructive mutation, but the description never states irreversibility, undo behavior, or required permissions/session validity, and it omits the session_id requirement entirely.

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 zero filler. It is efficient, though arguably under-specified rather than simply concise.

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

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

An output schema exists so return values need not be described. Still, for a destructive tool with no annotations and an undocumented required session_id, the definition is barely adequate for correct invocation.

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

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

Schema description coverage is 0% and the description only references guide_id. The required session_id parameter is never explained, nor is the ID's origin or format, so the description does not compensate for the coverage 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+resource (delete a guide) and scopes it to a single item by guide_id. However it does not distinguish itself from siblings like guide_add/guide_list, so an agent must infer the boundaries.

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 prerequisites, and no mention of alternatives. Nothing tells the agent that guide_list or guide_add exist as related operations.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description says nothing about permissions, whether it scopes to a session's document, or any other behavioral trait beyond the bare action.

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 that is front-loaded and free of waste. It is efficient, though arguably under-specified rather than truly concise.

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

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

An output schema exists, so return values need not be explained. For a simple one-parameter list tool this is nearly adequate, but the missing session/scope context and the undocumented session_id leave a real gap.

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

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

Schema description coverage is 0% for the single session_id parameter, and the description does not explain what session_id refers to or how the guides are associated with it. With low coverage the description should have compensated, but it adds no parameter meaning.

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

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

The description states a specific verb (List) and resource (image guides and positions), which is clear enough to distinguish it from the sibling guide_add and guide_delete tools by implication. It does not explicitly name those alternatives, but the purpose 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?

There is no guidance on when to use this tool, when not to, or which sibling to prefer. The agent must infer from the name alone that this is the read counterpart to guide_add/guide_delete.

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 credentials are not exposed, which is meaningful for a status tool, but it does not state whether the operation is read-only, what authentication is required, or any rate limits.

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 wasted words. The scope (workspace state and GIMP worker pool) is stated immediately, followed by the credential-safety note.

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

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

An output schema exists, so the description need not explain return values, and there are no parameters to document. It covers what is being reported and a key behavioral constraint, though it omits when to prefer this tool over other status siblings.

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

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

There are zero parameters, so the schema has nothing to document. Per the rubric, a parameterless tool receives a baseline of 4 when no additional parameter semantics are needed.

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 ('Report') and two clear resources: visible/headless workspace state and the configured headless GIMP worker pool. It is distinguishable from generic status siblings like gimp_status or live_bridge_status by its workspace/worker-pool focus, though it does not explicitly name alternatives.

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

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

The description says what the tool reports but offers no guidance on when to use it versus siblings such as gimp_status, live_bridge_status, or session_list. Usage is only implied by the tool name and resource.

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, yet it only says a new layer is created. 'Allowed image file' hints at a restriction but never states which formats are accepted, what happens on rejection, or whether the import mutates existing layers.

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 action and target front-loaded and no padding. It is terse rather than bloated, though brevity comes at the cost of the missing detail noted elsewhere.

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

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

An output schema exists so return values need not be explained, but for a mutation tool with no annotations and 0% parameter coverage the description is too thin — it omits the accepted formats, the naming behavior, and any failure conditions.

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 three parameters. The description loosely maps 'image file' to path and 'current artwork session' to session_id, but says nothing about the optional name parameter, so the agent gains no real semantics beyond the schema's field names.

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 (import) and resource (image file becoming a new layer) scoped to the current artwork session, so the agent can tell it apart from generic layer tools. However, it never distinguishes itself from the sibling layer_create, and 'allowed image file' leaves the accepted formats undefined.

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

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

No guidance on when to choose this over layer_create, layer_duplicate, or transform_layer, and no mention of prerequisites such as an open session or supported file types. The agent must infer the selection criteria entirely.

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. 'Ensure' weakly implies idempotent conditional behavior (add alpha only if missing), but it says nothing about whether this mutates in place, what happens if alpha already exists, or whether the change 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?

A single, front-loaded sentence with no wasted words. Its brevity is appropriate, though it borders on under-specification given the tool's mutation behavior.

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

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

An output schema exists, so return values need not be explained, but for a mutating tool with zero annotation coverage and 0% parameter documentation, the description should at least address idempotency and error/side-effect behavior. It leaves significant gaps.

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

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

Schema description coverage is 0% and the description adds no meaning for layer_id or session_id. The parameter names are fairly self-explanatory, but neither the schema nor the description clarifies required session context or layer scoping.

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 ('ensure') and resource ('alpha channel' on a layer), so the operation is unambiguous. However, it does not distinguish itself from siblings like layer_create or layer_update, which could plausibly also affect alpha channels.

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 indication of when to use this versus alternatives such as layer_update or layer_create, no prerequisites, and no exclusions. The agent must infer the usage context entirely.

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 disclose real behavior: dimension defaults fall back to canvas size, opacity is on a 0..100 scale, blend_mode accepts documented LayerMode names, and the returned layer_id is persistent. However it omits the layer's insertion position in the stack, session requirements, and failure behavior 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?

Three compact sentences, front-loaded with the core action, then defaults, then accepted values, then return semantics. No filler or restatement of the title.

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

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

With no annotations and a mutation tool, the description should do more: it never clarifies where the new layer is placed, what the required session_id implies, or what 'visible' controls. The output schema covers the return type, so mentioning layer_id is a minor bonus rather than a necessity.

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 documents width/height defaults, the opacity range, and blend_mode values. It leaves 'name', 'visible', and the required 'session_id' entirely unexplained, so roughly half of the seven parameters remain 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?

States a specific verb+resource ('Create a transparent layer') and adds the distinguishing scope that the result is a new persistent layer with its own layer_id. An agent can separate this from layer_duplicate, shape_create, and text_create 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?

The description never says when to use this versus siblings like layer_duplicate or shape_create, nor does it state prerequisites beyond the implicit session. Usage is only inferable from the tool name and the 'create a layer' phrasing.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose one meaningful trait: the deletion is snapshot-undoable, implying reversibility rather than permanent destruction. It omits whether a session must be open, permission requirements, or what happens to layer references, so disclosure is partial.

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

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

Two short sentences, front-loaded with the action and target, with no filler. Every clause contributes (what it does, what identifies the target, and one behavioral trait).

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

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

An output schema exists, so return values need not be explained, and the reversibility note is useful. However, for a mutation tool with no annotations and an undocumented session_id, the description should say more about session context and failure modes to be fully actionable.

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

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

Schema description coverage is 0% for two parameters, and the description only touches layer_id (the target layer), leaving session_id completely undefined in both schema and prose. One of the two required parameters has no semantics anywhere, so coverage is inadequate.

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 with scope ("Delete one layer identified by layer_id"), which cleanly separates it from layer_create, layer_update, and layer_reorder. It stops short of naming any alternative or clarifying intended/deleting conditions, so it is clear but not maximally differentiating.

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

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

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no mention of alternatives. Notably, the tool says the operation is snapshot-undoable but never points the agent at session_undo for reverting it, which is the obvious routing an agent might need.

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 notes that a new persistent layer_id is returned, implying a non-destructive copy, but it omits whether the original is modified, required session permissions, and 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?

Single sentence, front-loaded, and no wasted words.

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

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

For a mutation tool with no annotations and zero schema coverage, the description is too sparse. While the output schema covers the return value, the description does not address parameter usage, prerequisites, or side effects.

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 three parameters. The description implies layer_id but says nothing about session_id or the optional name parameter, failing to compensate for the coverage gap.

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

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

The description states a specific action and resource: duplicate a layer. It does not explicitly differentiate from siblings like layer_create or import_layer, but the action itself is distinct enough that an agent can tell what it does.

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

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

No when-to-use guidance, prerequisites, or alternatives are given. It merely states the action, leaving the agent to infer context.

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

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

With no annotations, the description carries the burden and does disclose one real behavioral trait: the change is snapshot-undoable, which tells the agent it can be reversed. It does not cover permissions, interaction with layer alpha/transparency, or failure behavior, leaving notable 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?

A single compact sentence with the primary action front-loaded and the no-selection fallback appended. No wasted words.

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

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

An output schema exists, so return values need not be described, and the undo note plus targeting rule cover the core behavior. However, for an unannotated mutation tool with 0% schema coverage, the missing parameter documentation and error/permission context leave it only partially complete.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It only adds meaning for color (CSS/Gegl format, default black implied); layer_id and session_id go completely unexplained in both schema and description.

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

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

States a specific verb (fill) and resource (selected area of a layer) plus the fallback scope when no selection exists. An agent can immediately tell what the tool does, and no sibling tool overlaps this fill 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?

The description gives a conditional behavior (fills selection if present, whole layer otherwise), which implicitly guides usage, but it never states when to choose this over alternatives like shape_create or filter_apply, nor any prerequisites such as an active session or layer.

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 states the mutation and mentions returning a layer_id, but does not disclose whether the source layer is removed, whether the action is reversible, how merge_type affects behavior, or what permissions 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 with no filler. Every clause earns its place, even though more detail is needed elsewhere.

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, 0% schema description coverage, and a meaningful enum parameter, the description is too thin. The output schema can cover return values, but the description should still explain the merge_type options and basic behavioral impact.

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 three parameters. The description only implicitly covers layer_id and the merge direction; it says nothing about session_id or the merge_type enum values (expand, clip-image, clip-bottom), so it fails to compensate for the missing schema documentation.

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

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

The description states a specific verb and resource: merge one layer into the next layer below. It implies the directional distinction from layers_merge_visible, but never names that sibling or explicitly contrasts with it.

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 when-not-to-use guidance, and no mention of alternatives such as layers_merge_visible or document_flatten. The operation is implied only by the tool name and a short description.

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 discloses the position-indexing convention but nothing about side effects, whether other layers shift, required session state, or reversibility for what is clearly a mutation.

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 zero filler; the most important convention (indexing origin) is stated immediately.

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

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

An output schema exists so return values need not be explained, and the indexing convention is covered. However, for a no-annotation mutation tool with 0% param coverage, missing details on session context, shifting behavior, and the two undocumented parameters leave it only partially complete.

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

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

Schema coverage is 0%, so the description must compensate. It clarifies the critical 'position' parameter (zero-based, 0 = top) but leaves session_id and layer_id entirely undocumented in both schema and description.

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

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

States a specific verb+resource ('Move a layer') and adds the key semantic detail of a zero-based stack position with 0 as the top. It is clearly distinct in spirit from layer_create/layer_delete/layer_update, though it does not explicitly name them.

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

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

No when-to-use guidance, prerequisites, or alternatives are given. The intent is inferable from the name and siblings, but nothing states when to reorder versus use layer_update or transform_layer.

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

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

With no annotations, the description must carry the full behavioral burden. It usefully discloses that pixels are not scaled, which is a non-obvious and important trait. However, it omits mutation/reversibility details, session or permission requirements, and how offset_x/offset_y affect the operation, leaving 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 wasted words. It communicates the core operation and its key constraint immediately, which is an efficient structure for an agent scanning tool definitions.

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

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

Although an output schema exists and return values need not be explained, this is a mutation tool with six undocumented parameters and no annotations. The description omits parameter meanings, usage context, and permission/reversibility basics, so it is not complete enough for reliable invocation.

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

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

Schema description coverage is 0% and there are six parameters, including required session_id, layer_id, width, and height. The description mentions none of them, so it adds no meaning beyond the bare schema names and does nothing to compensate for the complete lack of parameter documentation.

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

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

States a specific verb (Resize) and resource (a layer boundary), and adds the key constraint 'without scaling its pixels' to distinguish it from scaling operations. However, it does not explicitly differentiate from close siblings such as layer_resize_to_image or document_scale, so the agent must infer when this specific resize is appropriate.

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 offers no when-to-use guidance, prerequisites, or alternatives. It does not mention when this tool should be chosen over layer_resize_to_image, document_resize, or transform_layer. The agent receives no routing help beyond the core purpose.

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

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

No annotations are provided, so the description carries the full burden, yet it only restates the operation. It does not disclose whether the resize is destructive to existing layer content, what happens to pixels outside the new boundary, or any session/auth requirements 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?

A single efficient sentence with the action verb front-loaded and no wasted words. It is appropriately sized for the operation, though it is arguably too terse given the missing 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?

An output schema exists so return values need not be explained, but for a mutation tool with no annotations and zero parameter documentation the description is not complete enough. It omits prerequisites, side effects, and parameter meaning that an agent needs to invoke it correctly.

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

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

Both parameters (session_id, layer_id) have 0% schema description coverage and are not mentioned in the description, so an agent gets no meaning for their format or valid values. The description could easily have clarified that layer_id targets the layer whose boundary is resized.

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 (resize) and resource (layer boundary) with a clear target (the current image canvas), so the agent knows exactly what operation occurs. It does not, however, distinguish itself from the sibling layer_resize, which an agent would reasonably consider an alternative.

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

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

There is no when-to-use guidance, no prerequisites (e.g. an active session or selected layer), and no mention of when to prefer this over layer_resize or document_resize. Usage must be inferred entirely from the name.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the key behavioral trait — visible layers are collapsed while hidden layers survive — but says nothing about reversibility, undo requirements, or what happens to the resulting merged 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?

A single front-loaded sentence that states the action and its distinguishing constraint with zero waste.

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

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

An output schema exists so return values need not be explained, and the core behavior is clear. However, the undocumented merge_type modes and absent mutation semantics (reversibility, permissions) leave real gaps for a two-parameter mutation tool with no annotations.

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

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

Schema description coverage is 0% for two parameters. The description never mentions session_id and completely ignores merge_type, whose three enum values (expand, clip-image, clip-bottom) are left unexplained, so it fails to compensate for the coverage 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 (merge) and resource (visible layers) and adds the scope qualifier that hidden layers are preserved. This meaningfully separates it from layer_merge_down and document_flatten, though neither 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: use this when you want visible layers combined but hidden ones kept. The 'preserving hidden layers' clause hints at the alternative (flatten for everything), but no when/when-not guidance or sibling reference is 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 provided, so the description carries the full burden. 'Update' implies mutation but the description says nothing about permission/session requirements, whether unspecified fields are left untouched, reversibility, or side effects on related layers. Listing the mutable fields is the only behavioral signal.

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

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

A single compact sentence with no filler, and the field list is front-loaded after the verb. It is neither padded nor vague, though the dense comma-list is slightly harder to scan than a structured enumeration.

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

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

An output schema exists, so return values need not be described. But for a 9-parameter mutation tool with zero annotation coverage and no schema descriptions, the definition omits the identity parameters, does not state that only supplied fields change, and gives no hint about failure modes or session handling.

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 partially does: it maps name, visible, opacity, blend_mode, lock_alpha and clarifies that x/y are 'absolute offsets' rather than relative deltas, which the bare schema titles do not convey. However, session_id and layer_id are never explained, and optionality/partial-update semantics (all non-required params default to null) are left unstated.

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

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

Specific verb ('Update') plus resource ('layer') and an enumerated list of mutable fields, so the agent knows exactly what the tool does. It does not differentiate itself from adjacent mutators such as layer_resize, transform_layer, or layer_reorder, which is the only thing keeping 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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling layer-mutation tools. The agent must infer that this is the general-purpose property editor rather than, say, layer_resize or transform_layer.

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 that a connected bridge mirrors successful edits into an open GIMP display, but it does not state what a disconnected result implies, whether the call is strictly read-only, or any failure behavior.

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

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

Two short sentences with no wasted words. It front-loads the return value and then adds the only meaningful behavioral context.

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

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

An output schema exists, so the description need not explain return values. For a no-argument status probe it is nearly sufficient, but it does not disambiguate from other *_status sibling tools.

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

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

The tool takes zero parameters, so the schema has no parameter semantics for the description to clarify. Baseline 4 applies for a no-argument tool with complete schema coverage.

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

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

States a specific verb and resource: return whether the persistent visible GIMP bridge is connected. It does not distinguish this from sibling status tools such as gimp_status or provider_status, so it falls short of 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?

No explicit when-to-use guidance, prerequisites, or alternatives are given. The second sentence describes behavior when connected, not when this tool should be selected over gimp_status or headless_workspace_status.

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 delivers substantial behavioral detail on how argument types are interpreted (GimpImage binds to session, Drawable/Layer/Item accept layer_id, GFile accepts a path, RunMode accepts specific values). It omits potential error handling or side-effect disclosure, but the core argument-mapping behavior is well covered.

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 front-loaded and dense with information, moving from core purpose to prerequisite to argument-type mappings in a minimal number of words. Every sentence adds distinct value, with no redundancy or 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?

Given the tool's complexity (generic PDB bridge, nested arguments object, output schema present), the description provides the essential context an agent needs to invoke it correctly, especially the argument-type mapping. It could mention error conditions or that arguments must match the procedure's signature, but the output schema covers return values and the core invocation details are present.

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 effectively by explaining the special handling for GimpImage, Drawable/Layer/Item, GFile, and RunMode arguments. It does not explicitly define the session_id or name parameters, but their meaning is strongly implied by the tool's overall purpose.

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 (calls) and resource (a discovered official PDB procedure against a session), making the tool's purpose clear. It differentiates from pdb_describe by instructing 'Use pdb_describe first', but does not explicitly contrast with pdb_search or the layer_* siblings, leaving some sibling differentiation 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?

It provides a prerequisite ('Use pdb_describe first'), which implies this tool is for executing previously discovered procedures. However, it lacks explicit guidance on when to use this generic bridge versus the many specific operation tools (e.g., layer_duplicate, document_resize), leaving usage context 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, the description carries the full behavioral burden; it correctly supplies the key trait 'read-only,' which is genuinely useful. It does not say what happens with an unknown procedure name, whether names are case-sensitive, or how the inspection result should be interpreted.

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

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

Two short sentences, front-loaded with the action and resource before the read-only note. The 'Expert discovery:' prefix is mild flavor but not wasteful.

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

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

An output schema exists, so return values need not be described, and the read-only nature is stated. For a one-parameter introspection tool this covers the essentials, with only the name-if-unknown behavior left implicit.

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

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

Schema description coverage is 0% for the single 'name' parameter, so the description must compensate. It implies the parameter is a GIMP PDB procedure name via 'one GIMP PDB procedure,' which is meaningful, but gives no format, source, or naming conventions.

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 (inspect) and resource (arguments and returns of one GIMP PDB procedure), so the agent knows it is a metadata/introspection call. It implies differentiation from pdb_search by emphasizing 'one' procedure, but never names the sibling that lists many.

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?

'Expert discovery' hints at the intended audience and context, which implies usage after finding a procedure name. However, there is no explicit when-to-use vs pdb_search, no prerequisite that a name must already be known, and 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?

No annotations are provided, so the description carries the full burden, and it does disclose the tool's rationale (avoiding thousands of exported tools) and implicitly that it is a read-only discovery operation. However, it never says how matching works (substring, prefix, regex, case sensitivity) or how results are bounded. Return format is covered by the output schema, which partially offsets the 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 no filler; the purpose and its justification are front-loaded. It is efficient, though brevity here comes at the cost of operational detail.

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

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

For a two-parameter search tool with an output schema, the essential missing piece is the matching semantics of 'query' and the meaning of 'limit' – neither is addressed. With the output schema covering return values, the description is adequate but leaves a real gap for correct invocation.

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

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

Schema description coverage is 0% and neither parameter is explained. The description says nothing about what 'query' matches against or how 'limit' truncates results, so it fails to compensate for the undocumented schema.

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

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

The description states a specific verb and resource: 'search GIMP PDB procedure names', and clarifies the mechanism ('without exporting thousands of procedures as MCP tools'). It distinguishes itself from sibling pdb_describe implicitly by being about discovery/search rather than describing a single procedure, though it never names that 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?

'Expert discovery' implies an audience but gives no explicit when-to-use condition, no prerequisites, and does not name any alternative such as pdb_describe or filter_list. An agent must infer the routing decision entirely.

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 usefully discloses a non-obvious side effect (a successful render refreshes the coordinate-overlay and rolling GIF vision resources) plus the non-mutation guarantee. However, it says nothing about failure behavior, permissions, size limits beyond 'bounded,' or format probing, so the behavioral picture is partial.

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 front-loaded and the side-effect detail second. No filler, no redundancy.

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

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

An output schema exists, so return values need not be described, and the side-effect note covers the biggest behavioral unknown. Still, for a tool with zero parameter documentation and no annotations, the definition leaves an agent guessing about argument semantics and error/edge behavior.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does not. 'Bounded' hints at max_width/max_height but never explains whether the box preserves aspect ratio, whether dimensions are scaled or cropped, or what session_id identifies; the defaults of 1200 are left 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) and a specific artifact (bounded PNG preview), which is more precise than a bare name restatement. It is not fully differentiated from close siblings like vision_capture or export_image, but an agent can tell it produces a preview image.

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

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

No when-to-use guidance is given: nothing says when a preview is preferable to vision_capture, export_image, or export_artwork, and no prerequisites or exclusions are stated. The only usage-adjacent phrase, 'without modifying the artwork,' describes a side effect rather than selection criteria.

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

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

With no annotations, the description carries the full burden. 'List' implies a non-destructive read and 'already-linked' discloses a prerequisite, which is useful behavioral context. It does not disclose failure behavior for unlinked providers, whether results are cached/live, or any rate limits.

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

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

One front-loaded sentence with zero waste; the verb and scope come first and the constraint follows immediately.

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

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

An output schema exists, so return values need no explanation. For a one-parameter read tool, the description supplies the resource, the provider value set, and the linked-account precondition, which is sufficient for correct invocation.

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

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

Schema coverage is 0% and the single 'provider' parameter has no enum, so the schema alone leaves the accepted values undefined. The description compensates by naming the valid providers (ChatGPT, Claude, Gemini, Mistral), effectively supplying the missing value set, though it doesn't state exact string casing or format.

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

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

The description states a specific verb and resource ('List models') and scopes it to the four named provider accounts. It does not explicitly distinguish itself from siblings like provider_status or triforce_models, but the resource ('models' per provider account) 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 phrase 'already-linked' implies a precondition, so an agent can infer this only works after an account is linked. However, there is no explicit when-to-use guidance, no statement of what to do when no provider is linked, and no routing versus provider_status or triforce_models.

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 disclose one useful behavioral fact -- that no credentials are returned -- which is a meaningful data-safety signal, but it omits whether the call requires authentication, whether it is read-only, or what happens 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 short sentences with no filler, and the credential-safety guarantee is front-loaded alongside the purpose. 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?

With zero parameters and an output schema, the description needn't explain return values, so the core is covered. However, it offers no routing context against several similarly named status siblings, leaving a real gap for tool selection.

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 are no parameter semantics to explain; the baseline of 4 applies. Schema coverage is 100% and empty, so nothing is missing.

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 ('Report') and resource ('native official-provider account status'), which lets an agent distinguish it from provider_models and the various *_status siblings. It is clear but lacks a precise definition of what 'native official-provider' scopes to.

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 when this is preferable to provider_models, triforce_status, live_bridge_status, or gimp_status, and no prerequisites. The agent is left to infer the use case 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the exported formats and that the links expire, but omits auth/permission requirements, whether any session state is modified, and how the expiration relates to the ttl_seconds parameter.

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. It leads with the verb and resource and efficiently packs formats, return type, and audience into one line.

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

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

An output schema exists, so return values need not be explained in detail. However, with no annotations and 0% parameter description coverage, the description should do more to explain session_id and ttl_seconds and to distinguish this tool from nearby export siblings. It is adequate but has clear gaps.

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

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

Schema description coverage is 0% for both parameters. The description does not mention session_id or ttl_seconds at all; 'expiring' only vaguely hints at the TTL concept without explaining how to control it. The description fails to compensate for the undocumented schema.

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

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

States a specific verb ('Export') and resource ('final artwork') with concrete output formats (XCF, JPEG, PNG) and the return behavior (three expiring HTTPS links). It does not explicitly name or contrast with sibling tools like export_artwork or export_image, so it is clear but not fully differentiated.

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

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

The phrase 'for external/autonomous clients' gives an intended usage context, implying when the tool is appropriate over file-only exports. However, it does not state when-not to use it or name any alternative sibling tool, leaving the routing decision partly 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, the description carries full burden. It mentions that it can 'modify the current selection,' which hints at mutation, but says nothing about permissions, reversibility, effect on existing selection, or side effects. The polygon note is the only extra behavioral detail.

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

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

Two tight sentences, front-loaded with the core purpose. Every sentence earns its place, and there is no filler or repetition.

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

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

The tool has 12 parameters, 11 action enum values, and no annotations. The description does not explain what any action does, how operation combines selections, or what most parameters mean. Although an output schema exists and return values needn't be explained, the description is far too sparse to call this tool correctly.

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

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

Schema description coverage is 0% across 12 parameters. The description clarifies only one parameter's format ('points are a flat x/y list'), leaving x, y, dx, dy, steps, width, height, radius, operation, action, and session_id entirely undocumented. This does not compensate for the severe schema coverage gap.

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

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

The description clearly names the verb set (create/combine/modify) and the resource (geometry selections/current selection). It doesn't differentiate from any sibling tool, but that's potentially acceptable given no obvious selection-related sibling. The polygon point format note is useful.

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

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

No guidance on when to use this tool versus alternatives, no prerequisites, no exclusions. It only states what it does, not when or why to choose it. An agent receives no routing help.

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 a key destructive trait: discard=true deletes the temporary XCF and history. It does not state the default outcome when discard is false (session closed but artifacts retained), nor reversibility or permission requirements, 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?

Two short sentences, front-loaded with the core action and then the conditional flag behavior. No wasted words, though it is terse to the point of under-specifying for a mutation tool.

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

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

An output schema exists, so return values need not be described. However, with zero annotation coverage and 0% parameter schema coverage, the description should do more to pin down the default close behavior and its place among the session lifecycle siblings.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning for 'discard' (deletes temp XCF and history), but adds nothing for session_id, which is only self-evident from its name.

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 ('Close a session'), which is unambiguous against siblings like session_open and session_create. It does not, however, explicitly contrast itself with lifecycle siblings such as session_undo or session_info, so it falls short of full sibling differentiation.

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

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

The description gives conditional behavior for the discard flag but no guidance on when to close a session versus alternatives, nor any prerequisites (e.g. must the session be active, does saving happen first). Usage is only implied.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the key side effect — returns a session_id consumed by all editing tools — but says nothing about persistence, resource limits, or lifecycle constraints for a creation 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?

Two tight sentences with the core action front-loaded and the return value stated second. 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?

An output schema exists, so return-value detail is not required, though the description reinforces the session_id contract. For a simple creation tool with all-optional params, this is nearly complete, lacking only parameter meaning and usage context.

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?

Four parameters with 0% schema description coverage, and the description mentions none of them (width, height, background_name, background_color). Only opaque defaults exist in the schema, so the description does not compensate for the coverage 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+resource: 'Create a new isolated artwork session and XCF working document.' The word 'isolated' hints at differentiation from session_open, but no sibling is named explicitly, so the boundary between this and session_open/session_list is left to inference.

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

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

No guidance on when to use this versus session_open or session_list, and no prerequisites or context are given. An agent must infer that this is the entry point for a fresh session.

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 disclose the key trait: it is non-mutating ("without modifying it"). It stops there, saying nothing about permissions, error behavior, or the freshness of the returned state.

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

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

A single front-loaded sentence covering verb, returned data, and the non-mutating constraint with no wasted words.

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

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

An output schema exists, so return values need not be explained, and for a one-param read-only tool the description covers purpose and safety. The missing alternatives guidance is a minor gap, not a blocking one.

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 should compensate. It scopes the identifier to an "artwork session," which gives session_id some meaning, but adds no format or origin detail. The generic param name carries most of the weight.

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

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

Specific verb ("Return") plus concrete resource (dimensions, layers, current XCF state) scoped to an artwork session. It clearly reads as an inspection tool distinct from session_list, though it does not name the sibling it differs from.

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?

"without modifying it" implies a read-only inspection use case, but the description never states when to reach for this over session_list, gimp_status, or session_open. No alternatives or preconditions are offered.

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 add useful context beyond the schema by noting that 'recovered' sessions are included and that undo depth is reported, which hints at the enumerable state, but it never states that this is a non-destructive read or describes scoping/filtering 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?

A single, front-loaded sentence with no filler; the verb and scope come first and the notable contents follow. Every clause earns its place.

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

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

For a parameterless list tool with an output schema present, the description need not explain return values, and the schema plus annotations carry most of the remaining weight. It is nearly complete, leaving only the sibling-routing question unaddressed.

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 the baseline of 4 applies; there are no parameter semantics to clarify beyond what the empty schema already conveys.

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

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

The description states a specific verb ('List') and resource ('active and recovered artwork sessions') and even enumerates the notable returned fields (preview paths, undo depth). It is clear what the tool does, but it does not differentiate itself from the closely named sibling 'session_info', which an agent could easily 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?

There is no statement of when to use this tool versus alternatives like session_info or session_open; usage is only implied by the word 'List'. With several session_* siblings that plausibly overlap in purpose, the absence of any routing guidance is a real gap.

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 disclose a meaningful behavioral trait: the file is opened into an isolated copy so source files are never edited in-place. But it omits session lifecycle, error behavior for a missing/invalid path, and persistence semantics, which matter given the surrounding session_* tools.

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 carrying the action, target, and the key safety benefit with no wasted words.

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

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

The presence of an output schema means return values need not be explained. Still, for a tool sitting among session_create/session_close/session_list, the description omits how the session must be managed afterward, leaving a notable lifecycle gap.

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

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

Schema coverage is 0% with one required 'path' parameter. The description only loosely compensates by implying path points to an existing image or XCF file; it adds no format, extension, or validation detail beyond that weak hint.

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+resource (open an existing image/XCF) plus the core behavior (isolated session copy). The word 'existing' implicitly separates it from session_create, but it never explicitly names or contrasts the sibling, 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?

Usage is implied: use this to load a file for editing rather than creating a new session. However, there is no explicit when-to-use/when-not guidance and no reference to the obvious alternative (session_create) or to the required follow-up (session_close), leaving lifecycle 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the snapshot-level scope, but not whether the operation mutates session state destructively, what happens on an empty redo stack, whether a new edit clears the redo history, or any permission requirements.

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 scope constraint front-loaded and zero filler. Nothing could be removed without losing meaning.

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

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

An output schema exists, so return values need no explanation, and the operation is low-complexity with one parameter. Still, for a state-mutating tool with no annotations, the session_id semantics and the empty-redo-stack behavior are gaps an agent would have to guess at.

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

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

Schema description coverage is 0% and there is one required parameter, session_id, whose meaning and accepted format the description never touches. With a coverage gap this large the description should compensate, and it 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?

Specific verb ("Redo") plus a scoped resource ("the last snapshot-level undo in this session"), which is far more than a restatement of the name. It implies the counterpart relationship to session_undo but never names it, so the sibling differentiation is left to inference.

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 "the last snapshot-level undo" hints the tool is only valid after an undo has occurred, but there is no explicit when-to-use, when-not-to-use, or alternative named. An agent gets no guidance on ordering or on what happens when there is nothing to redo.

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 scope ('last successful mutating operation') and mechanism ('session snapshot journal'), implying a one-step, journal-backed reversal. It omits failure behavior (what happens with no snapshot), whether the undo is itself reversible, and any auth or session-precondition requirements.

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 operative action and its scope appear immediately.

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

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

An output schema exists, so return values need not be explained, and the mutation's intent is clear. However, for a state-changing tool with no annotations and an undocumented session_id, the description should say more about preconditions and failure cases to be fully actionable.

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 the single required parameter session_id, and the description never mentions it or explains what value it takes (e.g., from session_create/session_list). Since the schema does not document the parameter, the description should have compensated and does not.

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