Skip to main content
Glama

Build: run a uCAD script

run_script
Destructive

Run a whole uCAD script on a drawing in the user's account (a new drawing when drawing is left out) and keep the result there. Returns the report (every solid with its size and place, warnings, print() output, or the error with its line), the drawing's id and link, and pictures of it. Each run replaces what the drawing's previous run made. The language is at spec version e597bdd3ef: if what you know of it is another version (or none), call specs first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

NameRequiredDescriptionDefault
codeYesThe whole script (uCAD's Python, see specs)
nameNoA name for a new drawing (as the user sees it in Open)
viewsNoThe sides to show it from (one picture each): iso, iso_back, front, back, left, right, top, bottom. Default: iso.
widthNoPicture width in pixels (default 800)
heightNoPicture height in pixels (default 600)
drawingNoThe id of the drawing to run it on. Left out: a new drawing.
spec_versionNoThe spec version (from specs) the script is written for. Now: e597bdd3ef

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: d28f4bc8e1"New value: +"The spec version (from specs) the script is written for. Now: e597bdd3ef"
  2. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: 9a5b59f5c9"New value: +"The spec version (from specs) the script is written for. Now: d28f4bc8e1"
  3. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: bcfda6e225"New value: +"The spec version (from specs) the script is written for. Now: 9a5b59f5c9"
  4. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: 58a371b686"New value: +"The spec version (from specs) the script is written for. Now: bcfda6e225"
  5. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: 0b5a988824"New value: +"The spec version (from specs) the script is written for. Now: 58a371b686"
  6. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: c023c3182f"New value: +"The spec version (from specs) the script is written for. Now: 0b5a988824"
  7. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: 9ee73bb3f2"New value: +"The spec version (from specs) the script is written for. Now: c023c3182f"
  8. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: d9290d231d"New value: +"The spec version (from specs) the script is written for. Now: 9ee73bb3f2"
  9. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: 9f15cf0fae"New value: +"The spec version (from specs) the script is written for. Now: d9290d231d"
  10. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: 9e0fee0d90"New value: +"The spec version (from specs) the script is written for. Now: 9f15cf0fae"
  11. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: ad65f6b97f"New value: +"The spec version (from specs) the script is written for. Now: 9e0fee0d90"
  12. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: ed373303d5"New value: +"The spec version (from specs) the script is written for. Now: ad65f6b97f"
  13. Changed1 schema field changed
    • changedInput schema / properties / spec_version / description
      Previous value: -"The spec version (from specs) the script is written for. Now: e69d2ae9e0"New value: +"The spec version (from specs) the script is written for. Now: ed373303d5"
  14. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With destructiveHint=true already declared, the description adds the exact destructive mechanic: 'Each run replaces what the drawing's previous run made.' It also enumerates what comes back (report with solids, warnings, print output, or error with line number, plus drawing id, link, and pictures), which annotations alone could not convey.

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?

Three sentences, front-loaded with the action and persistence semantics, then the return payload, then the destructive replacement warning and the version caveat. Parentheticals are load-bearing rather than filler; nothing reads as restating the title.

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?

There is no output schema, so the description carries the return-value burden itself and does so completely: report contents, error/line reporting, id, link, and images. For a destructive, non-idempotent execution tool with 7 parameters, the mutation effect and version prerequisite are both covered.

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 coverage is 100%, so every parameter already carries its own description including defaults and the new-drawing behavior. The description reinforces the omitted-`drawing` case and ties `spec_version` to the specs tool, but adds little syntax or constraint detail beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource ('Run a whole uCAD script on a drawing'), plus the important scope nuance that the target is a drawing in the user's account or a brand-new drawing when `drawing` is omitted. It also signals the result is persisted ('keep the result there'), which separates it from a pure evaluation or preview tool.

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 a concrete prerequisite-based routing rule: check the spec version and 'call specs first' when the known language version differs or is unknown. That is an explicit alternative for one important precondition, but there is no statement of when not to use this tool (e.g. versus `example` or `view` for inspecting an existing drawing).

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