Skip to main content
Glama

edit_structure

Modify an LSD model configuration's structure by adding, renaming, deleting, or resizing objects, parameters, variables, and functions; operations apply in order and roll back if any fail.

Instructions

Change a configuration's structure (objects, parameters, variables, functions, instance counts) with LSD's own code. operations is a list of objects applied in order; if any fails (the message names it) nothing is written. Writes new_config.lsd, or replaces config.lsd (old file kept as .bak). Names must be valid LSD labels (letter or '' first, then letters, digits, '') and unique across the whole model, objects and elements alike. Operations, one example each: {"op": "add_object", "parent": "Root", "name": "Firm", "instances": 10} {"op": "add_parameter", "object": "Firm", "name": "alpha", "value": 0.5} {"op": "add_variable", "object": "Firm", "name": "K", "lags": 1, "initial": 1.0, "saved": true} (initial: a number, or one per lag) {"op": "add_function", "object": "Firm", "name": "f"} {"op": "rename", "name": "old", "new_name": "new"} (object or element) {"op": "delete", "name": "K"} (element; an object with elements or child objects needs "force": true and goes with all of it) {"op": "set_instances", "object": "Firm", "instances": 50} {"op": "set_instance_values", "name": "alpha", "values": [0.1, 0.2], "lag": 2} (one value per instance in file order; lag only for variables) {"op": "describe", "name": "alpha", "text": "adjustment speed"} Parameters and variables are added to every instance of the object, with the value (default 0) in each. set_instances gives the object that number under every parent instance; new instances are copies of the object's first instance (its values and its child objects), extra ones are removed from the end; at least 1. Equations are not touched: add or change them with write_equations. LSD's save rewrites the file in its own layout, so old files may change in layout (empty descriptions, the notes LSD generates for initial values of variables with no lags are dropped), never in values.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYes
configYes
new_configNo
operationsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.