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

Annotations declare readOnlyHint=false and destructiveHint=false, so safety is largely covered. The description adds genuine behavioral facts beyond that: positioning defaults to centered when x/y are omitted, and scaling preserves aspect ratio when only one of width/height is given. It does not disclose layer ordering, failure modes, or where the new layer lands relative to existing ones.

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

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

Two compact sentences that lead with the core action and then layer in the positioning and scaling caveats. No filler or repetition, though the parenthesis-heavy style is slightly dense.

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

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

For an 8-parameter mutation tool with no output schema and no enum guidance, the description is thin. It addresses positioning and scaling but omits image_id (target image selection), name, and position semantics, leaving an agent unable to confidently populate most of the schema.

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

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

Schema description coverage is 0% across 8 parameters. The description clarifies only x/y (centering behavior) and width/height (optional scaling with proportion retention); image_id, name, and position are left entirely undocumented, and path is only implicitly obvious. Partial compensation that leaves half the parameters opaque.

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

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

States a specific verb and resource: inserts another image file (logo, photo) as a new layer. This is clearly distinguishable in intent from gimp_new_layer (empty layer) or gimp_duplicate_layer, though it never names those siblings. The purpose is unambiguous from the text alone.

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

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

Offers implied usage context via the default behavior ('sin x/y queda centrada') and the optional scaling mode, which help an agent anticipate outcomes. However, it gives no explicit 'use this when / instead of X' guidance and never routes the agent against gimp_new_layer or gimp_open_image.

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

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

Annotations already declare it is a non-readonly, non-destructive, non-openWorld operation. The description adds real behavioral context beyond that: (x,y) is the TOP-LEFT corner not the center, and the text is clipped if x+width/y+height exceed the image, plus a directive to verify this in the response.

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

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

Front-loads the purpose, then layers parameter and workflow detail in a tight run of sentences with no filler. Dense but each clause carries usable information.

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

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

For a 12-parameter mutation tool with no output schema, the description covers the two highest-risk pitfalls (coordinate semantics and clipping) and points to a resource-listing helper. It still leaves nearly half the parameters (spacing, color, justify, image_id) with no explanation, so it is 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% across 12 parameters, so the description must compensate. It clarifies the tricky ones (x/y coordinate convention, size in px, box_width for line wrapping, align values), but font, color, justify, line_spacing, letter_spacing, and image_id remain undocumented in both places.

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

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

States a specific verb+resource: 'Añade una capa de texto editable' (adds an editable text layer). Clear enough to act on, but it never distinguishes itself from the sibling gimp_edit_text, which operates on text too, so the agent must infer which tool applies to new vs. existing text.

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?

Offers practical guidance on how to reach goals (use align='center'/'center_x' to center, box_width to wrap) and points to gimp_list_resources('fonts') for font names. However, it gives no explicit when-to-use/when-not or routing vs. gimp_edit_text, so usage is only implied.

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

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

Annotations already declare this is a non-readonly but non-destructive mutation, so the safety profile is covered structurally. The description adds one genuinely useful behavioral detail — the operation respects the active selection — but says nothing about what happens when no layer/image is supplied, reversibility, or how the mutation is applied.

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

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

Front-loads the purpose, then uses a tight one-line-per-operation bullet list. It is long, but the length is earned by 15 distinct operations and their parameter contracts; there is little redundancy, though the mixed bullet/slash formatting is slightly harder to scan.

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/parameter mapping is thorough. The main gaps are image_id/layer_id targeting (how the agent points at a non-active layer) and whether omitted params mean defaults, but for a 15-operation adjustment tool it is complete enough to invoke 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?

With 0% schema description coverage across 21 parameters, the description carries the full burden and does so well: it groups parameters under each operation and supplies units and ranges (hue -180..180, saturation/lightness -100..100, gamma 0.1..10, posterize levels 2..256, temperature K with warm/cool semantics, curves as x1,y1,x2,y2 in 0..1). This is far beyond what the bare schema conveys and compensates almost entirely 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: color adjustments on the current layer, and adds the key scope qualifier 'respetando la selección'. An agent immediately understands this is the color-correction tool, distinct from siblings like gimp_set_colors or gimp_apply_filter, though it never names those alternatives explicitly.

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

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

The operation menu implicitly tells the agent what each call can achieve, but there is no explicit when-to-use/when-not guidance and no routing versus overlapping siblings (gimp_apply_filter, gimp_set_colors). Usage is inferable from the enumerated operations 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?

With annotations already covering the safety profile (destructiveHint=false), the description adds real behavioral context: it respects the current selection, and 'non_destructive=True lo deja como filtro editable en vez de fusionarlo con la capa' explains exactly whether the layer is modified destructively. This is the key operational nuance an agent needs.

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

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

Front-loads the purpose and the selection-respects note, then the examples and the non_destructive rule. The long filter catalog is verbose but each entry doubles as a usable operation/property example, so it largely earns its space.

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 annotations plus the description's non_destructive explanation adequately cover behavior for a mutation tool. The only real gap is the undocumented image_id/layer_id targeting behavior.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does for the two hard parameters: it enumerates example 'operation' values and shows the property shapes for many of them (e.g. gegl:gaussian-blur {std-dev-x, std-dev-y}). It also explains non_destructive, though image_id/layer_id semantics (e.g. defaulting to the active image/layer) remain 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+resource: 'Aplica cualquier filtro GEGL a una capa' (Applies any GEGL filter to a layer), with the scope qualifier 'respeta la selección'. It is clearly distinguishable from the info-only sibling gimp_filter_info and the adjustment sibling gimp_adjust.

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 clear usage context (applies a GEGL filter to the current/selected layer) and explicitly routes the agent to gimp_filter_info to discover a filter's properties. It stops short of stating when-not to use it versus alternatives like gimp_adjust or gimp_pdb_call.

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

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

Annotations already flag destructiveHint=true, and the description adds genuinely useful behavior beyond them: the tool refuses to close an image with unsaved changes unless discard_changes=True. This is the exact guard behavior an agent needs to avoid data loss. It does not mention permissions or what the response returns, but the safety semantics are 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?

Two tight sentences, with the core action front-loaded and the safety caveat immediately after. No filler; every clause earns its place.

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

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

With an output schema present, return values need not be explained, and the annotations plus the safety note cover the destructive nature of the operation. The only real omission is guidance on the image_id parameter and when to choose this over saving.

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

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

Schema coverage is 0%, so the description carries the burden. It explains discard_changes clearly (the flag that bypasses the unsaved-changes guard), but says nothing about image_id, which parameter identifies the target. Partial compensation 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?

"Cierra una imagen" states a specific verb (close) and resource (image), clearly distinguishing it from siblings like gimp_open_image and gimp_save_image. It stops short of naming an alternative or contrasting scope, 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 safety condition (fails on unsaved changes unless discard_changes=True) implies the workflow of saving first or explicitly discarding, but the description never states when to prefer this tool over alternatives such as gimp_save_image or gimp_export_image. Usage is implied rather than explicit.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the agent knows this is a non-destructive write. However, the description adds nothing beyond that: it does not disclose that converting RGB to grayscale or indexed can permanently discard color information, nor whether the change is reversible.

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

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

Two short sentences with the core action front-loaded and no wasted words. Efficient, though extremely terse given the tool's complexity.

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

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

A mutation tool with no output schema, 0% schema coverage, and an unexplained image_id parameter. It omits the key behavioral fact that mode conversion can lose color data, leaving an agent under-informed for a write operation.

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

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

Schema description coverage is 0%, so the description must carry the burden, but it only explains the `colors` parameter ('Para indexed, colors = nº de colores de la paleta'). The `image_id` parameter is entirely undocumented, and `mode` relies solely on its enum 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?

States a specific verb and resource: 'Convierte el modo de color de la imagen' (converts the image's color mode). An agent can distinguish this from siblings like gimp_adjust or gimp_set_colors, though no sibling is named explicitly.

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

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

Provides no when-to-use guidance, no prerequisites, and no mention of alternatives among the many siblings that touch image properties. The single sentence about indexed colors is a parameter hint, not usage direction.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows the safety profile. The description adds the crop-mode context but omits that cropping discards pixels outside the region and says nothing about how image_id selects the target image.

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

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

A single sentence that is front-loaded with the verb and then branches into the three modes. No filler, though the parenthetical lists make it slightly dense.

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

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

For a 7-parameter tool with 0% schema coverage and no output schema, the description covers most parameters well but leaves image_id undefined and does not clarify mode exclusivity or interaction (e.g., what happens if x/y are omitted while to_selection is false).

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it names and explains six of the seven parameters (x, y, width, height, to_selection, autocrop) with their roles. Only image_id is left unexplained, a minor gap against a 0% baseline.

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

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

States a specific verb (recorta/crop) and resource (imagen/image) and enumerates three distinct crop modes. It is distinguishable from siblings like gimp_resize_canvas and gimp_scale_image, though it does not explicitly name them as alternatives.

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

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

The three modes (rectangle, to_selection, autocrop) imply how each is triggered, but there is no explicit when-to-use guidance, no statement about which mode takes precedence, and no mention of prerequisites such as needing an active selection or open image.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered by structured data. The description adds nothing on top of that: no undo semantics, no confirmation requirement, no statement about what happens to the layer content or the image stack.

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 padding, which is structurally fine, but the brevity is under-specification rather than efficiency — the sentence carries no operational detail an agent needs.

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

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

The tool itself is simple and annotations plus an output schema offload some burden, but with 0% parameter coverage and no guidance on sourcing the layer_id or the effect on the layer stack, the definition is not 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 description coverage is 0% and the sole parameter (layer_id) is not mentioned at all in the description. With no schema documentation to lean on, the description should explain how a layer_id is obtained (e.g., via gimp_list_images or layer listing) but does not. Only the self-explanatory parameter name prevents a lower score.

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 pair ("Elimina una capa") is unambiguous and the destructive verb separates it cleanly from siblings like gimp_new_layer, gimp_duplicate_layer and gimp_merge_layers. It is however extremely terse and says nothing about which layer or the scope of deletion.

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, or alternative routing is given. An agent cannot tell from the description whether to delete vs merge/duplicate, or whether this requires an active image context. It is a bare statement of function.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds the useful 'closed=True returns to the first point' behavior, but says nothing about which layer/image is mutated by default, undo implications, or whether color/opacity/size come from current context.

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

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

Two tight sentences; the point-format explanation is front-loaded and the closed behavior follows. Nothing is wasted, though the language does not match the surrounding English toolset.

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 core geometry is described. However, for an 8-parameter mutation tool with zero schema documentation, the omission of layer/image target defaults and the drawing attribute parameters leaves real gaps.

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

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

Schema coverage is 0% across 8 parameters, so the description carries the burden. It does document the two most critical semantics: the flat x1,y1,x2,y2 point format and closed=True. Size, color, opacity, image_id, and layer_id remain completely undefined in both description and 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+resource ('pinta un trazo') plus the geometry model (points list in image coordinates), which separates it from siblings like gimp_fill or gimp_gradient. It does not explicitly name what it is not, 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?

No when-to-use, when-not-to-use, or alternative is given. An agent must infer that this is for freehand/polyline painting rather than selection stroking (gimp_stroke_selection) or filling (gimp_fill).

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, and the description is consistent, adding that layers are carried over into the new image. It does not disclose the key behavior that image_id is optional, i.e. what happens when it is omitted (default to active image?).

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 parenthetical '(con capas)' efficiently conveys the copy semantics. No structural issues beyond its brevity.

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

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

For a one-parameter tool with no output schema the description is nearly adequate, but it omits what image_id defaults to and whether the duplicated image becomes the active/target image, which an agent needs to chain subsequent calls.

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 description never mentions image_id, whether it is optional, or its default of null. With one undocumented parameter and no schema descriptions, 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 (duplicate a full image, layers included, into a new image), which implicitly separates it from gimp_duplicate_layer. It does not name a sibling explicitly, so an agent must infer the distinction, but the scope is clear.

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 explains when to duplicate a whole image versus creating one with gimp_new_image or copying a single layer with gimp_duplicate_layer. Usage is only implied by the tool name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds the placement behavior (duplicate sits directly above the original), but says nothing about the created layer's default naming, whether the original is untouched, or what is returned.

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

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

A single short sentence with the core action front-loaded and the placement detail in parentheses; nothing is wasted. It is arguably too terse for a tool with an undocumented parameter, but structurally it is efficient.

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

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

With no output schema and no annotation-derived detail, the description should tell the agent what the duplicated layer is called, whether it becomes selected, and what the call returns. None of that is present, so the definition is not sufficient on its own.

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 carries the full burden, yet it explains neither the required layer_id (which layer is targeted) nor the optional name parameter (does it rename the duplicate?). This leaves the second parameter's meaning entirely 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+resource ('Duplica una capa') and adds the placement result, so the agent knows exactly what operation runs. It does not explicitly differentiate from close siblings like gimp_new_layer or gimp_duplicate_image, but the verb 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 duplicate versus creating a new layer or copying via other means, and no prerequisites or context conditions are given. Usage must be inferred from the tool 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?

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it doesn't say which attributes get modified, that omitted parameters probably leave existing values untouched, or whether the edit is undoable. It merely restates 'modify' with no operational context.

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

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

A single front-loaded sentence with no filler, but it is concise only because it is under-specified; there is no second sentence earning its place with required 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 6-parameter mutation tool with no output schema and zero schema description coverage, the description is far too thin — an agent cannot learn from it which fields are editable, what the enum options for justify mean, or what the tool returns.

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

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

Schema description coverage is 0% across 6 parameters, so the description must compensate and does not — it never mentions font, size, text, color, or justify, nor explains that only layer_id is required and the rest are optional overrides.

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 clear verb ('Modifica') and resource ('una capa de texto existente'), which distinguishes it from the sibling gimp_add_text (creates text). It does not explicitly name that sibling, but the create-vs-edit distinction is 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?

No guidance on when to use this instead of gimp_add_text or gimp_set_layer, no prerequisites (does the layer need to already be a text layer?), and no mention of what happens if the layer_id points to a non-text 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?

Annotations declare destructiveHint=true/readOnlyHint=false, and the description adds genuinely useful context beyond them: that the format is auto-detected from the extension, the quality scale (1-100) and which formats it applies to, and that flatten operates on a copy so the original image is untouched. It doesn't mention whether an existing file is overwritten, but the added behavioral detail is solid.

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

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

Two tight sentences, front-loaded with the core action and followed by the parameter-relevant details. The parenthetical format list is slightly long but functional; no wasted prose.

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

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

An output schema exists, so return values need no explanation, and the mutation profile is covered by annotations. The remaining gap is image_id, which is undocumented in both schema and description, leaving the agent unsure how a target image is identified for a 4-parameter export tool.

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

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

Schema description coverage is 0%, so the description must carry the load, and it documents three of four parameters well: path (format via extension), quality (1-100, jpg/webp), and flatten (joins layers on a copy). image_id is left entirely unexplained, which is the only meaningful 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 clear verb+resource ('Exporta la imagen') and specifies that the target format is inferred from the file extension, listing supported formats. However, it never distinguishes this from the closely related sibling gimp_save_image, so the agent must infer the export-vs-save boundary itself.

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

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

The description explains mechanics (format by extension, quality range, flatten-on-copy) but gives no when-to-use guidance and never names an alternative. With gimp_save_image present as a near-twin sibling, the absence of 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?

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the write/non-network profile is already covered. The description usefully adds the selection-vs-whole-layer scoping rule, but says nothing about whether existing pixels are overwritten or the operation's irreversibility. Nothing here contradicts the annotations.

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

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

Two compact sentences with the primary behavior (what gets filled) front-loaded and the parameter values following. No wasted text; the only minor issue is that the fill-value list is dense inside the second sentence.

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

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

An output schema exists, so return values need no explanation. Still, for a 3-parameter tool at 0% schema coverage, the description omits how image_id/layer_id resolve (defaults, active image/layer behavior), which an agent needs in order 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?

Schema description coverage is 0%, so the description carries the burden. It does enumerate the accepted fill values including the missing enum (foreground, background, white, transparent, pattern, hex color), which is genuinely useful. But image_id and layer_id are left completely unexplained, so the compensation is only partial.

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/rellena) and the exact resource affected: the current selection, or the whole layer when no selection exists. It is unambiguous about what the tool does, though it does not name any sibling to differentiate itself from tools like gimp_draw, gimp_gradient, or gimp_stroke_selection.

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

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

The parenthetical '(o la capa entera si no hay selección)' implicitly defines the operating context and the fallback behavior when no selection exists. However, there is no guidance on when to prefer this over related painting tools (draw, gradient, stroke) and no prerequisites stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds genuinely useful behavior beyond that: the two-mode branching and the fact that the detailed mode returns name/type/default/range/description. It does not mention result size, pagination, or cost of a broad query, so it goes modestly past the annotations without being rich.

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

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

Two short sentences, front-loaded with the mode distinction, zero filler. Each clause maps to a distinct parameter behavior, so every sentence earns its place.

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

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

For a two-optional-parameter read-only query tool with no output schema, the description supplies the mode logic, the filter semantics, and a partial inventory of the returned fields. The remaining gap is error/empty-result behavior and the fact that `query` and `operation` are mutually weighted, but nothing essential to invoking it correctly is missing.

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

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

Schema description coverage is 0%, so the description must carry the parameters, and it largely does: `query` is a substring filter over available GEGL operations, and `operation` is the selector that switches the call from listing to property introspection. This compensates well for the empty schema titles, though it doesn't state that both are optional or what happens with an unmatched query/unknown operation.

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

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

The description names a specific verb and resource: it lists GEGL operations filtered by `query`, or, when `operation` is supplied, displays that operation's properties (name, type, default, range, description). This is clearly distinguishable from CRUD siblings like gimp_open_image or gimp_delete_layer, though it never explicitly contrasts itself with near neighbors such as gimp_pdb_search or gimp_apply_filter.

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 does describe the two internal modes and the condition that selects each (`operation` present vs absent), which is real usage guidance for the tool itself. However, it gives no guidance on when to reach for this tool instead of the related discovery tools (gimp_pdb_search, gimp_pdb_info, gimp_list_resources), so alternative selection is left 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?

Annotations declare a non-readonly, non-destructive write operation, but the description does not clarify which image layer is affected, whether it operates on the active layer, or any side effects. It only explains color defaults, leaving key behavioral context unstated.

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 succinct sentences with the core action front-loaded and default behavior explained efficiently. No wasted words, though it could better structure the parameter hints.

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

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

For an 11-parameter mutation tool with no schema descriptions and an output schema, the description is too thin. It omits target image/layer context, shape options, reverse flag, and any indication of where the gradient is applied.

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 11 parameters. The description mentions x1, y1, x2, y2, start_color, end_color, and gradient, but omits shape, reverse, image_id, and layer_id entirely, so it fails to compensate for the schema's lack of descriptions.

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 ('Rellena') and resource ('degradado') with coordinate endpoints, clearly distinguishing it from a solid fill. Does not name the sibling tool (e.g., gimp_fill) it should be chosen over, but the gradient focus is evident.

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

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

Describes default color behavior (start_color→end_color or foreground→background) and the 'gradient' parameter for named GIMP gradients. No explicit when-to-use vs. alternatives like gimp_fill; usage is implied by the gradient 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?

Annotations already declare a safe, read-only, non-destructive, closed-world operation, so the safety profile is covered. The description does add what fields come back, which is useful. However, it does not explain the parameter's default (image_id null presumably meaning the active image) or any failure mode.

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 lists exactly the returned fields with no padding or redundancy. Efficient, though it could carry one more clause on the id parameter without bloating.

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

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

With no output schema, the field enumeration usefully describes the return payload, and the read-only annotations cover safety. But the omission of image_id's default/active-image semantics leaves a meaningful gap an agent needs to call it correctly.

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

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

Schema description coverage is 0% and the single image_id parameter is never mentioned. Crucially, the nullable default of image_id is undocumented, so the agent can't tell that omitting it targets the active/current image, leaving a real semantic 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?

Names a specific resource and enumerates the returned detail (size, mode, resolution, selection, layer tree with ids), so the agent knows exactly what the tool produces. It doesn't distinguish itself from related introspection siblings like gimp_status, gimp_filter_info, or gimp_pdb_info, but the verb+resource+content list is clear.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no routing away from alternatives such as gimp_list_images or gimp_status. The agent must infer the call 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?

The description explicitly states that apply 'elimina la máscara' (removes the mask) and remove 'la descarta' (discards it), i.e. non-additive, destructive updates. The annotations declare destructiveHint=false, which per MCP means 'only additive updates'. The description therefore contradicts the annotation's safety profile, which is exactly the kind of mismatch that risks an agent discarding a mask without caution.

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

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

A single dense sentence with the resource front-loaded and the three actions listed in parallel parentheticals; no filler. It is arguably over-packed (the parentheticals mix both action and mask_type semantics), and the description is written in Spanish while the surrounding tool ecosystem is English, which slightly hurts scanability.

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

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

With no output schema and 0% schema description coverage, the description should carry more of the burden than it does. It covers action and mask-type semantics but omits prerequisites (the target layer must exist; mask_type=selection requires an active selection) and says nothing about what the tool returns or the state of the layer afterward.

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

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

Schema description coverage is 0%, so the description must carry the parameter meaning, and it largely does: it disambiguates the mask_type values (white=all visible, black=all hidden, selection=from the active selection) and ties the action enum to concrete effects. Only layer_id and the bare 'alpha/copy/grayscale' values are left unexplained, but layer_id is self-evident.

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

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

The description names the resource ('Máscaras de capa') and enumerates the three operations (add/apply/remove) with a gloss of each, so an agent can tell it creates, bakes, or discards a layer mask. It is a specific verb+resource. It does not, however, contrast itself with siblings like gimp_set_layer or gimp_select, so it stops 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?

The glosses on add/apply/remove imply which action to choose for a given goal (create vs. bake-in vs. discard), which is useful. But there is no explicit when-to-use guidance against alternative tools, no prerequisites (an existing layer, an active selection for mask_type=selection), and no when-not-to-use note.

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

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

Annotations declare a non-read-only, non-destructive mutation, so safety is partly covered. The description adds the semantics of each action (raise/lower move one step, position 0 = top), which is useful behavioral context, but says nothing about what happens to sibling layers or the resulting stack 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 with no filler; the action taxonomy is packed compactly. Dense but readable, and every clause carries 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?

With no output schema and no per-parameter documentation, the description covers the action space reasonably but leaves the required layer_id and the expected result/return unaddressed. Adequate for a simple reorder tool, but gaps remain 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%, so the description carries the burden. It partially compensates by explaining the action enum values and clarifying that position 0 means top, but layer_id (a required integer) is left entirely undocumented in both schema and description.

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

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

States a specific verb ("Mueve") and resource ("capa") plus the stack-reorder scope, with the action variants enumerated. An agent can distinguish it from layer-creation/edit siblings like gimp_new_layer or gimp_set_layer, though no sibling is named explicitly.

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

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

Implies usage through the action names (raise/lower one step, top/bottom, absolute position), but never states when to prefer this tool over alternatives such as gimp_set_layer, nor any prerequisites like having a layer selected.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds value by listing the fields returned, but says nothing about ordering, pagination, or behavior when no images are open.

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 waste; the parenthetical field list earns its place by describing the return payload in the absence of an output schema.

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

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

For a zero-parameter read-only listing tool with annotations carrying the safety profile and no output schema, the description is sufficient. It discloses the returned fields, which is the main thing an agent needs here.

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?

This tool takes zero parameters, so the baseline is 4. The description correctly adds nothing about parameters and instead describes the response shape, which is the only useful semantic content available.

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 ('Lista las imágenes abiertas en GIMP') and even enumerates the returned fields (id, nombre, archivo, tamaño). It is clearly distinguishable from mutation siblings like gimp_open_image or gimp_close_image, though it does not contrast itself with the overlapping gimp_image_info.

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, no prerequisites, and no routing to alternatives such as gimp_image_info for details on a single image. The agent must infer usage purely from the name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that listing is scoped to resource kinds and text filtering, but says nothing about pagination via limit or what a returned entry looks like.

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, resource, scope, and filter mechanism all appear before any trailing 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?

For a read-only listing tool with annotations covering safety and no output schema, the description is serviceable but thin: limit behavior and the shape of returned resources are undocumented, and the Spanish-only text may not match the English tool naming convention.

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

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

Schema description coverage is 0%, so the description must carry the load. It clarifies the text-filter semantics of query and the resource scope of kind (though that largely repeats the enum), but leaves limit, the pagination control, entirely unexplained.

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

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

States a specific verb and resource ('Lista recursos de GIMP') and enumerates the resource kinds, which cleanly separates it from gimp_list_images and gimp_pdb_search. It does not explicitly name a sibling, so it stops 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 gives no when-to-use context, no prerequisites, and no alternatives. An agent can infer that this is a discovery step before e.g. gimp_add_text or gimp_gradient, but nothing in the text says so.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds one real behavioral detail — flatten collapses everything 'sin transparencia' — but never states irreversibility or that source layers are consumed.

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 verb front-loaded and the three modes enumerated compactly. No filler or repetition, though it could consolidate the mode semantics more tightly.

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

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

For a destructive, multi-mode operation with zero schema description coverage and no output schema, the description leaves key gaps: the role of image_id/layer_id, what happens to the unselected layers, and any prerequisites are all absent.

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

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

Schema coverage is 0%, so the description must carry the load. It does explain the required 'action' enum meaningfully, but image_id and layer_id are never mentioned, and it is not stated which layer merge_down/merge_visible operate on relative to those ids.

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

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

The description names a specific verb+resource ('Combina capas') and then decomposes the three modes (merge_down, merge_visible, flatten) into concrete outcomes, so an agent can immediately tell this apart from other layer tools like gimp_layer_order or gimp_delete_layer.

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 per-mode parentheticals let the agent pick the right action, but there is no guidance on when to reach for this tool versus siblings, no preconditions (does it require an open image / active layer?), 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?

Annotations already declare destructiveHint=false and openWorldHint=false, so the safety profile is partly covered. The description adds real behavioral meaning beyond that: units (px) for grow/shrink/border, feather radius, and that sharpen removes blur — but it does not say what happens when no selection exists or whether the modification applies to the whole 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 tight sentence with the operation list front-loaded after the verb; nothing is padded. It is terse to the point that it drops potentially useful clauses, but it is not bloated.

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

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

With no output schema and a mutation that touches the current selection, the description covers the operations and their units but omits image_id, the default amount, and what happens absent a selection. Adequate but with clear holes for a 3-parameter write 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: it names the five 'action' values and gives units for 'amount' (px for grow/shrink/border, radius for feather), which is genuine added meaning. The third parameter, image_id, is never mentioned, and the default amount of 5 is not explained.

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

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

Specific verb ('Modifica') + resource ('la selección actual') plus an enumeration of the five operations it performs. An agent can tell it acts on the selection rather than building one, but the description never contrasts it with gimp_select or gimp_stroke_selection, which operate on the same resource.

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

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

No statement of when to use this tool versus the selection-related siblings (gimp_select, gimp_select_by_color, gimp_stroke_selection), nor any prerequisite such as an active selection existing. The action list implies usage but gives no selection conditions.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds no behavioral context such as whether the new image becomes active, whether it consumes resources, or what happens on invalid dimensions, so it contributes little beyond the annotations.

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

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

Two short sentences with the core action front-loaded and no filler. The second sentence is a terse fragment, but it still earns its place by clarifying the background parameter values.

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 creation tool with 0% schema coverage, no output schema and no annotation detail, the description is too thin: units for width/height, valid mode semantics, the meaning of the default name 'Capa base', and whether the resulting image id is returned are all 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%, so the description carries the full burden. It only explains the 'background' parameter and partially at that (a color, or the keywords 'transparent', 'foreground', 'background'), leaving width, height, mode and name completely undocumented. It 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 ('Crea una imagen nueva'), which is unambiguous and clearly distinct from siblings like gimp_open_image or gimp_new_layer. It does not, however, explicitly name those alternatives or clarify scope (canvas vs. document).

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 gimp_open_image (existing file) or gimp_new_layer (adding a layer to an existing image). The agent must infer the context 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?

Annotations already declare it a non-destructive write operation (readOnlyHint=false, destructiveHint=false), lowering the bar. The description adds useful context on group creation, position origin, and parent placement, but omits prerequisites such as needing a target/open image (image_id defaults to null) and what happens to the current selection.

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, front-loaded clauses with no waste, and the create-vs-group distinction leads. Slightly fragmentary in style but every sentence contributes information.

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

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

For a 12-parameter creation tool with no output schema and 0% schema coverage, the description covers too little: no defaults, no return behavior, no defaults for width/height/opacity, and no indication of which image is targeted. It is not sufficient on its own to call the tool confidently.

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

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

With 0% schema description coverage across 12 parameters, the description carries the full burden but only explains 4 of them (group, fill, position, parent_id). The remaining 8 (x, y, mode, name, width, height, opacity, image_id) are undocumented in both schema and description, leaving significant gaps.

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 ('Crea una capa') and clarifies the group-vs-layer branch via group=True. It does not differentiate itself from close siblings like gimp_add_layer_from_file or gimp_duplicate_layer, which an agent could easily confuse with this.

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 create a new layer versus adding from a file, duplicating, or setting an existing layer. The mention of group=True and parent_id implies usage but never states conditions or prerequisites (e.g., an open image).

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 annotation readOnlyHint=false already signals that this call mutates state, and the description adds that it 'returns info'. However, it does not explain the key behavioral trait beyond annotations: that opening loads the file into GIMP as the active image, nor what 'info' contains. With annotations covering the safety profile, a 3 is appropriate.

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 waste; the format enumeration is the one piece of added information and is placed inline rather than padding.

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

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

With no output schema, the description's claim to 'return info' is the only pointer to return values, and it is undefined. For a one-parameter tool with minimal annotations this is minimally adequate but leaves an agent guessing about the response payload.

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

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

Schema coverage is 0%, so the description must carry the path parameter's meaning. Listing the supported extensions does add value about acceptable formats, but it never clarifies whether path is absolute/relative or how it interacts with GIMP's file handling, so it only partially compensates.

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 (abre/opens) and resource (archivo de imagen) and enumerates the supported formats, which is concrete and helps an agent recognize the operation. It does not explicitly distinguish itself from siblings like gimp_new_image, gimp_image_info, or gimp_add_layer_from_file, so differentiation is only implied.

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 tool over gimp_new_image (create), gimp_add_layer_from_file (add to existing), or gimp_image_info (query). The supported-format list hints at scope but no prerequisites, alternatives, or exclusions are stated.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, so safety is partly covered. The description adds real behavioral context beyond that: 'run-mode' defaults to NONINTERACTIVE (no dialogs), special placeholder substitution rules, and how file/color values are interpreted. It does not warn about side effects of arbitrary procedures, but the added semantics are substantive.

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

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

Front-loaded with the core purpose, then a compact semicolon-delimited list of special-value rules. Dense but every clause carries information; the parenthetical special-value list is slightly hard to parse but nothing is wasted.

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

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

For a tool that can invoke any PDB procedure, with no output schema and 0% parameter description coverage, the description covers the key input conventions but says nothing about return format, error behavior on unknown procedure names, or how results come back. Adequate but with clear gaps for such an open-ended tool.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does: it maps image_id to 'image', layer_id to 'drawable'/'drawables', and describes the named-arguments object and file/color value formats. The 'arguments' object and 'name' semantics are only implied rather than spelled out, leaving a small 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: 'Llama a cualquier procedimiento PDB por nombre con argumentos por nombre.' An agent can tell this is the generic escape-hatch for arbitrary PDB procedures, distinct from the many task-specific siblings like gimp_draw or gimp_fill. It stops short of explicitly framing itself as the fallback when no specialized tool exists, which keeps it from a 5.

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

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

The only routing guidance is 'Consulta antes gimp_pdb_info' (check gimp_pdb_info first), which is a useful discovery step. It never states when to prefer this generic call over the dozens of purpose-built sibling tools, nor any when-not-to-use condition, so usage is only implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is largely covered. The description adds one useful behavioral fact, that it returns both argument and return-value details, but says nothing about lookup failure behavior for unknown procedure names.

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 no filler and the core action front-loaded. It is short rather than padded, though it is arguably under-specified rather than genuinely 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?

For a one-parameter introspection lookup with rich annotations but no output schema, the description conveys the returned content adequately. It still omits the name format and any routing versus gimp_pdb_search/gimp_pdb_call, and it is written in Spanish while every sibling is English, which is a mismatch an agent must reconcile.

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 the required 'name' parameter. It never states whether the name should be a fully-qualified PDB procedure identifier (e.g. 'plug-in-foo') or a display name, so the agent must guess the 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?

States a specific verb ('Muestra') and resource ('argumentos y valores de retorno de un procedimiento PDB'), so an agent can tell it introspects a procedure rather than calling or searching one. It does not explicitly distinguish itself from siblings like gimp_pdb_search, gimp_pdb_call, or gimp_filter_info, which keeps it 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 when-to-use guidance, no prerequisites, and no named alternative. The obvious use case (inspect a procedure's signature before invoking gimp_pdb_call) is left entirely 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safe-read profile is covered by structured data. The description adds useful scope information (plugins and Script-Fu are included) but omits anything about result size, the limit default of 50, or pagination 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 no filler and the resource front-loaded before the qualifier. It earns its place, though it is arguably too terse for a tool with two undocumented parameters.

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

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

For a low-complexity read tool with safety annotations and no output schema, the description covers the essentials of what is searched. It falls short on the limit parameter, matching semantics, and how results should be fed into gimp_pdb_call/gimp_pdb_info, which an agent would likely need.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. 'por nombre' loosely explains the required query parameter but says nothing about matching semantics (substring, regex, case sensitivity), and the limit parameter is left entirely undocumented in both schema and description.

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

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

States a specific verb (Busca) and resource (procedimientos de la PDB de GIMP) and even scopes the search space to include plugins and Script-Fu. It does not, however, explicitly distinguish itself from the sibling tools gimp_pdb_info and gimp_pdb_call, leaving the agent to infer the search-vs-inspect-vs-invoke distinction.

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 tool versus gimp_pdb_info or gimp_pdb_call, which are clearly part of the same workflow. The only usage signal is implicit in the word 'Busca', so the agent gets no routing guidance for the discovery-then-invoke pattern.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds that output is a PNG and that a single layer can be targeted, but says nothing about how the preview is delivered or what max_size does. Adequate but not rich.

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

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

Two short sentences, both earning their place: the first states the output, the second gives the trigger. Front-loaded with the core purpose and no filler.

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

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

There is no output schema, so the description should explain the return shape — file path, base64, or inline image content — since an agent cannot act on a PNG preview without knowing how it arrives. Combined with 0% schema description coverage on max_size, the definition is under-specified for a 3-parameter tool.

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

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

Schema description coverage is 0%, so the description must carry the burden. It clarifies the image-vs-layer distinction implied by image_id/layer_id, but leaves max_size (default 1024, a meaningful control over preview resolution) completely unexplained. Two of three parameters get only indirect 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: returns a PNG preview of the image, or of a single layer. This is clearly distinguishable from metadata-only siblings like gimp_image_info, though the description never names a sibling explicitly.

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

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

Gives clear timing guidance: 'use it after every important change to check it came out well', which tells the agent when to reach for this tool in an editing workflow. It lacks explicit when-not-to-use or named alternatives (e.g., versus gimp_image_info), so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is partially covered. The description adds useful behavior beyond them: new canvas area defaults to transparent unless 'fill' is supplied. It does not address permissions, reversibility, or how existing layers are affected.

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, no filler, and the core purpose is front-loaded before the 'fill' detail. 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?

With no output schema and 0% schema coverage across 5 params, the description is too thin: it never explains the anchor enum (which determines where content sits when canvas grows/shrinks) or image_id. An agent could resize but would be guessing about anchoring and targeting.

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 5 parameters, so the description must carry the load. It explains only 'fill' (color to fill new space), leaving width, height, anchor, and image_id completely undocumented despite anchor being an important behavioral control.

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 ('Cambia el tamaño del lienzo') and adds the critical qualifier 'sin escalar el contenido', which contrasts with the sibling gimp_scale_image. It is clear, though it does not explicitly 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?

Usage is only implied: 'sin escalar el contenido' hints that this is the tool to choose when the pixel content should not be resampled, but there is no explicit when-to-use statement or named alternative such as gimp_scale_image or gimp_crop.

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

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

Annotations already declare a mutating (readOnlyHint=false) but non-destructive operation, and the description usefully adds that the whole image is affected and that rotation is clockwise, which the enum alone does not convey. It does not disclose undoability, what happens when image_id is omitted, or interaction between simultaneous rotate+flip.

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 operation and its key qualifier (clockwise, entire image) come first. It is very terse, but nothing in it is wasted.

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

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

For a 3-parameter tool with no output schema, the description covers the core behavior and rotation direction but leaves image_id semantics (which image is targeted when null) and flip-axis meaning undocumented in both schema and description.

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

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

Schema coverage is 0%, so the description carries the burden. It partly compensates by clarifying the clockwise rotation sense and the allowed angles, but 'voltear' never explains horizontal vs vertical flip and image_id is not mentioned at all.

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

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

The description states a specific verb pair (rotate/flip) and resource (the entire image), plus the allowed angles and clockwise direction. 'Imagen entera' implicitly separates it from layer-level siblings like gimp_transform_layer, but no sibling is named explicitly.

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

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

Usage is only implied: 'entera' signals whole-image scope, which hints at when to prefer this over gimp_transform_layer, but there is no explicit when/when-not guidance, no mention of combining rotate and flip in one call, and no prerequisites.

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

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

Annotations already disclose destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that variables persist between calls and that helpers exist, but does not elaborate on what code can destroy or permission requirements; with annotations present, a 3 is appropriate.

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

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

Front-loaded with the core action and environment; the helper list is dense but each entry is functional. There is no redundant filler, though the helper list could be formatted more scannably.

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

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

For a destructive, arbitrary-code-execution tool with no output schema, the description covers the execution environment and result handling but omits when to prefer this over specific GIMP tools, safety caveats about irreversible changes, and error behavior. Adequate but 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 coverage is 0% and the single 'code' parameter has no description in the schema. The description compensates by listing imported APIs, available helpers, the `result` assignment, and persistence, which meaningfully informs what the code string can contain. It still lacks syntax examples or constraints, so 4 rather than 5.

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 ('Ejecuta') and resource ('código Python') plus the execution environment and available helpers, clearly identifying it as an arbitrary scripting tool. It does not explicitly contrast with the many sibling tools (e.g., gimp_pdb_call), so a 4 rather than 5.

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

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

Provides no when-to-use or when-not-to-use guidance; it only lists environment details and helpers. The agent must infer that this is an escape hatch for operations not covered by dedicated tools.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the bar is lower. The description adds real context: it saves with layers preserved and, when no path is given, overwrites the current .xcf file, which directly explains the destructive behavior. It stops short of describing permissions or failure modes.

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 clauses, front-loaded with the format/action before the no-path behavior. No wasted words, though it is fragmentary rather than fully structured.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The main gap is the unexplained image_id parameter and lack of explicit contrast with the export sibling for an operation that can overwrite files.

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

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

Schema description coverage is 0%, so the description must carry the load. It explains the path semantics (null path = overwrite current file) but says nothing about image_id, leaving one of two parameters completely 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 and resource ('Guarda en formato XCF de GIMP') and its scope: saved as XCF with layers. This distinguishes it from the export sibling by format, but it does not name or explicitly contrast with gimp_export_image, so an agent must infer the distinction.

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

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

It implies the usage context ('Sin path, guarda sobre su archivo .xcf actual') but never states when to choose this over gimp_export_image for saving to other formats. The guidance is inferred rather than explicit.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false), so the bar is lower. The description usefully adds the aspect-ratio-preservation behavior, but says nothing about the default interpolation (cubic) or that rescaling resamples pixel data irreversibly.

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; the core action is front-loaded and the parameter guidance follows immediately. Nothing is redundant with the schema.

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

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

This is a mutating image operation with 5 undocumented parameters, no output schema, and no annotation detail beyond safety flags. Missing image_id semantics (is it optional? which image is default?), the meaning of each interpolation mode, and any statement about the effect on the existing image.

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 carries the full burden and only partially meets it. It clarifies the width/height/percent relationship and aspect-ratio fallback, but image_id and interpolation are completely unexplained, and no defaults are mentioned.

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 ("Escala la imagen entera") with the scope qualifier "entera", which implicitly separates it from canvas-only operations like gimp_resize_canvas. It does not name any sibling explicitly, so an agent must infer the boundary itself.

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

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

The description explains how to drive the tool (width and/or height, aspect ratio preserved when one is missing, or percent), which is implied invocation guidance. It gives no when-to-use / when-not-to-use direction against gimp_resize_canvas, gimp_crop, or gimp_rotate_flip_image.

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

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

Annotations already declare the mutating-but-non-destructive profile, so the bar is lowered. The description goes beyond them by explaining that 'operation' combines with the prior selection and that 'feather' blurs the edge in pixels, which is genuine state-interaction context not available from annotations.

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

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

Front-loaded with the purpose, then a dense, well-organized parameter map with no filler sentences. It is compact for the amount of information it conveys, though the run-on shape listing could be slightly cleaner.

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

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

For an 11-parameter, no-output-schema tool the description covers most of what an agent needs: the shape modes and their required coordinates plus the combination operation. It falls short on image_id (context selection) and the all/none/invert shape behaviors, which are the main omissions.

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

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

Schema description coverage is 0%, so the description must carry the weight, and it largely does: it maps x/y/width/height/radius to the geometric shapes, explains points as a flat coordinate list, ties from_alpha to layer_id, and defines operation and feather semantics. It omits image_id and the all/none/invert shape values, leaving a few gaps.

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 (crea/modifica) and resource (la selección), so the core function is unambiguous. It does not, however, differentiate itself from overlapping siblings such as gimp_modify_selection or gimp_select_by_color, which an agent could easily confuse 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?

Usage is only implied through the per-shape parameter breakdown; there is no explicit statement of when to use this tool versus gimp_modify_selection, nor any prerequisite or exclusion. An agent can infer intent from the shape list but must decide scope on its own.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is partly covered. But the description omits the most behaviorally important fact: the 'operation' parameter (replace/add/subtract/intersect) determines whether the existing selection is destroyed or combined, and nothing about scope (whole image vs. layer, sample_merged) 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?

Very short and front-loaded, with no wasted sentences. The terseness comes at the cost of completeness rather than being elegant brevity.

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

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

A 9-parameter, selection-mutating tool with no output schema and 0% schema coverage needs considerably more explanation than three abbreviated sentences, particularly around the operation enum and image/layer targeting.

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

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

Schema coverage is 0% across 9 parameters, so the description carries the full burden. It explains only threshold (0-255), contiguous, and the color vs. x,y distinction, leaving operation, sample_merged, image_id and layer_id entirely unaddressed in both schema and description.

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

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

The description states a specific verb+resource ('Selecciona por color') and usefully distinguishes two invocation modes (by color vs. by x,y magic wand). However it never differentiates itself from close siblings like gimp_select or gimp_modify_selection, so an agent cannot tell when this is the right selection tool.

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

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

It gives conditional guidance for the two input modes ('Con color...' vs 'Con x,y...'), which is genuinely helpful. It stops short of any when-to-use vs. alternatives guidance relative to the many selection-related siblings.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact not in the annotations: the dual setter/getter mode with no arguments. It omits any auth, scope, or state-affecting detail (e.g. whether the change persists across images).

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

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

Two compact sentences with the setter behavior front-loaded and the no-argument read behavior appended. Nothing is wasted, though the field list is a bare enumeration rather than a prioritized summary.

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

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

No output schema exists, and the description does note the no-arg return of current values. Still, for a six-parameter tool with zero schema documentation, the missing value formats and paint-mode options leave an agent guessing at correct inputs.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It names all six fields (foreground, background, brush, brush_size, opacity, paint_mode), which is real compensation, but adds no format guidance: color string syntax, opacity range, or valid paint-mode values remain 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 (ajusta) and resource (contexto de pintura) and enumerates the exact fields affected: foreground/background color, brush name, size, opacity and mode. An agent can distinguish this from siblings like gimp_draw or gimp_fill, though no sibling is named explicitly.

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

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

'Sin argumentos devuelve los valores actuales' gives a clear conditional usage rule (call with no args to read, with args to write). However, it never says when to prefer this over alternatives such as gimp_draw, gimp_fill, or gimp_gradient, so routing is left 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?

Annotations already carry the safety profile (readOnlyHint=false, destructiveHint=false), so the description does not need to restate that this is a non-destructive mutation. It adds some behavioral context by disclosing that select=True makes the layer active and that opacity is bounded 0-100, but it says nothing about whether the layer must exist, whether changes are immediate/undoable, or what the call returns.

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

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

A single front-loaded sentence that opens with the verb+resource and then spends its remaining tokens on the parameter enumeration, with no filler. The long parenthetical blend-mode list is justified given the absence of schema enums, though the sentence is dense enough that a light structural break would read better.

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?

Annotations cover the safety profile and the description covers the parameters, but with no output schema the description should say something about what the call returns or confirms, and it is silent on that. The unresolved x/y-versus-gimp_transform_layer ambiguity also leaves a real gap for a 9-parameter mutation tool.

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

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

Schema description coverage is 0% and there are zero enums, so the description must carry the burden and largely does: it names every settable parameter (name, visible, opacity with its 0-100 range, mode, x, y, lock_alpha, select) and supplies the full blend-mode vocabulary that the schema leaves completely opaque. This is exactly the kind of value-add the schema cannot provide; only layer_id and the precise meaning of x/y are left light.

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 ('Cambia propiedades de una capa') and then enumerates exactly which attributes are settable (name, visibility, opacity, blend mode, x/y, alpha lock, active flag), which is far more specific than a tautology. It is clearly distinct from gimp_new_layer, gimp_delete_layer or gimp_duplicate_layer, but never resolves the overlap with gimp_transform_layer for the x/y position parameter, so it stops 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?

Usage is only implied: the reader infers this is the tool to reach for when altering an existing layer's attributes, and the '(select=True)' note hints at the active-layer use case. There is no explicit when-to-use/when-not statement and no comparison against gimp_transform_layer, which is the obvious alternative for repositioning.

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

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

Annotations only cover safety hints (readOnly, non-destructive, closed-world). The description adds real behavioral context the annotations lack: the call will launch GIMP if it is not running, which implies a potentially slow first invocation and a process-level side effect on the host. That side effect sits in mild tension with readOnlyHint=true, though it does not modify user data.

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 connection check (the primary diagnostic purpose) comes before the listing detail. Nothing to trim.

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

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

For a zero-parameter status tool with no output schema and full annotation coverage, the description says what it returns (open images) and discloses the auto-start behavior. An agent has everything it needs to call it correctly.

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

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

The tool takes zero parameters and the schema is an empty object, so there are no parameter semantics to explain. Baseline 4 applies; the description correctly implies no arguments 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 concrete compound action: verifies the GIMP connection and lists open images. Clear verb+resource, but it overlaps with the sibling gimp_list_images for the 'list images' half and never explains how the two differ.

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

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

Usage is implied rather than stated: 'comprueba la conexión' signals this is a diagnostic/health-check call, likely first in a workflow. No explicit when-to-use, no exclusions, and no mention of gimp_list_images as an alternative for enumerating images.

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

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

Annotations already declare this is a non-readOnly, non-destructive, closed-world write, so the safety profile is covered structurally. The description adds that the stroke applies to the 'current selection' (implying a selection should exist) but says nothing about undo behavior, what happens with no active selection, or whether the stroke is applied to the active 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 with no filler. It is efficient, though the sparseness reflects under-specification rather than 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?

With four parameters at 0% schema coverage and zero required parameters, the description leaves half the inputs undocumented for a mutation tool. The existence of an output schema relieves it of explaining return values, but the argument-level gaps remain substantial.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, yet it only covers two of the four parameters (width in px, color). The image_id and layer_id parameters, including that both are nullable and default to null, are left entirely unexplained.

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

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

States a specific verb and resource: it draws ('dibuja') the outline ('contorno') of the current selection. This distinguishes it reasonably from gimp_fill (fills interior) and gimp_draw, though it never explicitly names the sibling it differs from, 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?

There is no explicit statement of when to use this tool versus gimp_fill, gimp_draw, or gimp_modify_selection, and no prerequisites or exclusions are given. Usage must be inferred entirely from the one-line purpose.

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

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

Annotations already disclose that this is a non-read-only, non-destructive, non-open-world operation, so the safety profile is covered. The description adds useful geometric context such as clockwise rotation around the layer center and absolute top-left positioning, but it omits side effects, prerequisites, and whether layer/image IDs 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 definition is a single front-loaded sentence that enumerates the supported transformations without filler. Each clause adds a distinct operation or geometric detail, so no sentence feels wasted.

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

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

For an 11-parameter mutation tool with no output schema and 0% schema description coverage, the description covers the main transformation operations but omits critical context such as image_id/layer_id usage, whether at least one parameter must be supplied, and default behaviors. It is minimally adequate but has clear gaps given 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%, so the description must carry parameter meaning, and it does map most operations to parameters: scaling in px or %, rotation in degrees around center, flipping, absolute x/y movement, centering/alignment, and resizing the layer border to the image. It leaves image_id and layer_id unexplained and does not clarify defaults or parameter interactions, so it is not fully complete.

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

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

The description states a specific verb and resource ('Transforma una capa') and enumerates the supported transformations, so the tool's purpose is clear. It does not explicitly differentiate itself from siblings such as gimp_scale_image, gimp_rotate_flip_image, or gimp_set_layer, 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?

It lists what operations are available but gives no guidance on when to use this tool versus alternatives like gimp_set_layer or gimp_scale_image. There are no exclusions, prerequisites, or conditions that would help an agent choose correctly.

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