Skip to main content
Glama

Run script

run_script
Destructive

Use this whenever a task needs many reads or writes, or numbers you would work out in your head: sums per class or storey, one element per bay or grid point (louvres of a bay: one element, repeat), walls along an outline. Runs JavaScript; await moddl.<tool>(args) is any tool call, same args; writes inside take guid, guids or a set (many: one call with guids, not one per guid). All writes land as ONE revision; a throw writes nothing. One script per part of the job (a storey; walls, openings, roof), each under 45 s: the person sees no change while one runs, then each land, and can stop you in between. Writes of one tool (set_properties at one guid, create_elements, copy_elements, insert_in_host): moddl.together([{tool, args}]) is one commit, answers in order; a conflict refuses all (try). Return what you need as JSON (max 8 KB), with n and coverage when you sum. A refusal throws ContractError {code, message, at, detail, try, line}; catch it to go on, it still appears in rejected with its line. console.log goes to log. Answers as outside but without checks: those run once at the end over all it wrote, each finding with its line. dry_run runs it all, puts it back and answers the checks and, when it writes, a plan_id; run_script with that plan_id alone lands exactly that result in seconds, PLAN_CHANGED if the model was written since; never rerun the script (as slow as the dry_run). Time limit 150 s, moddl calls included; at any limit (SCRIPT_LIMIT) nothing is written, finished writes stay a plan_id (try). Lost to a timeout? Repeat with its request_id; without, get_history shows whether it landed. Not callable inside: run_script, export_ifc, undo, restore_revision, render_view, draw_section. No Date, no Math.random, no I/O; at most 200 moddl calls, 1 MB per call argument; a request_id once per script. Limits: get_guide topic script. Example: const f = await moddl.find_elements({filter:{class:['IfcColumn']},fields:['hull.center_x'],limit:500}); return {n: f.target.n, xs: f.rows.map(r => r['hull.center_x'].value)}

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "run_script"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteNoYour note, stored with the new revision
scriptNoJavaScript body; top-level await and return allowed. Exactly one of script and plan_id
dry_runNoPreview: the planned effect and a plan_id, nothing written
plan_idNoFrom a dry_run of run_script: lands that result unchanged. The human sees the result of the latest dry_run in the viewer until it lands or the model is written
contactsNoThe contact checks at the end. fast: touch and gap between two planar bodies, approximate (source mesh, n_pairs_mesh); clash stays exact. exact: every pair measured exactly. Default: exact, but pairs with an IfcGeographicElement and lost_contact fast
request_idNoYour id for this call: a repeat answers the first result and writes nothing

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare destructive/not-read-only; the description goes far beyond by disclosing transaction semantics ('All writes land as ONE revision; a throw writes nothing'), the together() single-commit rule, the dry_run/plan_id replay flow with PLAN_CHANGED, timeout consequences (SCRIPT_LIMIT writes nothing, finished writes stay a plan_id), idempotency via request_id, and safety limits (150 s, 200 calls, 1 MB per argument, no Date/Math.random/IO). Error shape (ContractError {code, message, at, detail, try, line}) and post-hoc check behavior are also spelled out.

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

Conciseness3/5

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

Nearly every clause carries information, and the usage guidance is front-loaded, but the delivery is a dense run-on with telegraphic parentheticals ('louvres of a bay: one element, repeat', 'walls, openings, roof') that hurt scanability for a high-stakes destructive tool. A short bulleted limits/error list would deliver the same content more reliably.

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 destructive, open-ended script executor this is thorough: it covers execution model, write atomicity, size/time limits, forbidden globals, error contract, check timing, recovery via request_id or get_history, and includes a worked example plus a pointer to get_guide topic script. There is no output schema, and the description compensates by specifying the return contract (JSON, max 8 KB, include n and coverage when summing) and where console.log goes.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already defines all six parameters; nonetheless the description adds real meaning about interplay: script vs plan_id exclusivity and 'never rerun the script', request_id used once per script to recover from a timeout, and dry_run producing a plan_id that lands 'exactly that result in seconds'. It adds less on contacts and note, which the schema already covers well.

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 mechanism: 'Runs JavaScript; `await moddl.<tool>(args)` is any tool call, same args', which unambiguously identifies this as a batch/orchestration tool rather than any single-element sibling. The opening also scopes it ('whenever a task needs many reads or writes, or numbers you would work out in your head'), so an agent can distinguish it from find_elements, compute_quantities, or set_properties 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.

Usage Guidelines5/5

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

Explicit when-to-use ('many reads or writes', sums per class or storey, one element per bay) plus explicit decomposition advice ('One script per part of the job... each under 45 s'). It also names what cannot be called inside (run_script, export_ifc, undo, restore_revision, render_view, draw_section) and routes to get_guide topic script, which is stronger than most sibling definitions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources