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

With no annotations, the description carries the burden of behavioral disclosure. It discloses the output type (8-bit autostretched PNG) and the effect of the 'linked' parameter, but it doesn't mention prerequisites like having a loaded image, potential failure modes, or side effects (e.g., writing debug copy when save_debug_copy is true). It's adequate but not thorough.

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

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

The description is exceptionally concise: a one-sentence purpose followed by a bulleted Args list. There is no filler, and the most important detail (what the tool returns) is front-loaded. Every line 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?

Given the tool has 7 parameters, no output schema, and no annotations, the description is incomplete. It doesn't explain the return format (e.g., whether the PNG is base64-encoded), what happens if no image is loaded, or error handling. An agent would have to guess or rely on trial and error for robust usage.

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 explain every parameter, and it does. Each argument is clearly described: max_edge for size, x/y/w/h for ROI coordinates, linked for autostretch mode, and save_debug_copy for a debug file. This fully compensates for the empty schema descriptions, adding meaning beyond bare types and defaults.

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

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

The description clearly states a specific verb ('Return') and a resource ('8-bit autostretched preview of the current Siril image'), with an optional ROI variant. This unambiguously distinguishes it from siblings like siril_get_stats and siril_get_state, which focus on data rather than images.

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 provides no explicit guidance on when to use this tool versus alternatives. It doesn't state conditions like 'use this when you need a visual representation' or mention that it should be preferred over siril_get_stats for previews. The only implied context is from the name and purpose, but no when/when-not guidance is given.

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

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

No annotations are provided, so the description carries the full behavioral burden. It is transparent that the tool is a read-only state query and lists what aspects of the state are surfaced. It does not discuss failure modes or whether the state may be empty, but the read-only nature is clearly evident from the verb and noun choice.

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

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

The description is a single, well-structured sentence that front-loads the core action ('Get live Siril state') and then efficiently lists the included fields. No wasted words or redundant 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 parameterless read-only tool with an output schema available, the description is complete: it names the state dimensions returned and signals the live/current nature of the data. There is no missing operational context that would prevent an agent from invoking 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, so there are no parameter semantics for the description to clarify; a baseline of 4 is appropriate. The description instead usefully lists the fields the agent can expect in the returned state, which complements the empty input schema.

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

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

The description uses a specific verb ('Get') and resource ('live Siril state'), then enumerates the exact fields returned: loaded image, size, filename, selection, and working directory. This makes the tool's purpose unmistakable and differentiates it from siblings like get_preview or get_stats.

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 word 'live' implies this tool is for reading the current Siril state, which gives some usage context. However, there is no explicit guidance on when to use this versus sibling tools like siril_get_preview or siril_get_stats, nor any mention of when it should not be used.

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 disclosure burden. It communicates a read-only intent and scoping ('per-channel', 'currently loaded image') but does not mention behavior when no image is loaded or any potential side effects; the output schema covers return details.

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

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

The description is a single sentence with the action and resource front-loaded, containing no filler. Every word earns its place.

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

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

For a no-parameter getter, the description plus output schema adequately covers invocation and expected result. The only notable gap is failure-mode context (e.g., no image loaded), but given the tool's simplicity this is a minor omission.

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

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

The tool has zero parameters, and the schema already covers the empty input space, so the description does not need to add parameter semantics. The baseline of 4 for 0-parameter tools applies here.

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

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

The description uses a specific verb ('Get') and resource ('per-channel statistics') scoped to the currently loaded image, so an agent can tell what the tool does. It does not explicitly contrast with siblings like siril_get_state or siril_get_preview, but the resource is distinct enough.

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

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

No guidance is provided on when to choose this tool over sibling tools, nor are prerequisites or exclusions mentioned. The phrase 'currently loaded image' implies some context, but there is no explicit when-to-use or when-not-to-use guidance.

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

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

There are no annotations, so the description carries the behavioral burden. It discloses the list behavior and the two filtering behaviors: substring match on name/usage and scriptable-only restriction. For a simple read-only listing tool, this is adequate; it does not claim side effects or need to state auth/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?

The description is two sentences plus a compact Args block. Every sentence earns its place: the first states the core purpose, and the Args section clarifies both parameters without filler.

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

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

For a low-complexity discovery tool with an output schema available, the description covers the purpose and all parameter semantics. Sibling tools are clearly distinct by verb, so an agent should be able to select and call this tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does: query is defined as an optional substring filter on command name or usage, and scriptable_only is defined as limiting results to scriptable commands. Both parameters get meaningful semantics beyond their raw schema titles and defaults.

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

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

The description states a specific verb and resource: 'List Siril commands available for scripting.' This clearly distinguishes it from sibling tools like siril_run_command and siril_run_script, which execute commands rather than enumerate them.

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

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

The phrase 'available for scripting' and the query/filter arguments imply this is a discovery tool to find commands before scripting, but the description never explicitly says when to prefer it over siblings or when not to use it. Usage context is implied, not stated.

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

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

No annotations are provided, so the description carries the behavioral burden. It implies a read-only connectivity check, which is likely safe and side-effect-free, but it does not disclose failure behavior, return semantics, or any timeout/error traits. For a simple ping this is adequate but not richly transparent.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes to explaining the tool's purpose, and it is appropriately sized for a no-argument health check.

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

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

Given the tool's zero parameters, the presence of an output schema, and the simplicity of a ping, the description is nearly complete. It could add a note about output meaning or typical usage order, but those are not essential for calling this tool correctly.

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

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

The tool has zero parameters and 100% schema description coverage, so there is nothing for the description to add. Per the rubric, a 0-parameter tool with full schema coverage receives a baseline of 4.

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

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

The description uses a specific verb ('Check') and names a concrete resource ('Siril MCP bridge') and condition ('is running inside Siril'). This clearly distinguishes it from sibling tools like siril_run_command or siril_get_state, which perform different actions.

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

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

The description states what the tool does but gives no guidance on when to use it versus alternatives, and does not mention whether it should be called before other operations. There is no explicit context or exclusion, leaving the agent to infer usage.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals only that the command runs in the 'live GUI session' but does not mention side effects, session requirements, failure modes, or whether the command mutates state. For a command runner that can execute arbitrary operations, this is a significant transparency 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?

The description is short, front-loaded with the core purpose, and uses a clear Args section. Every line earns its place without filler or redundant restating 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?

Although an output schema is present, the description lacks important context for correct invocation: it does not explain how to discover valid command names, when to use this tool instead of running a script, or what session precondition is required. The sibling siril_list_commands is available but never referenced, leaving the agent to infer the workflow.

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 by naming example commands and describing 'args' as an optional list of argument strings, which goes slightly beyond the schema's bare types. However, it does not specify the expected argument syntax or how commands should be invoked, so the compensation is 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?

The description states a specific action ('Run a single Siril command in the live GUI session') and gives concrete command examples ('autostretch', 'load', 'cd'), so an agent can understand what the tool does. It partially distinguishes itself from sibling tools like siril_run_script through the qualifier 'single command', though it does not explicitly name alternatives.

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

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

No guidance is provided about when to use this tool versus siril_run_script, siril_list_commands, or the other siblings. The intended use is only implied by the name and the examples; there are no exclusions, prerequisites, or pointers to more appropriate tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals only that Python scripts are executed via pyscript, but does not mention that running a script may modify images, fail partway, require specific Siril state, or produce side effects. This is a significant transparency gap for a script execution tool.

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

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

The description is concise and front-loaded with the core purpose, followed by a clean two-item argument list. Every sentence earns its place and there is no redundant or filler text.

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

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

The input parameters and execution modes are documented well enough to make a basic call, especially given that an output schema exists. However, for a tool that runs arbitrary multi-line scripts, the lack of side-effect disclosure and the absence of explicit guidance about when this tool is appropriate limit completeness.

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 fully compensates by explaining script_body as 'Full script contents' and kind as 'ssf' for command scripts or 'py' for Python executed with pyscript. This adds real meaning beyond the raw schema and clarifies how to construct each argument correctly.

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

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

The description states a specific action and resource: 'Run a multi-line Siril script (.ssf command script or .py via pyscript).' It differentiates from the sibling siril_run_command by emphasizing multi-line scripts and script file types, so an agent can tell this tool apart 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 description implies this tool is for multi-line scripts, but it does not explicitly state when to prefer it over siril_run_command or what the exclusion conditions are. The 'multi-line' qualifier hints at the intended use, but no alternative tools are named.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Set', which implies mutation, but does not state that the current selection is replaced, whether it requires a loaded image, whether it affects image data, or how errors are reported.

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

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

The description is a single, front-loaded sentence with no redundant wording. Every word contributes to identifying the action, the target, and the parameter semantics.

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 state-changing tool with no annotations and no parameter descriptions, the definition is quite thin. It omits coordinate units/origin, prerequisites, and behavioral effects. The presence of an output schema reduces the need to describe return values, but the remaining context is insufficient for confident correct use.

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

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

The description adds meaning by mapping the terse parameter names w and h to 'width' and 'height' and by presenting the expected order as (x, y, width, height). However, with 0% schema description coverage, it still leaves gaps such as units, coordinate origin, bounds, and valid ranges.

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

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

The description uses a specific verb ('Set') and a specific resource ('Siril image selection rectangle'), and it explicitly identifies the tuple as (x, y, width, height). This clearly distinguishes it from sibling tools like siril_run_command, siril_get_preview, and siril_get_stats.

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, and no prerequisites or exclusions are given. The intended use is only implied by the name and description, with no mention of required prior state such as an image being loaded.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It mentions the undo-history condition but does not state that this is a state-mutating operation, what happens when no history exists, or whether the undo affects the current image/state. This is a meaningful gap for a mutation tool.

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

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

The description is a single, front-loaded sentence with no filler or repetition. Every word earns its place.

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

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

For a zero-parameter tool with an output schema, the description is mostly complete: it names the action and the key precondition. It could additionally explain failure behavior when undo history is unavailable, but the simplicity of the tool limits the impact of that omission.

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

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

The tool has zero parameters and the schema reflects that, so no parameter explanation is needed. The description correctly implies that no arguments are required to perform the undo.

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

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

The description uses a specific verb ('Undo') and resource ('the last Siril operation'), making the action unambiguous. It clearly differs from the sibling tools like siril_run_command or siril_get_state, and the caveat about undo history adds precision.

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 provides clear context: it is for undoing the last operation when history is available. It does not explicitly name alternatives or exclusions, but the use case is self-evident and no competing sibling performs the same action.

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