Skip to main content
Glama
LBurny

CADPilot

by LBurny
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

execute_code

Destructive

Run Python code in FreeCAD's GUI thread to automate parametric modeling, with print output returned and mutating runs committed as one undoable step.

Instructions

Run Python in FreeCAD's GUI thread (FreeCAD/App, FreeCADGui, Part pre-imported); print() output is returned.

The run is transactional: a mutating snippet commits as one undoable step, a read-only run is not recorded.

Args:
    code: Code to run; start with a # comment naming the step, which becomes the step's row label and description.
    doc_name: Bind the transaction, step journal and App.ActiveDocument to this document; defaults to the session's document, else the process's home document.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYes
doc_nameNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.7.7
    • addedInput schema / properties / doc_name
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Doc Name"
+}
    • removedInput schema / properties / with_screenshot
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "boolean"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "With Screenshot"
-}
    • removedOutput schema / $defs / ImageContent
      Removed value: -{
-  "additionalProperties": true,
-  "description": "Image content for a message.",
-  "properties": {
-    "_meta": {
-      "anyOf": [
-        {
-          "additionalProperties": true,
-          "type": "object"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "title": "Meta"
-    },
-    "annotations": {
-      "anyOf": [
-        {
-          "$ref": "#/$defs/Annotations"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "data": {
-      "title": "Data",
-      "type": "string"
-    },
-    "mimeType": {
-      "title": "Mimetype",
-      "type": "string"
-    },
-    "type": {
-      "const": "image",
-      "title": "Type",
-      "type": "string"
-    }
-  },
-  "required": [
-    "type",
-    "data",
-    "mimeType"
-  ],
-  "title": "ImageContent",
-  "type": "object"
-}
    • addedOutput schema / properties / result / items / $ref
      Added value: +"#/$defs/TextContent"
    • removedOutput schema / properties / result / items / anyOf
      Removed value: -[
-  {
-    "$ref": "#/$defs/TextContent"
-  },
-  {
-    "$ref": "#/$defs/ImageContent"
-  }
-]
  2. First observedv0.4.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructive/non-idempotent/open-world, and the description adds material context beyond them: the run is transactional, a mutating snippet commits as one undoable step, a read-only run is not journaled, and print() output is captured. Undo grouping and journaling behavior are exactly the traits an agent cannot infer from the schema.

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?

Front-loaded purpose sentence, then one transactional sentence, then a compact Args block — every line carries information and nothing is repeated from the 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?

With an output schema present, return values need no explanation, and thread, transaction, doc binding and both parameters are covered. The remaining gap is the blocking/timeout profile of running arbitrary code in the GUI thread versus the async sibling, which an agent choosing between the two would want.

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%, so the description carries the full burden and does: the '#' comment convention that becomes the step row label is a non-obvious semantic, and doc_name's binding of transaction, step journal and ActiveDocument plus its default fallback chain is spelled out. This adds real meaning the bare schema lacks.

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 precise verb+resource ('Run Python in FreeCAD's GUI thread') and immediately scopes it with the pre-imported modules and the fact that print() output is returned. The GUI-thread qualifier cleanly distinguishes it from the sibling execute_code_async.

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?

The GUI-thread framing implicitly tells the agent this is the synchronous/in-thread path versus execute_code_async, and the transactional paragraph clarifies mutating vs read-only intent. It never explicitly says when to prefer the async sibling or warns that long code blocks the GUI, so guidance is clear but not exhaustive.

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

Deploy Server

Other Tools