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

With no annotations, the description carries the full burden and does disclose two useful traits: it refuses overwrites unless explicitly enabled, and it restricts writes to an allow-listed XCF path. It omits failure modes, whether the session document state changes, and any permission requirements.

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

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

Two short sentences, front-loaded with the primary action and followed by the key safety constraint. No filler or redundant restatement of the tool name.

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

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

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

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning for two parameters (overwrite's refusal semantics and output_xcf's allow-list restriction) but leaves session_id completely unexplained in both schema and description.

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

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

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

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

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

There is no statement of when to use this tool versus export_image or any other save/export sibling. The only conditional in the text is about overwrite refusal, which is behavior, not tool selection guidance.

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

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

No annotations are provided, so the description carries the full burden, yet it only says the events are 'recent' and 'live'. It does not disclose pagination behavior, ordering, whether results are capped, whether it blocks, or any auth/permission requirements for an observation surface.

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

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

A single efficient sentence with the resource and audience front-loaded and no wasted words. It is arguably too terse for the burden it must carry, but the structure itself is clean.

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

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

An output schema exists, so return values need not be explained, but for a parameterized observation tool with zero annotations and zero schema description coverage, the description leaves the agent guessing about filtering scope and result limits. It is under-specified relative to the tool's complexity.

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

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

Schema description coverage is 0%, and the description never mentions either parameter. The meaning of 'limit' (default 100) and especially 'session_id' (does omitted mean all sessions?) is left entirely undocumented, so the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Return recent live operation events') and names the audience ('observers and control UIs'), which tells an agent what it gets back. It does not differentiate itself from siblings like session_list or gimp_status, so it stops short of a 5.

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

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

The phrase 'for observers and control UIs' implies a usage context (polling for live state rather than inspecting a session or a status tool), but no explicit when-to-use or when-not-to-use guidance is given relative to the many sibling tools. The agent must infer that this is a monitoring/polling surface.

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

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

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

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

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

A single efficient sentence with the core action and the format-selection behavior front-loaded. No filler, though it is short enough that the missing guidance is conspicuous rather than trimmed.

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

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

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

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

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

Schema description coverage is 0% for 3 parameters. The description adds real meaning for output_path (its extension determines the encoded format), which is more than the bare schema, but session_id and especially overwrite (default false, unclear collision behavior) are left undocumented.

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

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

States a specific verb (Export) and resource (the session) plus the target artifact (image in PNG/JPEG/WebP/other GIMP format). It does not explicitly differentiate itself from the sibling document_save_as, which is the nearest ambiguity, so it falls short of a 5.

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

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

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

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

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

No annotations are provided, so the description carries the full burden. It clearly indicates the operation is non-destructive (creates a DrawableFilter), which is valuable behavioral context. However, it omits permission requirements, whether the filter is applied immediately or requires a render step, and effects on the layer's state.

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

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

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

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

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

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

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

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

Schema description coverage is 0%, so the description must compensate for all parameter semantics, but it only hints at the 'operation' and 'parameters' fields indirectly. It doesn't explain 'session_id', 'layer_id', 'name', or the expected structure of the 'parameters' object, leaving critical parameters undocumented.

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

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

States a specific verb (Apply) and resource (GEGL operation as a non-destructive GIMP DrawableFilter) on a specified target (a layer). This distinguishes it from filter_list and filter_describe, which are read-only discovery tools, and from structural tools like layer_delete.

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

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

The phrase 'Discover parameters first if uncertain' implies a workflow involving filter_describe, but it doesn't explicitly say to use filter_list/filter_describe as the alternative. No when-not-to-use or prerequisites (like session/layer existence) are stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Describe' strongly implies a safe read operation and the existence of an output schema covers return values, but the description never confirms it is read-only (no side effects on GEGL state) or mentions any constraints. It is adequate but thin for a zero-annotation tool.

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

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

A single front-loaded sentence with no filler. The purpose and the downstream benefit are both stated compactly.

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

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

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

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

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

Schema coverage is 0% and the single 'operation' parameter has no description in the schema. The description only obliquely indicates the parameter is a GEGL operation, but gives no expected format or example (e.g. 'gegl:blur'), so it fails to compensate for the coverage gap.

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

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

States a specific verb ('describe') and resource ('a GEGL operation's configurable properties'), and even names the downstream goal (constructing a valid filter_apply call). An agent can clearly distinguish it from siblings filter_list and filter_apply without opening the schema.

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

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

The phrase 'so an AI can construct a valid filter_apply call' implies this is a prerequisite step before filter_apply, which is useful implied guidance. However, it never explicitly states when to call this vs filter_list (to discover operation names) or filter_apply, nor any ordering or exclusion, leaving the workflow inference-based.

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

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

No annotations are provided, so the description carries the full burden. It implies a safe, read-only discovery operation but does not state the result size behavior (limit defaults to 100) or that results may be truncated, and says nothing about auth or rate limits. Adequate but with a clear gap for a no-annotation tool.

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

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

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

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

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

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

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

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

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

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

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

States a specific verb (discover) and resource (GEGL operations), and explicitly names the two sibling tools it relates to (filter_describe/filter_apply). An agent can distinguish this listing tool from the describe/apply tools without opening any schema.

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

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

Gives an explicit precondition: use this before filter_describe/filter_apply when the exact operation name is unknown. That is a concrete when-to-use rule tied to the alternatives.

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

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

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

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

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

Three short sentences with zero waste: the verification scope, the safety profile, and the usage trigger are all front-loaded and each earns its place.

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

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

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

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

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

The tool takes zero parameters, so there is nothing to document and the schema is fully covered. Baseline of 4 applies for a no-argument tool.

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

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

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

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

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

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

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

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

With no annotations, the description carries the full burden. It discloses useful traits: the new layer is transparent, width/height fall back to canvas dimensions, and it returns a persistent tattoo-based layer_id. It omits whether the layer becomes active, where it is inserted in the stack, and whether the operation is undoable.

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

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

Three short sentences, front-loaded with the core action and then the two most useful facts. Every sentence carries information; nothing is padded.

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

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

An output schema exists, so the return value need not be detailed. However, for a creation tool with no annotations and a required undocumented session_id, the description should say more about session/context requirements and the resulting layer's place in the document.

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

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

Schema description coverage is 0% across 4 params, so the description must compensate. It does explain the nullable width/height defaults, which adds real meaning beyond the schema, but it says nothing about the required session_id or the 'name' default of 'Layer'.

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

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

The description states a specific verb and resource ('Create a transparent layer'), which clearly separates it from siblings like layer_delete, layer_update and layer_reorder. It stops short of explicitly disambiguating from text_create, which also produces a layer, so it is clear but not perfectly sibling-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?

There is no guidance on when to use this tool versus alternatives such as text_create, nor any prerequisites (e.g. an open session/document). The only contextual statement is about default sizing, which is parameter behavior rather than usage guidance.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description gives a specific verb and resource with scope ("Delete one layer identified by layer_id"), which cleanly separates it from layer_create, layer_update, and layer_reorder. It stops short of naming any alternative or clarifying intended/deleting conditions, so it is clear but not maximally differentiating.

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

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

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

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

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

No annotations are provided, so the description carries the full burden. It discloses the position-indexing convention but nothing about side effects, whether other layers shift, required session state, or reversibility for what is clearly a mutation.

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

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

A single front-loaded sentence with zero filler; the most important convention (indexing origin) is stated immediately.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

With no annotations, the description carries the full behavioral burden. It discloses the useful constraint that opacity is a percent 0..100 (beyond the schema's bare 'number'), but says nothing about partial-update semantics, whether omitted fields are left untouched, error behavior for bad layer_id, or session/auth requirements for this mutation.

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

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

Two tight sentences, zero filler, with the primary action front-loaded and the non-obvious opacity constraint immediately after. Every clause earns its place.

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

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

An output schema exists, so return values need not be described. However, for an unannotated mutation tool with 0% schema coverage, the description is only marginally complete: it omits partial-update semantics, session requirements, and the meaning of the two required identifiers.

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

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

Schema coverage is 0%, so the description must compensate. It clarifies the meaning of three of five parameters (name=rename, visible, opacity) and adds the 0..100 range that the schema lacks, but leaves layer_id and session_id completely unexplained.

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

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

The description states a specific verb+resource pair ('Rename a layer') plus the secondary operations ('set visibility/opacity'), so an agent knows exactly what mutation it performs. It is clearly distinct from layer_create and layer_delete in intent, though it doesn't explicitly name those siblings to route 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?

There is no guidance on when to use this versus layer_create, layer_delete, layer_reorder, or transform_layer. No prerequisites (e.g. an active session or valid layer_id) are mentioned, leaving the agent to infer 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?

With no annotations, the description carries the full behavioral burden; it correctly supplies the key trait 'read-only,' which is genuinely useful. It does not say what happens with an unknown procedure name, whether names are case-sensitive, or how the inspection result should be interpreted.

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

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

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

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

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

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

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

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

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

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

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

States a specific verb (inspect) and resource (arguments and returns of one GIMP PDB procedure), so the agent knows it is a metadata/introspection call. It implies differentiation from pdb_search by emphasizing 'one' procedure, but never names the sibling that lists many.

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

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

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

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

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

No annotations are provided, so the description carries the full burden, and it does disclose the tool's rationale (avoiding thousands of exported tools) and implicitly that it is a read-only discovery operation. However, it never says how matching works (substring, prefix, regex, case sensitivity) or how results are bounded. Return format is covered by the output schema, which partially offsets the gap.

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

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

A single well-formed sentence with no filler; the purpose and its justification are front-loaded. It is efficient, though brevity here comes at the cost of operational detail.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

With no annotations, the description carries the full burden. It usefully discloses that the output is a bounded PNG and that a gimp-preview resource URI is returned, but it never states whether rendering alters the document, whether it costs memory/time, or that it is a safe read-only operation — a meaningful gap for a tool with zero annotation coverage.

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

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

Two short sentences, front-loaded with the action and output, with no filler. The second sentence partially duplicates the output schema, but it is brief enough not to be wasteful.

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

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

An output schema exists, so return values need not be spelled out, and the description is adequate for a simple preview tool. However, with no annotations and 0% parameter documentation, the agent is left uninformed about session requirements, size limits semantics, and side effects.

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

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

Schema description coverage is 0%, so the description must compensate and does not. 'Bounded' hints at max_width/max_height but gives no units, defaults, or behavior when omitted, and session_id — the only required parameter — is never explained or linked to session_create/session_open.

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 output ('Render a bounded PNG preview of the current artwork') with a clear downstream intent ('for vision review'), which separates it from mutation siblings like layer_create or export_image. It stops short of naming any sibling explicitly, so an agent must infer that export_image is the write-to-disk alternative.

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

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

The phrase 'for vision review' implies a usage context (inspect artwork visually before deciding), but there is no explicit when-not guidance and no mention of the closest alternative, export_image, or of any prerequisite like an open session. Usage is implied 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 no annotations, the description carries the full burden. 'List' implies a non-destructive read and 'already-linked' discloses a prerequisite, which is useful behavioral context. It does not disclose failure behavior for unlinked providers, whether results are cached/live, or any rate limits.

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

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

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

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

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

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

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

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

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

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

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

The description states a specific verb and resource ('List models') and scopes it to the four named provider accounts. It does not explicitly distinguish itself from siblings like provider_status or triforce_models, but the resource ('models' per provider account) is unambiguous.

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

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

The phrase 'already-linked' implies a precondition, so an agent can infer this only works after an account is linked. However, there is no explicit when-to-use guidance, no statement of what to do when no provider is linked, and no routing versus provider_status or triforce_models.

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

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

No annotations are provided, so the description must carry the burden; it does disclose one key behavioral fact (credentials are not returned, framing it as a non-sensitive read). It does not state whether this counts as a read-only operation, whether it can fail or time out, or what the status output shape is, though the output schema covers the return value.

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

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

Two sentences, no waste, and the credential-safety note is front-loaded with the core action. Nothing extraneous 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 parameterless status tool with an output schema available to describe returns, the description is adequate: it names the adapter, the subject of the status, and the credential guarantee. It is missing only sibling disambiguation and a hint of failure 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?

Zero parameters, so there is nothing to document and the schema is trivially complete; baseline is 4. The description correctly describes a parameterless call.

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

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

States a specific verb (report) and resource (official-provider account status), and the sensitivity note 'No credentials are returned' sharpens the scope. However, it does not differentiate from the sibling status tools (gimp_status, triforce_status) or the sibling provider_models, so the agent cannot tell without opening it whether 'provider' overlaps those.

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

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

Usage is implied by the name and the phrase 'through the shared AICoder adapter', but there is no explicit when-to-use or when-not-to-use guidance, and no mention of the sibling status tools it might be confused with. Minimum viable.

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

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

With no annotations, the description carries the full burden but only discloses the geometry-handling difference between actions. It says nothing about side effects on prior selections, session/auth requirements, or reversibility of a state mutation.

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

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

Two tight sentences, front-loaded with the core purpose and followed by the one non-obvious conditional. 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?

An output schema exists, so return values need not be described. However, with six parameters at 0% coverage and no annotations, the omission of enum semantics and session context leaves the definition short of what an agent needs to call it reliably.

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

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

Schema coverage is 0%, so the description must compensate. It usefully explains that x/y/width/height are pixel coordinates and dimensions only relevant to the rectangle action, but it leaves the action enum values and the session_id parameter 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 ('Set the current selection') and goes further by explaining that only the rectangle action consumes geometry while others ignore it. There are no sibling selection tools to differentiate against, so this is a clear, self-contained purpose.

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, when not to, or how the four enum actions (none/all/invert/rectangle) should be chosen. It only clarifies geometry relevance for rectangle, which is parameter behavior rather than usage guidance.

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

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

With no annotations, the description carries the full burden and does disclose a key destructive trait: discard=true deletes the temporary XCF and history. It does not state the default outcome when discard is false (session closed but artifacts retained), nor reversibility or permission requirements, leaving meaningful gaps for a mutation tool.

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

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

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

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

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

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

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

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

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

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

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

States a specific verb and resource ('Close a session'), which is unambiguous against siblings like session_open and session_create. It does not, however, explicitly contrast itself with lifecycle siblings such as session_undo or session_info, so it falls short of full sibling differentiation.

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

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

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

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

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

With no annotations, the description carries the full burden. It usefully discloses that the tool creates an isolated session and XCF working document and returns a session_id used by all editing tools, but it does not cover permissions, lifecycle, cleanup, or how this interacts with existing sessions.

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

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

Two tightly written sentences with zero waste. The creation purpose is front-loaded and the return usage is stated immediately after.

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

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

The output schema exists, so return-value details are less necessary, and the description does mention session_id usage. However, for a session-creation tool with no annotations and undocumented parameters, it omits key context about when to create versus open a session and what the canvas parameters control.

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

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

Schema description coverage is 0% for three parameters, and the description does not mention width, height, or background_name at all. It adds no meaning beyond the parameter names and defaults already visible in the 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 and resource: creating a new isolated artwork session and XCF working document. The word 'new' hints at the distinction from session_open, but no sibling is named, so it is clear without being explicitly differentiated from 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?

There is no explicit guidance on when to use this tool versus session_open or other session tools. The 'new' wording implies creating a fresh session, but no conditions, prerequisites, or exclusions are stated.

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

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

With no annotations, the description carries the burden and does disclose the key trait: it is non-mutating ("without modifying it"). It stops there, saying nothing about permissions, error behavior, or the freshness of the returned state.

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

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

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

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

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

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

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

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

Schema coverage is 0%, so the description should compensate. It scopes the identifier to an "artwork session," which gives session_id some meaning, but adds no format or origin detail. The generic param name carries most of the weight.

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

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

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

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

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

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

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

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

No annotations are provided, so the description carries the full behavioral burden. It does add useful context beyond the schema by noting that 'recovered' sessions are included and that undo depth is reported, which hints at the enumerable state, but it never states that this is a non-destructive read or describes scoping/filtering behavior.

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

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

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

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

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

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

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

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

The tool takes zero parameters, so the baseline of 4 applies; there are no parameter semantics to clarify beyond what the empty schema already conveys.

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

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

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

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

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

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

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

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

No annotations are provided, so the description carries the full burden. It does disclose a meaningful behavioral trait: the file is opened into an isolated copy so source files are never edited in-place. But it omits session lifecycle, error behavior for a missing/invalid path, and persistence semantics, which matter given the surrounding session_* tools.

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

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

A single front-loaded sentence carrying the action, target, and the key safety benefit with no wasted words.

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

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

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

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

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

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

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

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

The description gives a specific verb+resource (open an existing image/XCF) plus the core behavior (isolated session copy). The word 'existing' implicitly separates it from session_create, but it never explicitly names or contrasts the sibling, so the differentiation is inferable rather than stated.

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

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

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

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

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

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

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

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

A single tight sentence with the scope constraint front-loaded and zero filler. Nothing could be removed without losing meaning.

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

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

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

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

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

Schema description coverage is 0% and there is one required parameter, session_id, whose meaning and accepted format the description never touches. With a coverage gap this large the description should compensate, and it does not.

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

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

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

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

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

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

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

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

With no annotations, the description carries the full burden. It usefully discloses scope ('last successful mutating operation') and mechanism ('session snapshot journal'), implying a one-step, journal-backed reversal. It omits failure behavior (what happens with no snapshot), whether the undo is itself reversible, and any auth or session-precondition requirements.

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

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

A single front-loaded sentence with no filler; the operative action and its scope appear immediately.

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

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

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

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

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

Schema description coverage is 0% for the single required parameter session_id, and the description never mentions it or explains what value it takes (e.g., from session_create/session_list). Since the schema does not document the parameter, the description should have compensated and does not.

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

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

The description gives a specific verb and resource ('Undo the last successful mutating MCP operation') plus the mechanism ('session snapshot journal'), which is far more precise than the bare name. It does not, however, explicitly distinguish itself from the sibling session_redo, leaving the agent to infer the undo/redo pair from naming alone.

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

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

There is no guidance on when to use this versus session_redo, no mention of prerequisites (an existing session, a populated snapshot journal), and no stated limit such as whether only a single operation can be undone. Usage is only implied by the name and the word 'last'.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does disclose the mutation ('Create'), the editability of the resulting layer, and the returned layer_id, but is silent on session requirements, undo behavior, and what happens if no document is 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?

Two tight sentences with the primary action front-loaded and the return value appended. No filler or redundancy.

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

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

An output schema exists, so the return value need not be explained. However, for a mutation tool with zero annotations and 0% schema description coverage across 6 parameters, the description leaves the session lifecycle and several parameter semantics 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 must compensate. It usefully clarifies that x/y are pixel positions and size is in pixels, but leaves text, font_name, and the required session_id unexplained beyond their names and schema defaults.

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

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

States a specific verb and resource ('Create an editable GIMP text layer') with the positioning semantics, which distinguishes it from the generic layer_create sibling. It does not name layer_create explicitly, but the 'text layer' qualifier is enough for an agent to differentiate.

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

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

There is no explicit guidance on when to use this versus layer_create or other creation paths, nor any stated prerequisites such as an active session or document. Usage is only inferable from the tool name and verb.

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

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

No annotations are provided, so the description carries the full burden for a mutation tool. It never states whether transforms are undoable (relevant given session_undo exists), what permissions or session state are required, or what happens on an out-of-range rotation or scale. Only the value encodings are 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?

Two short sentences, front-loaded with the purpose and then the argument grammar. Every clause carries information and nothing is repeated from the schema.

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

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

The output schema covers return values, and the values encoding is well documented, so the core invocation is clear. For an unannotated mutation tool with a required session_id, however, the absence of any statement about prerequisites, side effects, or undo behavior leaves meaningful gaps.

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

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

Schema description coverage is 0%, yet the description supplies the exact encoding of the 'values' array per action enum: translate=[dx,dy] pixels, rotate=[degrees] or [degrees,cx,cy], scale=[x0,y0,x1,y1]. That resolves the single genuinely ambiguous parameter; session_id and layer_id are self-evident from their names.

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

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

States a specific verb and resource ("Transform one layer") and immediately qualifies it with the coordinate conventions for each mode. It is clearly distinct from siblings like layer_update or layer_reorder, 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?

There is no when-to-use guidance: nothing says when to prefer transform_layer over layer_update, selection_set, or filter_apply, nor whether a session must be open first. The per-action value formats imply the tool's scope but do not route the agent among alternatives.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only listing bound to the authenticated account (useful auth context), but says nothing about pagination, rate limits, or failure behavior when not logged in.

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 scope qualifier ("currently logged-in account") is the only thing that matters and it appears immediately.

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

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

An output schema exists, so return values need no explanation, and a zero-param read tool is inherently simple. However, with no annotations and no differentiation from provider_models, the definition leaves a real selection ambiguity unresolved.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond the account scoping it already states. Baseline 4 applies for a parameterless tool.

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

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

States a specific verb and resource ("List models") and scopes it to the currently logged-in AILinux/TriForce account. It is clear on its own, but it does nothing to distinguish itself from the sibling provider_models, 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?

The description gives no when-to-use guidance and never mentions alternatives such as provider_models or triforce_status. An agent must infer from the name alone whether this or provider_models is the correct tool.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the bearer token is not exposed, implying a safe read, and implicitly that it reuses an existing login rather than creating one. However, it says nothing about auth requirements, failure behavior when unauthenticated, or rate limits.

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

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

A single front-loaded sentence with no filler. It is appropriately sized for a zero-param status tool, though the 'reused from AICoder' clause adds more words than value.

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. For a zero-parameter read-only status call, the description communicates enough to invoke it correctly, with the only gap being authentication/usage context.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter surface the description needs to explain.

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

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

States a specific verb (Report) and resource (existing AILinux/TriForce login), which distinguishes it from siblings like triforce_models or provider_status. The phrase 'reused from AICoder' adds a slightly confusing provenance detail rather than sharpening the purpose, but the core intent 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 explicit when-to-use guidance, no mention of prerequisites, and no differentiation against the many sibling status/session tools. The agent must infer that this is a diagnostic call for login state.

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