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

With no annotations, the description carries the full burden, and it does disclose the key side effect: a new fitted variable is created in the dataset. However, it says nothing about whether the source data is modified, how missing values or attached instances behave, or what permission/state requirements exist, leaving meaningful behavioral gaps for a mutating tool.

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

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

A single front-loaded sentence that names the operation, the output, and the motivation without filler. It is dense and slightly run-on, but 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 tool with no output schema and no annotations, the description covers the core action and its primary side effect, and the schema fills in the remaining parameters. It could say more about persistence (`save`) and live-edit (`attach`) side effects, but the essentials for correct invocation are present.

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

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

Schema description coverage is 75%, so most parameters are already documented. The description reinforces the `x` default (case number) and the fitted-variable output, but adds nothing about `degree` polynomial fitting, `save`, `sheet`, or `attach` beyond what the schema states. Baseline 3 is appropriate.

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 ('Fit an ordinary least-squares line of `y` on `x`') and a concrete output ('write the fitted values to a new variable'). The parenthetical 'scriptable substitute for the interactive graph fit' distinguishes it from the heavier analysis siblings such as statistica_regression and from dialog-driven fitting.

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

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

It gives clear context for use ('so the trend can be plotted next to the data') and contrasts itself with the interactive graph fit, implying when the scriptable route is preferred. It does not name a sibling alternative explicitly or state when not to use it, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the two-stage transform (product then centered moving average) and that the result is appended as a named column, which is real behavioral detail, but it says nothing about mutation side effects on the target sheet, permissions, or how attach/save change execution.

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

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

A single dense sentence that front-loads the core computation before the append action. Nothing is wasted, though the parenthetical workflow note is slightly tacked on.

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

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

For a 10-parameter mutation tool with no annotations and no output schema, the description covers the core behavior but omits side effects on the target sheet, the effect of attach vs a new process, and persistence via save. The rich schema compensates for parameters, but the mutation semantics remain under-described.

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 100%, so the schema already documents lag, mode, window, smooth and the rest. The description ties the parameters together conceptually (the product formula, the smoothing) but adds no syntax or default detail beyond what the properties already state, so the baseline of 3 applies.

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

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

The description names a specific chain of verbs (compute, smooth, append) on a specific resource (the lag-m correlation product column x(t)*x(t-lag)) and points at a target sheet. An agent knows exactly what the tool produces, though it never explicitly contrasts itself with siblings like set_formula or statistica_time_series.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named. The parenthetical '(builds the Month + Lag1..LagK matrix step by step)' only implies the workflow context in which this tool belongs, so usage is inferable but 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 full behavioral burden, yet it only notes that variables are 'empty' (a useful detail). It omits mutation side effects, the role of save/attach, permission needs, and what happens to the running instance.

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: the purpose is front-loaded and the type legend follows. Nothing is wasted, though the second sentence could be tied more directly to the 'type' parameter.

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

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

For a 10-parameter mutation tool with no annotations and no output schema, the description is too thin. It does not clarify the save/attach behaviors or the interaction between count, after, and sheet, leaving substantial gaps an agent would need to fill.

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 high (90%), setting a baseline of 3, and the description adds genuine value by mapping the enum values (0=numeric, 1=text, 2=integer, 3=byte), which the schema only lists numerically without labels.

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 ('Append') and resource ('new empty variables to a spreadsheet'), which is clearly distinct from siblings like rename_variables, delete_variables, and read_variables. However, it does not explicitly name or differentiate itself from those siblings in the text.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. An agent must infer usage from the name and schema alone.

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

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

With no annotations, the description carries the full burden, and it discloses only that names are applied one per case starting at case 1 -- information the `names` schema field already states. It omits whether writes persist without `save`, what happens when the name count mismatches the case count, and any permission or process side effects (e.g. the `attach` live-edit mode).

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

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

Two tight sentences with the read default stated first and the write condition second. No filler, no redundancy, front-loaded with the core capability.

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

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

For a 6-parameter tool with no annotations and no output schema, the description covers the read/write duality but leaves return behavior (limit/default 200), persistence via `save`, and the live-edit implications of `attach` unexplained. Adequate but with clear gaps an agent must resolve from the schema alone.

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

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

Schema description coverage is 83%, so the schema already documents nearly every parameter, making 3 the baseline. The description's only parameter detail (one name per case from case 1) restates the `names` field description rather than adding new semantics.

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

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

The description states a specific verb pair (read/set) and resource (case names / text labels for spreadsheet rows), which is clear on its own. It implicitly separates this from siblings like rename_variables and value_labels by scoping to row labels, but it never names those siblings to make the boundary explicit.

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

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

It establishes that omitting `names` means read-only and providing `names` means write, which is useful conditional guidance. However, it offers no when-to-use context relative to alternatives such as value_labels or rename_variables, and no prerequisites for the write path.

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

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

With no annotations, the description carries the full burden and does not meet it. It says the tool deletes, but never states whether deletion is reversible, what happens to the source file when 'save' is omitted, or how the live-attach mode affects the running instance.

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

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

A single front-loaded sentence with the verb and resource first and zero 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?

A 6-parameter destructive mutation tool with no annotations and no output schema needs far more than one sentence. Missing are the persistence semantics of 'save', the effect of 'attach' on a live process, and any safety or recovery information.

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 83%, so the schema already documents most parameters. The description's only added value is clarifying that 'from'/'to' form an inclusive range and can be resolved by index or name, which is genuine but marginal.

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 ('Delete ... variables') and adds scope detail ('inclusive range ... by index or name'). This separates it from siblings like add_variables and rename_variables, though it never names them explicitly.

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

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

There is no guidance on when to use this versus alternatives such as select_cases or recode, and no warnings or prerequisites for a destructive operation. The agent must infer the 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 behavioral burden. It usefully discloses the return contents (properties, methods, enum constants) and implies a read-only introspection, but says nothing about side effects such as whether it spins up a STATISTICA process, runtime cost, or how the 'attach' live-edit mode changes behavior.

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

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

Two tightly packed sentences with zero waste; the core action and the enumerated return are front-loaded, and the workflow cue (building a run_analysis request) follows.

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

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

With no output schema and no annotations, the description correctly compensates by stating what the call returns and where it fits in the run_analysis workflow. The remaining gap is the absence of any side-effect or process/latency context for an introspection call.

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

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

Schema description coverage is 75%, so most parameters (path, attach, module) are documented in the schema itself. The description adds no additional parameter meaning, so the baseline 3 applies when the schema does the heavy lifting.

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 (introspect) and resource (a STATISTICA analysis dialog), and enumerates exactly what it returns: settable properties, callable methods, and known enum constants. It also implicitly distinguishes itself from run_analysis by positioning itself as the upstream step.

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 tells the agent when to reach for it: 'before driving it' and 'Use it to build a run_analysis request', which routes it against the run_analysis sibling. It stops short of naming when NOT to use it or listing other alternatives such as list_analysis_modules.

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

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

With no annotations, the description carries the full burden. It does disclose the returned content in detail (case count, variable count, full variable metadata), which is genuinely useful given there is no output schema. However it never states side effects: whether a STATISTICA process is launched, whether the file is modified, or what 'attach' does to the running instance.

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

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

A single front-loaded sentence that opens with the action and then lists the payload. The parenthetical field list is dense but every item is a real return field, so little is wasted; only the opening is arguably overloaded.

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?

Because there is no output schema, the description correctly takes on the job of enumerating return values, and it does so thoroughly. The remaining gap is behavioral: for an 'open a file' tool with no annotations, an agent still cannot tell whether opening has side effects or how attach changes the call.

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

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

Schema description coverage is 100% and all three parameters (path, sheet, attach) are documented in the schema, including the live-edit semantics of attach. The description adds no parameter-level detail beyond the .sta/.stw file extension hint, so the baseline 3 applies.

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

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

States a concrete verb+resource pair ('Open a .sta/.stw file') and enumerates exactly what it reports (case count, variable count, and per-variable metadata fields). This distinguishes it in substance from value-reading siblings like read_variables, though it never names those alternatives explicitly.

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

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

The description gives no when-to-use or when-not guidance and does not mention any sibling (e.g. read_variables, list_sheets) as an alternative. Usage is only inferable from the verb 'Open...and report'.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that missing values are honoured using declared missing codes and that computation happens in Node via COM, but it does not state whether the operation is read-only, what permissions are needed, or whether any file mutation occurs.

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 no wasted words. The core purpose and output statistics are front-loaded, followed by the important missing-value handling 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?

The description lists the statistics returned and explains missing-value handling, which is helpful given there is no output schema. However, it omits any usage guidance relative to siblings and does not clarify the sheet or attach parameters, leaving meaningful gaps for an agent choosing among many analysis tools.

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

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

Schema description coverage is 75%, which is not high enough to assume the schema fully compensates. The description adds no parameter-specific meaning: it does not clarify the sheet parameter (undocumented in schema), nor does it explain how attach or variables affect behavior beyond what the schema already states.

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: computes descriptive statistics from data read through COM, and lists the exact statistics returned. It is clear about what the tool does, but it does not differentiate itself from the sibling statistica_descriptives tool, which likely has overlapping 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?

There is no explicit guidance on when to use this tool versus alternatives such as statistica_descriptives or describe_spreadsheet. Usage is only implied by the tool name and output list, leaving the agent to infer the appropriate context.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does not say whether an existing file at `out` is overwritten, whether the source sheet is modified, or what permissions/state are required. The only behavioral hint is the implementation detail ('built-in CSV writer'), which is not operationally useful.

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 or repetition. It is appropriately sized, though its brevity is partly the source of the gaps noted in other dimensions.

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

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

For a file-writing tool with 4 parameters, 2 required, no annotations and no output schema, the definition omits overwrite semantics, sheet-selection behavior, and any post-call outcome. The agent has enough to attempt a call but not enough to predict its effect.

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 75%, below the threshold where the schema alone justifies a baseline 3. The description adds no parameter meaning at all, leaving the `sheet` parameter (string or integer, no description, no enum) 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?

The description states a specific verb and resource ('Export a sheet to CSV') plus the mechanism ('STATISTICA built-in CSV writer'), so the agent knows exactly what the tool produces. It does not explicitly distinguish itself from the sibling save_spreadsheet, which is the nearest alternative, so it stops short of a 5.

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

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

There is no guidance on when to use this instead of save_spreadsheet, nor any prerequisite such as the spreadsheet being open or the source file existing. The agent must infer the usage context from the name alone.

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

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

With no annotations, the description carries the full behavioral burden for a mutating import tool, yet it says nothing about overwrite behavior, required permissions, what happens to existing sheets, or how attach mode interacts with the running window. The schema parameter text covers attach somewhat, but the description itself adds only the .sta save note.

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

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

A single front-loaded sentence with no filler, stating purpose and the optional persistence outcome first. It is efficient, though its brevity is closer to under-specification than tight editing.

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

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

For an 8-parameter mutation tool with no annotations and no output schema, the description is too thin: it omits return value, failure modes, attach semantics, and how text-vs-Excel options differ. The schema covers parameter names, but the agent still lacks the surrounding context needed to invoke this confidently.

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

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

Schema description coverage is 100%, so all eight parameters are already documented in the schema, which sets the baseline at 3. The description adds no separator syntax, sheet selection, header-handling, or format details beyond what the schema already states.

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

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

States a specific verb (Import), the resource types (delimited text file or Excel workbook), and the destination (STATISTICA), plus the optional .sta persistence. It implicitly distinguishes itself from the reverse-direction sibling export_csv, but never names or contrasts siblings explicitly.

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

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

There is no when-to-use guidance, no exclusions, and no comparison to alternatives such as statistica_open or export_csv. The only hint is the word 'optionally', which implies but does not explain the save path decision.

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 return shape (id + name) and that the set is complete ('every'), but says nothing about whether the list is static or environment-dependent, its size, or ordering. For a zero-parameter read-only listing tool the risk surface is small, so this is adequate but thin.

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

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

One sentence, front-loaded with the verb and scope, with the returned fields and the consuming tool 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?

With no input parameters and no output schema, the description supplies the missing return contract (id + name) and the reason the tool exists (feeding run_analysis). It stops short of noting list stability or how to get each module's parameter schema, which describe_analysis presumably covers.

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; there are no argument semantics to explain. The description instead documents the output fields (id + name), which is a small bonus for a schema-less return.

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 ('List') and resource ('every analysis procedure exposed by STATISTICA') and names the returned fields (id + name). It also ties itself to the sibling run_analysis as the consumer of these ids, so an agent can distinguish it from generic info/describe tools 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 clause 'that can be driven with run_analysis' implies the intended workflow: enumerate valid module ids before invoking run_analysis. That is clear contextual guidance, but no explicit when-not-to-use or alternative (e.g., describe_analysis for a single module's parameters) 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 burden. It usefully discloses that no variable data is loaded (a cheap read) and what is returned, but says nothing about the live-editing/mutating implications of the attach parameter or permissions/process 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 zero filler; the most important scoping detail (no variable data loaded) is stated up front.

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

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

For a 3-param tool with no annotations and no output schema, the description covers the purpose and return fields but leaves the attach flag's live-edit side effects and any read-only safety expectation 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 100%, so the schema already documents path, sheet, and attach. The description adds nothing about any parameter, so baseline 3 applies.

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

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

States a specific verb (List) and resource (sheets inside a .sta/.stw file), and even names the returned fields (index, name, size). It contrasts itself with variable loading, but does not explicitly distinguish itself from siblings like describe_spreadsheet or read_variables.

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

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

The phrase 'without loading variable data' implies this is the lightweight metadata-inspection step before heavier operations, but no explicit when-to-use, prerequisites, or named alternatives are given.

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

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

With no annotations, the description carries the full burden. It usefully discloses vectorized numeric reads, string coercion for text, and null for missing values, which is real behavioral context. It omits any statement about side effects, permissions, or the effect of the `attach` parameter (which implies live-editing an app), leaving gaps for a tool that can touch a running process.

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

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

Three short, front-loaded sentences with no filler; the core action comes first and the type-handling caveats follow. Nothing is wasted, though the content is minimal rather than rich.

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

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

For a 6-parameter read tool with no annotations and no output schema, the description covers value semantics (vectorized, strings, nulls) but says nothing about the shape of the returned data or how to interpret it. Adequate but leaves an agent guessing about the result structure.

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 100%, so all six parameters are already documented in the schema. The description adds no parameter-level syntax or format detail beyond that baseline.

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

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

States a specific verb+resource ('Read variable values') that clearly separates it from write-oriented siblings like write_variables and add_variables. It does not, however, explicitly distinguish itself from describe_spreadsheet or describe_analysis, which an agent might reasonably confuse with reading values.

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

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

The description explains the mechanics of reading but gives no guidance on when to use this tool versus alternatives such as describe_spreadsheet, list_sheets, or export_csv. No prerequisites, no exclusions, no context cues.

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 the default-for-unlisted-values and missing-value-preservation behaviors. However, these largely restate schema field descriptions, and it omits key behavioral facts like whether the file is modified in place, what save/attach do to state, and whether the operation is reversible.

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

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

Two tight sentences, front-loaded with the verb and resource, and the optional default/missing behaviors follow logically. 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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the core recoding semantics but leaves the save/attach/sheet behavior and in-place mutation questions unaddressed. It is minimally adequate but incomplete for the tool's complexity.

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

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

Schema description coverage is 88%, so the schema already documents nearly every parameter. The description reinforces the map/default/missing interplay (keys compared as strings, unlisted vs missing handling) but adds little syntax or format detail beyond the schema baseline.

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

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

States a specific verb (recode) and resource (values of one variable) plus the mapping mechanism, so an agent immediately understands the operation. It does not explicitly differentiate itself from nearby siblings like set_formula, value_labels, or set_measurement, which also transform variable values.

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

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

The description explains the mechanics of recoding but gives no when-to-use guidance, prerequisites, or alternatives. With siblings such as value_labels and set_formula that could be confused for value transformation, the absence of routing guidance is a real gap.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says nothing about whether the edit is in-place or requires save, how attach interacts with the live instance, or what happens to unmapped variables. For a mutation tool with zero annotation coverage this is a significant gap.

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

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

A single front-loaded sentence with no wasted words. It is efficient, though it is arguably too sparse given the tool's behavioral burden rather than being overlong.

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

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

For a mutation tool with no annotations, no output schema, and nested rename maps, the description omits persistence, live-attach, and failure behavior. An agent cannot tell whether the source file is modified or whether save is required to keep results.

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 83% (high), so the baseline is 3. The description adds that renames/longNames are keyed by 'current variable name or index', reinforcing the map semantics beyond the schema's own text, but it does not clarify sheet, attach, or save behavior.

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 (Rename) and resource (variables), and additionally covers long-name changes, which distinguishes it from add_variables/delete_variables siblings by implication. It does not explicitly name an alternative, but the operation is unambiguous.

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

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

No when-to-use, when-not-to-use, or alternative-tool guidance is given. The phrase 'keyed by current variable name or index' hints at how arguments map, but nothing tells the agent when this tool is the right choice versus set_formula, write_variables, or recode.

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

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

With no annotations, the description carries the full burden. It does disclose substantive behavior: the step grammar (set/call/run/result/saveGraph), that results come back as tables, arrays or document handles, and which image formats saveGraph supports. It is silent on whether a run mutates the source spreadsheet, what happens on a failing step, and whether steps are atomic — meaningful gaps for a tool that executes arbitrary dialog operations.

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

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

Front-loaded with the purpose, then the step grammar, then the routing hint to describe_analysis. Dense but every clause is functional; the parenthetical examples and extension list all carry information. No filler sentences.

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

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

There is no output schema, and the description compensates by stating the return forms (tables, arrays, document handles). Combined with the step grammar and the describe_analysis pointer, an agent has enough to construct a call. Only error/failure semantics and the mutation footprint of a run are left 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 coverage is 83%, so the schema already documents most parameters. The description goes well beyond it for the critical 'steps' array, spelling out each step type and giving concrete examples (set/call/run/result/saveGraph) that the schema's one-line example does not, which is exactly the kind of added meaning that matters for the hardest parameter.

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

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

States a specific verb and resource ('Run ANY STATISTICA analysis') plus the mechanism ('executing an ordered list of steps against its dialog'). The word 'ANY' implicitly differentiates it from the specialized siblings (statistica_regression, statistica_t_test, statistica_anova), but it never names them, so the agent must infer the routing rule.

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

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

It directs the agent to describe_analysis for discovering property and method names, which is genuinely useful workflow guidance. However, it never says when to prefer this generic runner over the many pre-built analysis siblings, nor when-not to use it, so selection remains 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?

No annotations exist, so the description carries the full burden. It discloses the ActiveSpreadsheet binding and that the result can optionally be persisted, which is useful. But for arbitrary-code execution it omits side effects, process lifecycle (partly in the schema's 'attach' description), failure behavior, and any permission or safety caveats.

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

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

Two sentences, front-loaded with the action and execution context before the use-case scoping. No filler, though the parenthetical acronym list is dense and the sentence could be split for readability.

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

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

For a 6-parameter, annotation-free, code-executing tool with no output schema, the description covers purpose and the core binding but leaves behavioral risk (side effects, error handling, what happens to the active spreadsheet on failure) unaddressed. Adequate but with clear gaps.

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

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

Schema description coverage is 83%, so the schema already documents most parameters well. The description only adds the code-vs-source-file alternative and the optional nature of save, which the schema largely conveys on its own. Baseline 3 is appropriate.

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 (Execute) and resource (SVB source code / .svb file), and specifies the execution context (opened spreadsheet as ActiveSpreadsheet) plus the optional save step. The final sentence distinguishes it from the run_analysis family by naming its niche: custom recurrent models (DWLS/Lowess/EWPR) supplied as SVB macros.

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

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

Gives a clear when-to-use signal ('custom recurrent models ... supplied as SVB macros'), which is more than most siblings offer. It does not, however, state when NOT to use it or explicitly route to run_analysis for built-in modules, so the boundary is implied rather than enforced.

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 falls short: it says nothing about overwrite default behavior, whether the source sheet is modified, the attach/live-edit mode, or that this is a filesystem mutation. It repeats only the format-selection trait.

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

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

Two short sentences, zero filler, with the core action and the format rule front-loaded. Every clause carries information an agent needs.

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

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

For a file-writing tool with no annotations and no output schema, the description covers format selection but leaves the write semantics (default overwrite behavior, source-preservation via copy, live attach) entirely to the schema. Adequate but with clear behavioral gaps.

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

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

Schema coverage is already 83%, so the baseline is 3; the description earns above that by explaining the non-obvious rule that the extension drives the output format (.sta, .stw, .csv, .xlsx), which is not encoded in the schema and clarifies the 'out' parameter's meaning.

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

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

States a specific verb and resource ('Save a sheet to a new file') plus how the output format is chosen via file extension. It is clear on its own, but does not distinguish itself from the sibling export_csv, which plausibly overlaps for the .csv case.

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

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

No guidance on when to use this versus export_csv or the other export-style siblings. The only directional hint is implicit in 'to a new file', and there are no stated prerequisites or exclusions.

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

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

With no annotations, the description carries the full burden, and it does disclose that non-matching rows are dropped and all columns rewritten, signaling a destructive reshape. It stops short of stating whether the source file is modified in place or held in memory, and says nothing about permissions or recoverability; the live-editing behavior of 'attach' is only documented in the schema, not the description.

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 behavior and the destructive effect, with no filler. The second sentence is slightly redundant with the op enum, keeping it out of the top band.

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

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

For a 9-parameter mutation-style tool with no annotations and no output schema, the description is adequate but incomplete: it does not clarify the interaction between not specifying 'save' and the in-memory result, nor whether the source spreadsheet is altered, which matters for chaining with downstream tools.

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

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

Schema description coverage is 89%, so the schema already documents op, value, values, path, save, attach and keepCaseNames. The description's note that missing values are matched with op "missing" adds marginal semantic value but largely restates the enum, so the baseline 3 is appropriate.

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 and resource: it keeps only rows matching a condition and drops the rest, which is precise and differentiating from sibling data-shaping tools like sort_data or recode. However, it never names an alternative tool, so the sibling boundary is left implicit.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives. The only hint is that the tool supports numeric/text comparisons, which describes capability rather than directing the agent's choice among the many other data-manipulation siblings.

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

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

With no annotations, the description carries the full burden. It discloses useful traits: the formula is stored in the variable long name, the variable is recomputed, result values are returned for inspection, and attach edits a live instance without a new process. It omits save/permission semantics and what happens to the file when attach is false.

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

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

Three tight sentences with the core action front-loaded, followed by the storage/recompute detail and the attach guidance. No filler; each sentence earns its place.

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

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

For a mutation tool with no annotations and no output schema, the description compensates by stating that result values are returned and by explaining the attach behavior. Remaining gaps around persistence/permissions are minor given the rich schema.

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

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

Schema coverage is 86%, so the schema already documents nearly all parameters including the formula example. The description reinforces the formula syntax and explains attach's live-edit behavior, but adds little that the schema lacks. Baseline 3 is appropriate.

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 ('Assign a formula to a variable') plus the side effect ('recompute it') and where STATISTICA stores it. It is clearly distinguishable from siblings like recode or write_variables, though it never names an alternative explicitly.

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

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

Provides one concrete conditional ('Use attach=true to write into the running STATISTICA window'), which tells the agent when to attach vs. run detached. However it offers no guidance on when to choose this tool over siblings like recode or write_variables, so usage is only partially covered.

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 for what is a mutation tool. It does not say whether the change is persisted to the file, what happens without the optional save path, whether it requires an attached/running instance, or whether the change is reversible. Only the conceptual meaning of the setting is conveyed.

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, purpose front-loaded, no filler. Every clause adds information about what the tool does and why it matters.

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

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

With no output schema and no annotations, the description should carry more: for a 6-parameter mutation tool it omits persistence, attach/live-edit semantics, and failure modes. Purpose is complete, but operational context is not.

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 83%, so the baseline is 3. The description adds meaning beyond the schema by listing the measurement levels and explaining their analytical effect (factor vs covariate), clarifying what the 'type' parameter actually controls. It still omits any note on variable indexing or save behavior.

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 ('Set the measurement level of a variable') and enumerates the accepted levels. The second sentence explains the downstream consequence (factor vs covariate), which distinguishes it cleanly from siblings like rename_variables or write_variables.

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

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

The description explains WHY the setting matters (STATISTICA treats the variable as factor or covariate), which implies usage, but it never states when to call this tool versus alternatives or any prerequisites (e.g. file must be loaded, analysis must be configured). Usage is inferable but 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 full behavioral burden. It does disclose the critical destructive trait that shrinking discards excess cases/variables, which is genuinely useful. However, it says nothing about the attach/live-edit behavior, whether changes are reversible, or what happens to existing data when only one dimension is resized.

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

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

Two short sentences with zero waste; the core action is front-loaded and the second sentence adds only necessary destructive 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 mutation tool with no annotations and no output schema, the description covers the destructive consequence but omits the attach/live-edit implication and the persistence behavior of save. Enough to avoid surprise data loss, but not complete for a 6-parameter write operation.

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

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

Schema coverage is 50%: path, save, and attach are documented in the schema while cases, sheet, and variables are not. The description ties cases/variables to the grow/shrink semantics, adding some meaning, but says nothing about sheet selection or how save/attach interact with the resize.

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

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

States a specific verb (resize) and resource (spreadsheet) and clarifies the two directions of the operation, growing vs shrinking. It doesn't name siblings like add_variables or delete_variables, so an agent must infer the distinction from the field names 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?

No guidance on when to use this instead of add_variables, delete_variables, or add_variables/delete_variables pairs. The growing/shrinking semantics are implied but no condition, prerequisite, or alternative tool is mentioned.

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 behavioral burden and does disclose two useful traits: the sort mutates the source 'in place', and case names travel with their rows. It stops short of covering permissions, whether the original is left untouched, or how persistence interacts with the 'save' parameter.

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

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

Two tight sentences, with the core operation front-loaded and the order semantics appended. Every clause 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?

For a 6-parameter mutation tool with no annotations and no output schema, the description covers the core operation and order semantics but leaves sheet, attach, and save behavior to the schema. Adequate but with visible gaps.

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

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

Schema coverage is 83%, so the schema already documents parameters like order and variables. The description restates the order semantics (single value or one per key, 0/asc vs 1/desc), reinforcing but not exceeding what the schema provides. Baseline 3 is appropriate.

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 (sort) and resource (spreadsheet) with scope qualifier 'in place'. The purpose is unambiguous and no sibling tool competes for the same operation, though the description doesn't explicitly differentiate itself from list/export siblings.

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

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

No guidance on when to use this versus alternatives such as export_csv or describe_spreadsheet, and no stated prerequisites. The 'in place' phrasing implies source mutation but the description never tells the agent when sorting is the right call.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose the return artifacts (ANOVA table / UnivariateResults plus parameter estimates), which is genuine behavioral information, but says nothing about side effects, whether the live workbook is modified, or what happens when `attach` is used.

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 method and module, then the key parameter meanings, then the return value. No filler or repetition; every sentence carries information.

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

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

For a 6-parameter analysis tool with no annotations and no output schema, the description covers the essentials of what comes back but leaves the file/sheet parameters, side effects on the running STATISTICA instance, and model-building defaults to inference from the schema alone.

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

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

Schema coverage is 67%; `attach` and `method` are already documented in the schema, and the description's gloss on `dependent` ('the outcome') and `between` ('factor/covariate effects') largely restates the schema while adding the covariate nuance. `path` and `sheet` remain undocumented in both places.

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

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

States a specific statistical verb and resource (analysis of variance via General Linear Models, module 4100) and names the key variables. It is readily distinguishable from siblings such as statistica_regression, statistica_t_test and statistica_correlation 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?

Usage is only implied by the statistical method name: an agent that knows ANOVA infers it is for comparing means across factor levels. The description never states when to prefer it over statistica_t_test or statistica_regression, and gives no prerequisites or exclusions.

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

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

With no annotations, the description carries the full burden. It helpfully discloses the outputs (cluster membership, amalgamation schedule, descriptive statistics), but says nothing about permissions, whether it mutates the spreadsheet, whether a running instance is required, or side effects.

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

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

Two tight sentences, front-loaded with the operation and followed by inputs and returns. Zero 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 statistical analysis tool with no annotations, no output schema, and half the parameters undocumented, the description covers purpose and outputs but omits input meaning (path/sheet), prerequisites, and any behavioral caveats.

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 only 50%, so the description should compensate. It merely restates the schema's own wording for `variables` ('the variables to cluster') and says nothing about `path` or `sheet`, both of which remain entirely undocumented.

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

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

States a specific verb+resource: 'Hierarchical cluster analysis', which clearly separates it from sibling analyses like statistica_factor, statistica_anova and statistica_regression. The module number adds precision. It does not explicitly name an alternative sibling, but the resource 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?

No when-to-use guidance, no exclusions, and no routing to or away from sibling analysis tools (e.g., factor vs cluster). The agent must infer the context from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden and it is essentially silent. It does not say where results go (attached sheet, new output, console), whether the process is blocking, what happens with missing data or non-numeric columns, or whether the existing STATISTICA instance state is modified. The one behavioral clue — 'attach' in the schema — is undocumented by the description itself.

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 zero waste and the resource front-loaded. It is appropriately sized, but its brevity is achieved by omission of substance rather than by economy.

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

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

For a 4-parameter analysis tool with no annotations, no output schema, and 25% schema coverage, the definition is essentially a one-line label. Nothing tells the agent how to invoke it correctly, how results are returned, or how it differs from the near-identically named sibling statistica_correlation_matrix. It is not adequate to drive 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 only 25% (only 'attach' is described, and that is in the schema, not the description). The description adds no meaning at all: it does not explain 'variables' selection semantics, what 'sheet' accepts, or how 'path' relates to the running instance. With three undocumented parameters, 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?

The description states a specific computation ('Pearson correlation matrix') and its engine ('STATISTICA Basic Statistics module'), which distinguishes it from the sibling statistica_correlation_matrix only weakly — the two names suggest near-identical purpose, and the description gives no basis for choosing between them. For an agent facing both tools, this is a real gap, but the verb+resource is still concrete.

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

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

No guidance on when to use this tool versus the sibling statistica_correlation_matrix, or the broader statistica_regression/statistica_factor tools that also consume correlation matrices. No prerequisites, no mention of required data shape. The agent must infer everything from the name alone.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that new variables are created (a mutation) with predictable names, that smoothing is optional, and that only a preview is returned. It does not say whether results are committed to the active spreadsheet, whether existing variables are overwritten, or what permissions/state are required, which are meaningful gaps for a write-style tool.

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

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

Front-loaded with the purpose and mechanics in one dense sentence, followed by a short mode hint. No filler, and every clause contributes information. Slightly dense but appropriately sized for an 8-parameter 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?

Given 8 parameters, no annotations, and no output schema, the description adequately explains what is produced (and that only a preview is returned, so no output schema needed) but leaves side-effect and state-management questions unanswered. It is minimally sufficient rather than complete for a mutating spreadsheet operation.

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

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

Schema description coverage is 75%, so most parameters carry their own documentation and the baseline is 3. The description reinforces the meaning of lags (1..lags -> Lag1..LagK), the product formula, smoothing, and the shift mode, but adds nothing for path, sheet, attach, or prefix beyond what the schema already states.

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

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

States a concrete verb and resource with mechanical detail: it 'builds lagged series products', creates variables 'Lag1..LagK holding x(t)*x(t-lag)', optionally smooths, and returns a preview. This is specific enough for an agent to know exactly what the tool constructs. It does not, however, name or differentiate against plausible siblings such as add_lag_column or statistica_correlation, and the name 'correlation_matrix' does not match the described behavior, which slightly undercuts disambiguation.

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

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

'Use mode "shift" for plain lagged series' gives a real selection rule for one parameter mode, and the default product mode is implied. But there is no guidance on when to use this tool versus add_lag_column or statistica_correlation, nor any prerequisites such as whether the spreadsheet must be open. Usage is implied rather than framed as when/when-not.

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

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

No annotations are provided, so the description carries the full burden. It notes the computation happens in the STATISTICA engine (Basic Statistics module), hinting at a heavier operation, but says nothing about whether the app is opened, permissions, performance, or what the operation affects. The related 'attach' parameter behavior is left undocumented in the description.

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

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

A single front-loaded sentence that states the purpose and the distinguishing trait without waste. Efficient and readable.

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

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

With no annotations and no output schema, the description should disclose more about the operation's behavior and output, but it only covers what the tool computes. The core purpose is conveyed adequately, leaving moderate gaps around behavior and return content.

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

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

Schema description coverage is 75%, with 'path', 'attach', and 'variables' documented in the schema, while 'sheet' has no description. The description adds no parameter-level meaning beyond the schema, which is an acceptable baseline given the reasonably high coverage.

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

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

States a specific verb+resource (descriptive statistics computed by the STATISTICA engine) and adds a distinguishing qualifier that it provides statistics the JS shortcut does not. It does not name the 'descriptives' sibling explicitly, referring to it only as 'the JS shortcut', so the differentiation is slightly oblique but present.

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 'including ones the JS shortcut does not provide' implies this tool should be chosen over the lightweight 'descriptives' when fuller engine output is needed, but no explicit when-to-use or when-not-to-use condition is stated. Usage must be inferred.

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 that a dialog is opened in the running STATISTICA window and captured to an image, and hints at a two-level panel structure, but omits side effects (does opening a dialog mutate state? does the process persist?) and whether the capture can fail if the window is not present.

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 action front-loaded and the one usage hint placed at the end. Efficient, though the parenthetical example list is slightly cluttered.

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

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

For a 10-parameter tool with a nested properties object and no output schema, the description covers the core flow but says nothing about the mode/attach/title/path parameters or what the returned image represents. The high schema coverage compensates, but the description is thinner than the tool's complexity warrants.

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 90%, so the schema already documents nearly all parameters. The description's only added semantic is the `run:true` behavior, which the schema already explains ("Call Run before capture (to reach the Transformations panel)"). Baseline 3 is appropriate given the schema does the heavy lifting.

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 ("Open an analysis module dialog ... and capture the actual setup panel to an image") with concrete examples (Time Series/Forecasting, Transformations tabs). It is clear what the tool does, but it never distinguishes itself from the sibling statistica_screenshot, which appears to be a very similar capture operation.

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

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

The note "Use `run:true` to advance to the second-level panel" gives implied usage for one parameter, but there is no guidance on when to choose this over statistica_screenshot or how it relates to the open/run_analysis siblings. Usage is inferable 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. It usefully discloses the default extraction method and the returned outputs (eigenvalues, loadings, communalities), but says nothing about side effects, whether results are written back to the spreadsheet, or the new-process behavior of the tool.

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

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

Three tight sentences with the core purpose front-loaded, followed by the default method and return values. 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?

There is no output schema, but the description partially covers return values. However, for a 6-parameter analysis tool with no annotations, gaps remain around prerequisites, side effects, and how path/sheet/variables interact — more context is warranted.

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 only 50%. The description restates the method default and the factors count, both of which are already documented in the schema, and adds nothing for path, sheet, or variables. It does not fully compensate for the undocumented parameters.

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

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

The description names a specific analysis (factor analysis / principal components) and even ties it to module 2101, making it immediately distinguishable from siblings like statistica_cluster or statistica_correlation_matrix. An agent can select this tool without opening the schema.

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

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

Usage is implied by the analysis name but there is no explicit when-to-use or when-not guidance relative to alternatives such as statistica_cluster or statistica_correlation_matrix. It also does not state prerequisites (e.g., data must already be loaded, numeric variables only).

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 doesn't state whether the tool modifies the spreadsheet, whether it requires an open workbook, whether results are written back or returned, or what happens to the 'attach' workflow. It only says the computation is done 'by the STATISTICA Basic Statistics module,' which adds little behavioral context.

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

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

A single, tight sentence with no filler. It's front-loaded and wastes no words, though it is arguably too sparse given the surrounding context.

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

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

Four parameters with 25% schema coverage, no annotations, no output schema, and a crowded set of statistical siblings. The description is far too thin to let an agent invoke this correctly without opening the schema and guessing about the many near-neighbors.

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 only 25% (only 'attach' has a description), so the description should compensate for the undocumented path, sheet, and variables parameters. It doesn't mention any parameter at all — no hint that 'path' is required, that 'variables' selects which columns to tabulate, or that 'sheet' picks the worksheet. A significant 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 resource (frequency tables and histograms) and attributes them to the STATISTICA Basic Statistics module, which distinguishes it from descriptives or statistica_descriptives. However, it doesn't clearly state the action verb (compute/generate) and gives no indication of what the output looks like or how it differs from statistica_descriptives or descriptives beyond the output type.

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 whatsoever. With nine sibling tools that are all statistical analyses (regression, t-test, anova, correlation matrix, etc.) and two near-neighbors named 'descriptives' and 'statistica_descriptives', the agent has no signal for choosing frequencies over those 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 does disclose useful behavior (graph is built, export is optional, properties are set as dialog options before building), but says nothing about process lifecycle, permissions, whether an existing graph window is replaced, or what is returned after the build completes.

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 first sentence front-loads the core action and the export side effect; the following clauses pack parameter guidance without filler. It is slightly list-heavy but every sentence earns its place.

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

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

For a 7-parameter, nested-object tool with no annotations and no output schema, the description covers the main calling mechanics well but omits what the call returns (a graph object? a path?), whether STATISTICA must be running, and how failures behave. Adequate but with visible gaps.

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

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

Schema coverage is 71% with 7 parameters including a nested object. The description adds real meaning beyond the schema: the 'x | y' module variable syntax, the enumeration of common module IDs (11003, 11012, 11002, etc.), and concrete property keys (GraphType, FitType, ShowRawDataPoints). Only path and sheet remain undocumented anywhere.

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 ('Build a STATISTICA graph') plus the optional export side effect, so an agent knows exactly what it produces. It does not, however, distinguish itself from siblings that also emit graphics (statistica_screenshot) or from run_analysis, so it stops short of full sibling differentiation.

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

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

The module list and 'x | y' variable syntax imply when this tool is appropriate, and 'optionally export it to an image file' hints at the out parameter's role. There is no explicit statement of when to prefer this over statistica_screenshot, run_analysis, or statistica_dialog, and no prerequisites (e.g. whether STATISTICA must be open).

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 the nature of the operation (a read-only diagnostic reporting three specific values) and the failure-troubleshooting scenario, so an agent understands it is a safe health check. It does not mention timeout behavior or what happens if STATISTICA is absent, keeping it just short of a 5.

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

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

Two short sentences, front-loaded with what is reported and followed by the trigger for use. Every clause earns its place; there is no filler.

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

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

For a zero-parameter diagnostic tool with no output schema, the description must convey the return values, which it does (availability, version, path), plus when to invoke it. Nothing an agent needs to call it correctly is missing.

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

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

The tool takes zero parameters, which maps to the baseline of 4. There is nothing to document, and the description does not need to compensate for anything.

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 precisely names the resources returned: COM availability, version, and executable path. This clearly distinguishes it from the statistica_* analysis and data-manipulation siblings, which perform statistics rather than diagnostics.

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

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

Gives explicit context for use: 'Run this first if STATISTICA operations fail,' which is a clear trigger condition. It stops short of naming specific alternative tools (e.g., statistica_open) or stating when NOT to use it, but the guidance is actionable.

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 analytical outputs but says nothing about side effects: whether it opens new output windows, writes result nodes into the spreadsheet, requires a live STATISTICA session, or has runtime limits. For a tool whose 'attach' parameter implies process-level behavior, this is a notable 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 dense sentence that front-loads the resource and then lists the concrete outputs. No filler, no repetition of the tool name. Slightly terse for the amount of structured behavior left unexplained, but structurally 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?

With no output schema, the description usefully enumerates the returned contents (summary plus two named tests plus a histogram), which is real value. However, with 5 parameters, 2 required, and no annotations, it omits input expectations and runtime/side-effect behavior, leaving meaningful gaps for an agent to call it correctly.

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

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

Schema description coverage is 40% (only 'attach' and 'intervals' are documented). The description adds no parameter meaning whatsoever, leaving 'path', 'variables', 'sheet', and the required-vs-optional distinction for the agent to guess from bare types. It does not compensate for the coverage shortfall.

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

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

States a specific resource ('normality diagnostics') and enumerates exactly what is produced: descriptive summary, Shapiro-Wilk W, Kolmogorov-Smirnov/Lilliefors, and a histogram. This distinguishes it from broad siblings like statistica_descriptives or statistica_frequencies, though it never explicitly names or contrasts with those alternatives.

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

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

The description explains what the tool computes but gives no when-to-use guidance, no prerequisites (e.g., whether a STATISTICA instance must be running, whether data must be loaded), and no routing against the many sibling analysis tools. The agent must infer selection entirely from the tool name.

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

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

With no annotations, the description carries the full burden and does disclose the key stateful traits: the window is visible and persists across calls without start/stop cycling. But it references an undocumented 'attach:true' parameter, which is misleading about how the persistence is actually invoked, and it says nothing about how the window is shut down.

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 primary action and followed by the lifecycle clarification. No filler, and the most decision-relevant information (visible window, persistent) comes first.

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-annotation, no-output-schema launch tool the description covers purpose and persistence reasonably. The gaps are the dangling 'attach:true' reference (not a schema parameter) and the absence of any shutdown/cleanup guidance, which an agent managing a long-running GUI application would need.

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

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

Schema description coverage is 100%, so both 'path' and 'sheet' are already documented in the schema and the baseline is 3. The description's only parameter-relevant statement ('optionally opening a file') merely echoes 'path', and its mention of 'attach:true' refers to a parameter absent from 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 ('Launch a visible STATISTICA window') plus the optional file-open behavior, so an agent knows exactly what the tool produces. It does not need sibling differentiation since no sibling launches the application, though it also does not contrast itself with the analysis/export siblings.

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

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

It implies the intended lifecycle ('leave it running', then edit the same window on subsequent calls instead of restarting), which is real usage guidance. However, the instruction hinges on a parameter ('attach:true') that does not exist in the schema, and there is no guidance on when to close or re-launch.

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 names the underlying STATISTICA module but says nothing about whether a new process is spawned, what permissions/data state it requires, or what the result looks like; the critical live-edit caveat lives only in the `attach` schema description.

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?

Brief, but the rhetorical 'The first predictor list entry is the dependent variable? No:' reads as a confused self-correction rather than front-loaded guidance, costing clarity for an agent scanning the 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?

With no annotations, no output schema, six parameters, and only 67% schema coverage, the description should explain return/behavior context (outputs, attached-instance semantics, model method effects). It instead spends its budget restating parameter roles already in the schema.

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

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

Schema coverage is 67%, so several parameters are already documented. The description's clarification of `dependent` vs `predictors` largely restates what the schema already says ('Dependent (outcome) variable'), adding only marginal value and no detail on `method`, `sheet`, or `path`.

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: multiple linear regression via STATISTICA General Regression Models. It does not distinguish itself from siblings like statistica_anova or statistica_correlation, but the statistical operation is unambiguous.

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

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

No when-to-use guidance, no prerequisites, no routing to alternatives such as statistica_correlation for association or statistica_anova for group comparison. The agent must infer that this is the tool for predictive modeling.

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, so the description carries the burden; it usefully discloses that content is prepared while hidden and the window is only shown at capture time. However, it omits side-effect details such as whether a new STATISTICA process is launched and left open by default (only the attach parameter hints at this).

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 primary action and workflow, no filler. Efficient, though the second sentence slightly restates the hidden/shown sequencing already implied.

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

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

For an 11-parameter tool with 91% schema coverage and no output schema, the description adequately conveys the overall operation. Minor gaps remain around process lifecycle and what the returned image reference is, but the schema covers the call surface well.

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 91%, so the schema already documents nearly all parameters (mode enum, waitMs default, attach semantics). The description adds only the high-level build-then-capture framing and no parameter-specific detail beyond what the schema provides.

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 (capture) and resource (STATISTICA main window to PNG/JPG), plus the preparation step. It is distinguishable from siblings like statistica_graph or run_analysis, though it doesn't explicitly name a sibling it should be preferred over.

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

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

Implies usage via 'for a report' and describes the build-then-capture flow, giving an agent a sense of when it fits. But it never states when to prefer this over statistica_graph/statistica_dialog or notes prerequisites for the run/module path.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it falls short: it never says whether this mutates the spreadsheet, creates new variables/columns, requires a running STATISTICA instance, or what happens to existing data. It adds only the single-series scope constraint, which is useful but far from sufficient for a 25-parameter 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?

Front-loaded with the module identity, then the procedure enumeration, then the single-series constraint. Tight and waste-free, though the long inline procedure list makes the middle sentence dense.

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

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

For a 25-parameter tool with no annotations and no output schema, the definition covers procedure selection well but omits side effects, return shape, and instance requirements. Adequate as a minimum-viable router but leaves real gaps an agent would need to fill.

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 92%, so the schema already documents nearly every parameter (lag, lags, alpha, arOrder, model, etc.). The description adds the cross-cutting rule that autocorrelation/partial_autocorrelation/spectral/smoothing/differencing/descriptives operate on one series, but no format or syntax detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific resource ('Time Series / Forecasting module') and enumerates the eleven procedures, which clearly separates it from siblings like statistica_regression, statistica_anova, and statistica_correlation. It does not name an alternative tool directly, but the domain 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 description lists what procedures exist but gives no when-to-use guidance, no prerequisites, and no comparison to overlapping siblings such as add_lag_column (which resembles the 'shift' procedure) or statistica_correlation. The only routing hint is the single-series note.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it mostly does not. It never says whether the analysis mutates the spreadsheet, what it writes or returns, whether a running STATISTICA instance or a license is needed, or what the `attach` behavior implies for side effects — all notable gaps for a tool that drives an external application.

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, zero filler, and the purpose is front-loaded before the mode-specific detail. Every clause carries information an agent needs to pick a `kind`.

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

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

For a 7-parameter analysis tool with no annotations and no output schema, the description covers the core semantics but omits what the tool does to the workbook, what results come back, and any preconditions for running an analysis. It is minimally viable rather than complete.

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

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

Schema description coverage is 71%, so the schema already documents most parameters, and the description's added semantics for `kind` and `variables` (pairs of 2, 4, ... entries) largely restate the enum and array descriptions. It adds no information about `path`, `sheet`, `attach`, `summary`, or `constant`, so it does not compensate for the coverage gap. Baseline 3 is appropriate.

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

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

The description names a specific verb+resource ('Student t-tests') and goes further by defining what each value of the `kind` parameter actually computes (means vs. a constant, paired comparisons over listed variables). This distinguishes it clearly from statistical siblings such as statistica_anova, statistica_correlation, and statistica_normality.

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

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

It gives clear conditional context for the main decision — which test to run — by spelling out the scenario behind each `kind` value. However, it offers no exclusions or named alternatives (e.g., use ANOVA for >2 groups, or a different tool for independent-samples comparisons), so it falls short of the explicit when/when-not bar.

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, so the description carries full burden. It discloses the semantics of `clear` (removes existing labels first) and the label value format, which is genuinely useful. However, it is silent on permission requirements, whether live attachment is destructive, whether labels persist without a `save` path, and the return/acknowledgement behavior — for a mutation tool with no annotations, that leaves significant gaps.

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

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

Two sentences, front-loaded with the primary operation and followed immediately by the two key parameters. No filler, every clause earns its place.

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

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

Given no annotations and no output schema, the description covers the core mechanics but omits critical operational context: what 'attach' means for concurrency/side effects, whether labels persist without `save`, and what happens on invalid value/label mappings. Adequate but with clear gaps for a 7-parameter mutation tool.

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

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

Schema coverage is 86% — the schema already documents `path`, `save`, `clear`, `attach`, `labels`, and `variable` in detail. The description adds the shape of `labels` values (string or {label, description}) and the meaning of `clear` ordering, but does not add anything for the other parameters. Baseline 3 is appropriate when schema does the heavy lifting.

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 ('Attach or clear text labels') plus precise resource ('numeric values of a variable'). Clearly distinguishable from siblings like set_measurement, recode, or rename_variables, which operate on different aspects of variables.

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?

Implicitly states two modes (attach via `labels`, clear via `clear`) but does not explicitly say when to prefer live-editing ('attach') versus a new process, nor when to use this versus recode; no when-not guidance or alternatives 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?

With no annotations, the description carries the full behavioral burden and does notable work: 'Changes are only persisted if save is given' discloses the persistence/no-op behavior, and the numeric vs text value rules ('shorter arrays leave the rest untouched') describe partial-write semantics. It still omits any auth/permission or return-value context.

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

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

Four tight sentences, front-loaded with the core action and with zero filler; each sentence yields a distinct behavioral rule. Slightly dense but appropriately sized for the operation.

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

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

For a 5-param mutation tool with no annotations and no output schema, the description covers the highest-risk semantics (persistence, per-row value alignment). Remaining parameters (sheet, attach, path) are well covered in the schema, so the description need not repeat them.

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 100%, so baseline is 3, but the description adds meaning the schema lacks: exactly-one-value-per-case for numeric columns, null handling, and that text arrays shorter than the column leave remaining rows untouched. It also reinforces that save governs persistence.

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: 'Overwrite whole variables in a spreadsheet.' This clearly distinguishes it from add_variables, rename_variables, and read_variables by intent, though it never names a sibling explicitly to route the agent.

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

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

Usage is implied by 'overwrite' (existing variables only, versus add_variables), and the numeric/text value rules hint at application context. However, there is no explicit when-to-use statement, no alternatives named, and no prerequisites (e.g., a running STATISTICA instance for attach).

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