Skip to main content
Glama

sa_create_design

Generate a sensitivity-analysis design of experiments and write LSD configuration, design tables, and JSON files from factor ranges and the selected method.

Instructions

Create a design of experiments for a sensitivity analysis and write it in LSD's own file layout in the model folder: .sa, the design table _1_N.csv (and for meta-model designs the out-of-sample table _N+1_N+V.csv), numbered configurations _1.lsd ..., and _design.json (our file: method and parameters). factors maps an element to [min, max], or [min, max, "int"] for integers. An element is a parameter name, or a variable name for the variable's initial value at its first lag, or "Name -2", "Name -3" ... (name, space, negative lag) for the initial value at that lag. Functions, variables with no lags and lags beyond the variable's lags are refused, and an element can be a factor only once (LSD's design table names a factor by its label, so the result files and the analysis tables show the plain name, for example "X"; the design file _design.json records each factor's lag, 0 for a parameter). method: 'lhs' (Latin hypercube) or 'random': samples points (required, at least 2) plus validation_samples uniform out-of-sample points, for a Kriging or polynomial meta-model. 'nolh': near-orthogonal Latin hypercube made by LSD's own NOLH tables. LSD chooses the table from the number of factors (17 points for 1-7 factors, 33 for 8-11, 65 for 12-16, 129 for 17-22, 257 for 23-29, 512 for 30-100; extended=True uses LSD's extended size for the table: 33, 65, 129, 257, 257, 512), so samples is not used; the result says how many points LSD produced. Plus validation_samples out-of-sample points by LSD's Monte Carlo range sampling. For meta-model analysis. 'ee': elementary effects (Morris) design made by LSD's own code: trajectories (default 10) each of factors + 1 points, chosen from a pool of pool random trajectories (default 100) on levels levels (even, default 4) with jump (default 2). No out-of-sample set; validation_samples and samples are ignored. An ee design made on macOS differs from one made on Linux for the same seed (the C++ library's shuffle differs); both are valid designs. Analyse it with sa_analyze (metamodel 'ee'). Each point runs runs_per_point times (at least 2) with its own seeds. seed seeds the sampling. Refuses to replace an existing design unless overwrite=True. A warning is returned for integer factors with few levels (a hypercube collapses onto them). Variables whose results will be analysed must be saved (set_saved).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jumpNo
poolNo
seedNo
modelYes
configYes
levelsNo
methodNolhs
factorsYes
samplesNo
extendedNo
overwriteNo
trajectoriesNo
runs_per_pointNo
validation_samplesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.