lsd-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LSDROOT | No | An LSD folder containing src/. If unset, the tag is fetched (sparse clone of src, Example, Rpkg). | |
| LSD_TAG | No | Tag to fetch. | 8.1-stable-5 |
| LSD_MODELS | No | Your models. The only place the edit and run tools write. | ~/lsd-models |
| LSD_MCP_HOME | No | Fetched source and all build output. | ~/.cache/lsd-mcp |
| LSD_CONTAINER | No | Name of the running container. | lsd |
| LSD_MCP_BACKEND | No | docker forwards tool calls into the container. | local |
| LSD_MCP_RSCRIPT | No | R interpreter for sa_analyze. | Rscript |
| LSD_MCP_CONTAINER_MODELS | No | Models folder inside the container. | /home/lsd/LSD/Work |
| LSD_MCP_CONTAINER_LSDROOT | No | LSD folder inside the container. | /home/lsd/LSD |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| lsd_statusA | Show the setup: LSD source root and tag, models folder, whether a C++ compiler was found, whether LSD's command-line utilities are built yet (they are built automatically on first use), and whether Rscript and the R package LSDsensitivity are available. |
| list_modelsA | List models. group='models' is the user's LSD_MODELS folder; group='examples' is the Example folder of the LSD distribution (read-only). A model is a folder with an equation file (fun_*.cpp) and at least one .lsd configuration. Returns relative path, title, equation file, source files (*.cpp, *.h, *.hpp in the folder) and configuration names for each. |
| read_equationsA | Return the text of the model's equation file (the C++ source with the
EQUATION(...) blocks). Models whose equations are spread over several files
list them as source_files in list_models; pass such a plain file name
(.cpp, .h or .hpp, no path) as |
| describe_configurationA | Describe a .lsd configuration: the object tree with instance counts,
and for each element (variable, parameter or function) its type, number of
lags, whether it is saved to the result files, and its value (a single
value if all instances are equal, otherwise min, max and count), plus the
run settings SIM_NUM, SEED, MAX_STEP and EQUATION. |
| copy_modelB | Copy a model folder (source files only: no binaries, results, backups,
numbered design configurations, design tables or _sa folders) into
the models folder as |
| write_equationsA | Replace the model's equation file with |
| set_valuesA | Set element values in a configuration, using LSD's own lsd_confgen.
|
| set_run_settingsC | Edit SIM_NUM (runs), SEED and MAX_STEP (time steps) of a configuration. |
| set_savedB | Mark the named variables or parameters as saved (or not saved) to the result files. Only saved elements appear in results. |
| edit_structureA | Change a configuration's structure (objects, parameters, variables,
functions, instance counts) with LSD's own code. |
| create_modelA | Create a new, empty model folder in the models folder, as LSD's model
manager (LMM) does: equation file fun_.cpp from LSD's template,
model_options.txt, modelinfo.txt (LMM lists a folder only with it),
description.txt, and a configuration Sim1.lsd holding only Root. |
| compile_modelB | Compile the model's equation file into a headless LSD program (built into the cache, not the model folder). Returns ok and build time, or the first compiler errors as file:line: message. Nothing is rebuilt if the equation file is unchanged. |
| run_configurationA | Compile if needed and run a configuration of a model in the models folder. seed and runs override SEED and SIM_NUM of the file. threads: with runs > 1, the number of runs executed in parallel; otherwise threads for models that use parallel objects. Results are written next to the configuration as .res.gz. Returns the files written and, for the first run, the last value and mean of each saved series (at most 50 series, those whose name has few instances first; the rest are counted). With runs > 1 (sequential) LSD also writes _.tot.gz; with threads set the runs are parallel and no totals file is written. Row 0 of a result file holds initial values. On failure returns the tail of LSD's output. |
| read_resultsA | Read time series from one result file (.res.gz) in the model folder. variables filters by name ('Mean') or name with instance ('Mean 1'); start/end select time steps (the row number in the file is the time step; row 0 holds initial values; start must not exceed end; max_points >= 1); the series are thinned evenly to max_points. At most 50 series are returned. |
| sa_create_designA | 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': |
| sa_run_designB | Run every numbered configuration of the design in parallel processes (default: one per CPU). Points whose result files already exist are skipped. Returns counts of points done, run, failed and not started. |
| sa_analyzeA | Analyse the design results for one saved variable with LSD's R package LSDsensitivity. metamodel 'kriging' (default for lhs, random and nolh designs) or 'polynomial' fits a meta-model and computes its Sobol decomposition: returns the fit quality (Q2 for kriging, R2 for polynomial) and a table with direct effects and interactions per factor. For a design made with method 'ee' the analysis is elementary effects (metamodel 'ee', chosen automatically): returns per factor mu, mu_star, sigma, se and p_value (parameters scaled to [0, 1]; mu_star is the overall effect, sigma non-linear or interaction effects, p_value tests mu_star = 0), sorted by mu_star. Kriging or polynomial on an ee design, or ee on another design, is an error. For an ee design made in LSD's own interface (no design file) pass metamodel='ee' with its levels and jump. ini_drop drops initial time steps, n_keep keeps that many (-1 = all). The response is the mean of the variable over the kept steps, averaged over runs. Variables whose name starts with '_' work; with several instances only the first instance is analysed. ini_drop must be below MAX_STEP and ini_drop + n_keep at most MAX_STEP. r_seed seeds R's random numbers, so identical calls give identical results. A warning is added when a meta-model fit is below 0.5. The polynomial meta-model fails when a design point has a negative mean response (LSD weights points by mean/SD) and needs at least two factors; use kriging then. Kriging can fail numerically when design points nearly coincide (the message says so; try polynomial). Needs Rscript and LSDsensitivity; says so if they are missing. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Most tools have clearly distinct scopes (model management, configuration editing, execution, and sensitivity analysis). Slight overlap exists between set_values and edit_structure's set_instance_values operation, and between set_run_settings and run_configuration's seed/runs overrides, but descriptions distinguish them well.
Predominantly snake_case verb_noun names such as list_models, read_equations, and create_model. Deviations are the sa_ prefix for sensitivity-analysis tools and lsd_status, but these are readable and consistent within their subgroups.
With 17 tools, the set is slightly above the ideal 3-15 range but the domain is broad and each tool covers a distinct workflow step. The count is reasonable, though a couple of configuration-editing tools could potentially be merged.
Coverage is strong across the model lifecycle (create, copy, read/write equations, edit structure, compile, run) and sensitivity analysis (design, run, analyze). Minor gaps include no delete_model/delete_configuration and no explicit list_results, which agents can partially work around.