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

With no annotations, the description carries the full burden and does well: it discloses where output lands (cache, not model folder), the return shape (ok and build time, or file:line: message errors), and the no-op-if-unchanged caching behavior. It does not mention permissions or whether any artifacts can be invalidated.

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, front-loaded with the action and artifact, followed by return values and caching semantics. Every sentence earns its place with 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?

No output schema exists, so the description rightly explains the return values and error format. For a two-parameter tool with no annotations, the only real gap is documentation of the 'group' parameter, which leaves the definition slightly short of fully self-contained.

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

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

Schema description coverage is 0% and the description never mentions the parameters. 'model' is arguably implied by 'the model's equation file', but 'group' is completely undocumented in both schema and description, leaving the agent to guess its role.

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 (Compile) and resource (the model's equation file) with a concrete output artifact (headless LSD program). It is not confusable with siblings like write_equations or run_configuration, though it does not explicitly name an alternative.

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

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

No explicit when-to-use guidance or prerequisites. It does not say when compilation is needed relative to write_equations or run_configuration, nor when to skip it. The incremental-build note hints that repeated calls are safe but is behavioral, not usage routing.

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 well: it enumerates excluded artifacts (binaries, results, backups, design configurations, sa folders) and states the failure mode when `name` exists. It omits permissions, side effects on the source, and any rate/limits, but the mutation semantics are reasonably disclosed.

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

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

The action is front-loaded and packed into a single tight sentence with a scoping parenthetical; nothing is wasted, though the nested exclusion list slightly buries the destination and failure clause.

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

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

No annotations and no output schema, so the description must cover behavior and returns. It covers what gets copied and the failure condition, but never states what the tool returns (new path/name) or explains source_group, leaving gaps for a 3-parameter tool.

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

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

Schema description coverage is 0%, so the description must compensate. It explains `name` (the destination name) and implies `source`, but `source_group` (default 'examples') is never mentioned, leaving a required-understanding parameter undocumented.

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

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

The description gives a specific verb+resource (copy a model folder) and adds precise scope detail about what is and isn't copied, plus the destination and name. It implicitly distinguishes itself from create_model ('copy ... so it can be edited') but never names a sibling explicitly.

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

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

'so it can be edited' implies the intent context, and 'Fails if `name` exists' hints at a precondition, but there is no explicit when-to-use vs alternatives (e.g., versus create_model) or when-not to use it.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the side effects (which files are created: fun_<name>.cpp, model_options.txt, modelinfo.txt, description.txt, Sim1.lsd), the naming constraint (must not exist or lie inside another model), and that an empty model compiles and runs without computing.

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

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

Front-loaded with the core action and the generated-file list, then the workflow. Dense and mostly waste-free, though the file enumeration and workflow step run somewhat long for a creation 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?

No output schema or annotations exist, but the description compensates by covering the created artifacts, naming constraints, and downstream workflow. A brief note on the return value or error behavior on name collision would make it fully complete.

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

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

Schema coverage is 0%, so the description must compensate. It fully explains `name` (the folder name, allowed characters, existence/nesting constraint) but says nothing about `title` or `description` parameters; description.txt is mentioned as a file but not linked to the `description` 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 ('Create') and resource ('new, empty model folder in the models folder') and enumerates exactly what files are generated. It is clearly distinguishable from sibling creation tools like copy_model or sa_create_design.

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 chains the next steps ('Then use edit_structure to add objects, parameters and variables, write_equations for the equations, set_saved if needed, and run_configuration'), naming the exact siblings and the order, so an agent knows this is only the first step of a pipeline.

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 reasonably well: it discloses that values collapse to a single number when all instances are equal and otherwise report min/max/count, and that certain attributes appear only conditionally. It never explicitly says the operation is read-only or side-effect free, but the detail about returned content is above the annotation-free baseline.

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

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

The description is dense but front-loads the core purpose (what gets described) before the parameter guidance, and most sentences carry real information. The conditional-attributes sentence is somewhat confusing and could be trimmed, but there is little outright waste.

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

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

There is no output schema, so the description must explain the return shape, which it does thoroughly for a complex config-inspection tool. Gaps remain around the group/model parameters and the read-only nature, but an agent has enough to call it correctly for most cases.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: config is explained as the file name with or without '.lsd', object selects a single object, and detail='names' alters output granularity. group and model are left unexplained, and the 'Set only when they apply: computed=false ... debug, plot, parallel, saved_separately' sentence ambiguously mixes output attributes with settable fields.

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

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

The description states a specific verb ('Describe') and resource ('.lsd configuration') and enumerates exactly what is returned: the object tree with instance counts, per-element type/lags/saved flag/value summaries, and run settings. This is clearly distinguishable from siblings like read_equations, read_results, or list_models.

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 practical guidance for large models ('pass object=Name ... or detail=names'), which is useful invocation context, but never states when to prefer this tool over alternatives such as read_equations or read_results, nor any exclusions. Usage is implied through parameter selection rather than explicit routing.

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 so richly: atomic all-or-nothing application, failure naming, file write behavior with .bak backup, label validation, uniqueness constraints, instance copying/removal semantics, and LSD save layout changes. These are exactly the mutation and side-effect details an agent needs before invoking it.

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 purpose is front-loaded, and the remaining length is justified by the complex operation vocabulary and file side effects. Examples are compact and each sentence adds necessary detail rather than repeating schema or annotations.

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 high-complexity mutation tool with no annotations, no output schema, and no schema descriptions, the description is nearly complete. It omits an explicit success-return description and does not define the `model` parameter, but otherwise covers operation semantics, failure behavior, naming rules, and file side effects 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 description coverage is 0%, so the description must explain all four parameters. It exhaustively documents the `operations` parameter with examples, and indirectly clarifies `config`/`new_config` file behavior, but it never defines the required `model` 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?

The description states a specific verb and resource: 'Change a configuration's structure' and then enumerates the exact structural elements affected. It also distinguishes itself from write_equations by saying equations are not touched and must be handled separately.

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 structural changes and explicitly routes equation edits to write_equations. However, it does not compare against several sibling tools such as set_values or set_saved, leaving some routing decisions to inference.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: the 'examples' group is read-only, while 'models' is the user's own folder, and it enumerates what is returned for each entry. It stops short of covering edge cases such as empty folders or malformed models.

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 dense sentences, front-loaded with the action, with no filler. The return-field enumeration is somewhat long, but each element is informative and the group semantics come before it.

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

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

An output schema exists, so the explicit list of returned fields is partly redundant, but the description still supplies the domain framing (what a model is, what the two groups mean) that the schema cannot. For a simple read-only list tool this is close to sufficient, missing only failure or empty-result behavior.

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

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

Schema coverage is 0% and the single 'group' parameter has no enum, yet the description fully documents both meaningful values and their backing folders, effectively supplying the enumeration the schema lacks. An agent can select a value correctly without any additional source.

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

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

States a specific verb and resource ('List models') and goes further by defining what a model actually is (a folder with a fun_*.cpp equation file and at least one .lsd configuration). That definition usefully separates it from siblings like describe_configuration or read_equations, though no sibling is named explicitly.

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

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

Usage is implied rather than stated: the group values tell the agent which folder it is browsing, and the '(read-only)' note hints that 'examples' is for inspection only. There is no explicit guidance on when to reach for this versus describe_configuration or read_equations.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does add real behavioral context by noting that LSD's command-line utilities are built automatically on first use, which tells the agent about a side effect of other operations. However, it does not state that lsd_status itself is read-only/non-mutating, nor how quickly it returns or what it does if components are missing.

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?

It is a single front-loaded sentence beginning 'Show the setup:' followed by a clean enumerated list of checks, so an agent gets the essentials immediately. The awkward line wrapping and slightly run-on structure cost a point but no sentence is wasted.

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

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

With no output schema, the description effectively stands in for one by enumerating the fields the agent will see (source root/tag, models folder, compiler status, utility build state, R availability). That is sufficient for a zero-parameter diagnostic tool, though finer detail on result format or failure signaling is absent.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. Schema coverage is 100% for an empty object, consistent with no per-argument documentation being needed.

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

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

The description gives a specific verb ('Show the setup') and enumerates exactly what is reported: LSD source root/tag, models folder, C++ compiler presence, CLI utility build state, and R/Rscript availability. This makes the tool's function unmistakable. It stops short of naming sibling tools like describe_configuration or list_models for explicit differentiation, though the enumerated content is distinct enough in practice.

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

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

Usage is only implied: the mention that utilities are 'built automatically on first use' hints this is a pre-flight/diagnostic check, but the description never states when to call it (e.g. before compiling or running a configuration) or what alternatives exist. Adequate but leaves the agent to infer the trigger condition.

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 burden. The verb 'Return' and the file-resolution explanation make the read-only nature evident, and it explains the multi-file lookup behavior. However, it says nothing about failure modes (missing model, invalid file name) or any access constraints, so a middle score is warranted.

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 behavior and followed by the conditional multi-file case. The parenthetical detailing EQUATION(...) blocks earns its space by telling the agent what the returned text actually looks like. Slightly long second sentence but no filler.

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

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

An output schema exists, so return values need no explanation, and the main invocation path (model, plus file for multi-file models) is fully covered. The one gap is the `group` parameter, which is never mentioned and has 0% schema documentation, leaving the agent to guess at its role.

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

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

Schema description coverage is 0%, so the description must carry the parameters. It adds real meaning for `file` (accepted extensions .cpp/.h/.hpp, no path allowed), which the schema does not convey. But `group` (default 'models') and `model` are left entirely undocumented, so it only compensates for a third of the 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?

States a specific verb and resource ('Return the text of the model's equation file') and pins down exactly what kind of content comes back (the C++ source with EQUATION(...) blocks). It is clearly distinguishable from siblings like list_models, write_equations, and read_results.

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 routes the agent: multi-file models list their equations as source_files in list_models, and those plain file names should be passed as `file`. That is a concrete when-to-use rule tied to a sibling tool's output, though the read-vs-write relationship with write_equations is only implied by the name.

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

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

With no annotations, the description carries the full burden and does well: it discloses the 50-series cap, the even thinning behavior driven by max_points, the row-0-is-initial-values convention, and the constraints start <= end and max_points >= 1. It omits error behavior (missing/uncompiled model) and confirms nothing explicit about read-only safety, which keeps it from 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?

Front-loaded with the core action, then dense per-parameter guidance with no filler. Every clause carries usable information; the only minor cost is that the parameter notes run together as a long semicolon chain rather than being visually separated.

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-param tool with no annotations and no output schema, the description covers the time-axis semantics, filtering, thinning, and the return-size limit. It does not describe the shape of the returned series, which is the main remaining gap given the absence of an output schema.

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

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

Schema description coverage is 0%, so the description must compensate, and it explains variables (name or name+instance), start/end (row number = time step, row 0 = initial, start <= end), and max_points (thinning target, >=1). Only 'model' and 'results_file' lack explicit semantics, though both are largely self-evident from the opening sentence.

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?

Opens with a specific verb+resource: 'Read time series from one result file (.res.gz) in the model folder.' The file type and location are concrete enough to distinguish it from siblings like read_equations or list_models. It stops short of explicitly naming an alternative tool, but the purpose is unambiguous.

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

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

Usage is implied (inspect simulation output stored in a .res.gz file), but there is no explicit when-to-use/when-not guidance and no named alternatives among the many siblings. An agent can infer the context but must reason about it rather than being told.

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 so richly: compile-if-needed semantics, seed/runs overriding file SEED and SIM_NUM, parallel vs sequential run behavior, exact output filenames, the .tot.gz totals file being written only in sequential mode, row 0 holding initial values, and failure returning the tail of LSD output. This is unusually complete disclosure.

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?

Dense but front-loaded, leading with the primary action and following with behavioral detail. A few clauses (the series-counting parenthetical, totals-file note) are slightly rambling but each earns its place by conveying output behavior.

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

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

For a complex 6-parameter tool with no output schema, the description explains the return payload (files written, last value and mean of saved series) and failure mode, which is the key gap. The omission of timeout_s and explicit model/config semantics is the only shortfall.

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

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

Schema coverage is 0%, so the description must compensate. It explains seed, runs, and threads in meaningful detail, but leaves model, config, and especially timeout_s undocumented, so roughly half the parameters lack 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?

States a specific compound action (compile if needed and run) on a precise resource (a configuration of a model in the models folder). It clearly separates itself from compile_model (only compiles) and read_results (reads output), so an agent can distinguish it from siblings without opening schemas.

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

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

The description implies the workflow (compile-if-needed then run) and explains how runs/seed/threads change behavior, but never explicitly states when to choose this over sa_run_design or set_run_settings, nor any preconditions. 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 and does so richly: it discloses determinism via r_seed, dependency failures (Rscript/LSDsensitivity), a sub-0.5 fit warning, polynomial failure on negative-mean responses, kriging numerical failure on coincident points, and edge behavior for '_'-prefixed variables and multiple instances.

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

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

Front-loaded with the core verb and the two metamodel branches before constraints, which is the right ordering. The prose is dense and run-on in places, but nearly every clause carries a behavioral fact an agent needs, so the length is largely earned for a 9-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?

For a complex tool with no output schema and no annotations, the description supplies the return shapes (Q2/R2, effects/interactions table, mu/mu_star/sigma/se/p_value), the scaling and sorting of ee output, and the operational preconditions. Nothing essential to invoking or interpreting it 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?

At 0% schema coverage the description must compensate, and it explains metamodel, ini_drop, n_keep, r_seed, levels and jump with real meaning, including the MAX_STEP constraint and -1 sentinel. It leaves model, config and variable essentially defined only by surrounding prose, so one or two parameters remain under-specified.

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: 'Analyse the design results for one saved variable with LSD's R package LSDsensitivity.' It clearly delineates this as the analysis step, distinct from the design/run siblings (sa_create_design, sa_run_design), so an agent can place it without opening any schema.

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

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

Gives strong conditional guidance: kriging/polynomial for lhs/random/nolh, 'ee' chosen automatically for an ee design, and that mixing metamodels with the wrong design is an error. It also routes around failures ('use kriging then', 'try polynomial'). It stops short of explicitly naming sibling tools or stating the prerequisite ordering relative to sa_run_design.

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 and does so: it discloses the exact files written, the refusal of functions/laggless variables/duplicate factors, the overwrite guard, the integer-factor warning, platform-dependent ee designs, and which parameters are ignored per method. This is far beyond what any annotation would supply.

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 purpose and appropriately sized for 14 parameters and four design methods; every clause carries operational detail. Readability suffers from being one dense paragraph without list formatting, but there is little dead weight.

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 complex, no-annotation, no-output-schema tool with nested parameters, the description covers method selection, output artifacts, failure modes, and per-method parameter behavior. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 0% and the description compensates thoroughly — it defines the factors map format ([min,max] / [min,max,'int']), element naming including negative lags, and the meaning and defaults of samples, validation_samples, extended, trajectories, pool, levels, jump, seed, runs_per_point, and overwrite. Nearly every one of the 14 parameters gains semantics found nowhere in the schema.

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

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

Opens with a specific verb+resource ('Create a design of experiments for a sensitivity analysis') and immediately distinguishes itself from siblings by naming the artifacts it produces and the analysis tools it feeds (sa_analyze, metamodel 'ee'). An agent can tell this apart from sa_run_design and sa_analyze without opening any schema.

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

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

Gives rich per-method context — 'lhs'/'random' for Kriging or polynomial meta-models, 'nolh' 'for meta-model analysis', 'ee' to be analysed with sa_analyze — plus the overwrite refusal condition. It stops short of an explicit 'use this instead of X when Y' routing against sa_run_design, but the when-to-use guidance for each mode is clear.

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 and does so reasonably: it discloses parallel execution, the default thread count (one per CPU), skip-if-result-exists idempotency, and the returned counts (done/run/failed/not started). It omits any note on timeout behavior, permissions, or side effects of failed points.

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 no filler, front-loaded with the primary action and scope before the skip behavior and return values. Efficient and well-ordered.

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

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

The description covers the return values in lieu of an output schema and explains the parallel/skip behavior, which is good. But for an execution tool with no annotations and zero parameter documentation, it leaves the agent without guidance on the required model/config inputs or the timeout parameter.

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

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

Schema description coverage is 0% across four parameters, and the description only partially compensates by explaining the threads default (one per CPU). The meaning of model, config, and especially timeout_s (default 3600) is left entirely undocumented in both schema and description.

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

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

The description states a specific verb+resource ("Run every numbered configuration of the design") and clarifies scope as the whole design rather than a single configuration. It implicitly contrasts with the sibling run_configuration (singular), but never names it, so the differentiation is left to inference.

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

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

No when-to-use guidance or alternatives are given. With both run_configuration and sa_run_design present as siblings, the agent must guess which to pick; the description only hints via "every numbered configuration" vs a single one, without stating the selection rule.

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. 'Edit' implies mutation but nothing is said about persistence (is the config file rewritten?), required permissions, reversibility, or what happens to unspecified settings. For a mutating 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 tight sentence with the affected settings front-loaded and no filler. Brevity is appropriate, though it comes at the cost of completeness rather than being optimally balanced.

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 five-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin: it omits the meaning of the two required parameters, prerequisites, and any indication of the effect of the edit.

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

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

Schema coverage is 0% with five parameters, so the description must compensate. It usefully maps runs→SIM_NUM, steps→MAX_STEP and seed→SEED, but leaves the required 'model' and 'config' parameters entirely unexplained, so half the interface remains opaque.

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

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

Specific verb (Edit) plus resource (run settings of a configuration), and it names the exact settings touched (runs, seed, steps). It does not distinguish itself from siblings like set_values or set_saved, which also mutate configuration data.

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 set_values, set_saved, or run_configuration, and no prerequisites (e.g., whether the model must be compiled or the config must exist) are stated. The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full burden. It usefully discloses the downstream effect ('Only saved elements appear in results'), which is real behavioral context beyond the name. However, it does not say whether setting saved=false removes previously written results, whether the change persists across runs, or what permissions are needed for a mutation operation.

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

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

Two short sentences, front-loaded with the action and followed by the consequence. No filler, though the phrasing 'saved (or not saved)' is slightly awkward given the parameter already carries the polarity.

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 mutation tool with 0% schema description coverage, no annotations, and no output schema, the description is thin. It omits what model/config refer to, whether the operation is reversible, and how it interacts with existing result files, so an agent cannot call it 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 coverage is 0%, so the description must compensate. It hints at the 'names' parameter ('named variables or parameters') and the boolean toggle ('saved (or not saved)'), which maps to the 'saved' parameter and its default. But 'model' and 'config' — two of the three required parameters — are never explained, leaving the highest-risk inputs undocumented in both schema and description.

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

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

States a specific verb ('mark ... as saved') and resource ('named variables or parameters'), and clarifies the scope ('to the result files'). It does not explicitly distinguish itself from close siblings like set_values or set_run_settings, but the purpose is unambiguous.

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

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

No explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The clause 'Only saved elements appear in results' implies the context in which this matters, which is more than nothing but still leaves the agent to infer when to reach for this versus set_values or set_run_settings.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses important side effects: writes new_config.lsd or replaces config.lsd (keeping a .bak), and the result indicates whether replacement occurred. It also states error conditions (lag beyond variable's lags, parameter lag, repeated element per call). Missing: permissions required, atomicity, or what happens on partial failure.

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

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

The description is dense with useful details but somewhat disorganized; the lag-suffix explanation is verbose and interleaved with error conditions. It could be front-loaded better (e.g., start with the write behavior) but every sentence adds value.

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

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

Given no annotations and no output schema, the description covers key behavioral aspects: write destination, backup behavior, return information, and error conditions. It lacks the return type details (e.g., exact fields of result) and parameter explanations for 'model', 'config', and 'new_config', but is otherwise fairly 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?

With 0% schema description coverage, the description compensates well: it explains that 'values' maps element names to numbers, describes the special lag suffix syntax ('Name -2'), and notes constraints on parameter usage. However, it does not explain 'model', 'config', or 'new_config' parameters clearly (though their names are somewhat self-explanatory).

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

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

The description clearly states a specific verb+resource: setting element values in a configuration, and names the underlying mechanism (lsd_confgen). It does not explicitly differentiate from siblings like set_run_settings or edit_structure, but the resource (element values) is distinct enough.

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

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

Usage is implied by the description of how values map to elements and lags, but there is no explicit when-to-use versus alternatives, no mention of prerequisites, and no guidance on when to choose new_config vs. overwriting config.lsd.

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 provided, the description carries the full behavioral burden and does well: it discloses that writes are destructive ('Replace'), that a new file is created if absent, that backups are kept as <file>.bak and <file>.orig, and that writes are scoped to the models folder. It omits auth/permission requirements and error behavior, but the backup and scoping disclosures are substantial for a mutation tool.

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

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

The core action and the content-vs-file choice are front-loaded, followed by the backup semantics and the scope constraint. Every clause earns its place with 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 destructive three-parameter write tool with no annotations and no output schema, the description covers the essential behaviors an agent needs: what gets replaced, file naming/creation, backup retention, and scope restriction. It could go further on permissions and the outcome of a failed write, but it is largely self-sufficient.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: `content` is defined as complete C++ source, `file` as a plain name with .cpp/.h/.hpp and create-if-missing semantics, and `model` is constrained via the models-folder rule. It does not explain the interaction/default when `file` is omitted (where the equations file lives), leaving a small gap.

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

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

States a specific verb and resource: 'Replace the model's equation file' with either inline content or a named source file. It clearly distinguishes the two write modes. It does not explicitly contrast with the read counterpart (read_equations) among its many siblings, 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?

It explains the conditions governing the two write paths (content vs file) and adds the constraint that only models in the models folder can be written, which is genuinely useful context. However, it gives no explicit when-to-use-this-vs-alternative guidance (e.g., when to use write_equations versus edit_structure).

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