designer_action Reference

10.1.5 additions to designer_action and related DesignerMCP tools — new build action parameters, compile feedback on write/read responses, and a context_menu action for grid right-click verification.

AI Integration → designer_action Reference

designer_action('build', …) — new parameters

The build action invokes the same pipeline as the Designer "Build and Publish" dialog. In 10.1.5 it accepts two named parameters that mirror the dialog's checkboxes.

designer_action(
  action:             "build",
  rebuild_all:        bool = false,   // false = incremental, true = full rebuild
  validate_displays:  bool = true     // run Display compile pass in addition to Scripts
) -> { build: <block> }
      

The response is the shared build block. See MCP SDK Reference for the full shape.

# Fast path during iterative development
designer_action('build')
# == designer_action('build', rebuild_all=false, validate_displays=true)

# Pre-deploy check - recompile everything
designer_action('build', rebuild_all=true, validate_displays=true)

# Scripts-only run while debugging script logic
designer_action('build', validate_displays=false)
      

write_objects — per-row compile field

When a write_objects call touches a row in one of the four affected tables (ScriptsTasks, ScriptsClasses, ScriptsExpressions, DisplaysList), the response entry for that row carries a compile field populated from the save-time incremental compile.

{
  "results": [
    {
      "table": "ScriptsTasks",
      "name":  "Line1_Cycle",
      "status": "written",
      "compile": {
        "status": "error",
        "diagnostics": [
          { "line": 12, "msg": "The name 'tagx' does not exist in the current context" }
        ]
      }
    },
    {
      "table": "ScriptsClasses",
      "name":  "TankUtils",
      "status": "written",
      "compile": { "status": "ok", "diagnostics": [] }
    }
  ]
}
      

Writes to rows outside the four affected tables carry no compile field — those objects do not participate in the .NET compile pipeline.

The row-level compile reports only what the incremental pipeline saw for that single object. Cross-object breakage — for example, an edit to a ScriptsClasses row that breaks a ScriptsTasks row referencing it — is surfaced by a subsequent designer_action('build') call, not by the write response alone.

get_objects(detail='full') — lastCompile field

When get_objects is called with detail='full' against one of the four affected tables, each returned row carries a lastCompile field holding the most recent compile result for that object.

{
  "table": "ScriptsTasks",
  "name":  "Line1_Cycle",
  "code":  "...",
  "lastCompile": {
    "status": "ok",
    "at":     "2026-04-21T16:02:11Z",
    "diagnostics": []
  }
}
      

Calls with detail='summary' or the default detail level do not include lastCompile — it is only emitted on the full-detail path to keep the summary response compact.

SolutionContext / RefreshContext — build_state section

The context packages returned to the agent on connect and on refresh now include a compact build_state section. This gives the agent a one-shot view of compile health without needing to call designer_action('build') at session start.

{
  "build_state": {
    "built":     42,
    "failed":    1,
    "skipped":   0,
    "timestamp": "2026-04-21T16:02:11Z"
  }
}
      

The fields match the summary portion of the shared build block. Per-object diagnostics are not included here — callers that need them issue designer_action('build') or get_objects(detail='full') on the affected table.

designer_action('context_menu', …) — grid right-click verification

The context_menu action drives a row's right-click context menu through the same UI surface a Designer operator would use. It serves automated verification workflows that previously had to flag MANUAL-QA-BENCH-REQUIRED for any menu-driven step (Tag editor rows, Security Secrets, Devices / Datasets grids, and every other table whose row carries actions accessible only via right-click).

Two modes, discriminated by the presence of a | separator in the options string:

# Inspect: list the items the context menu would show for this row.
designer_action('context_menu', '<TableType>.<RowName>')
# Invoke: fire the named menu item on this row.
designer_action('context_menu', '<TableType>.<RowName>|<MenuAction>')
      

Inspect form

Returns the snapshot of the menu items after the page's ContextMenu.Opened gates fire against the selected row. Items reflect the post-gate state, so visibility and enablement match what a user would see on right-click.

{
  "mode": "inspect",
  "table": "SecuritySecrets",
  "row":   "AdminPass",
  "items": [
    { "header": "Copy SecretValue to clipboard",
      "tag":    "TDEV1412_CopySecretValue",
      "isEnabled": true,
      "isVisible": true }
  ]
}
      

Invoke form

Matches MenuAction against MenuItem.Tag first (case-sensitive — Tags are programmer-set stable identifiers), then against Header text (case-insensitive). Fires RaiseEvent(MenuItem.ClickEvent) on the matched item; the response carries any error the Click handler raised.

{
  "mode": "invoke",
  "table": "SecuritySecrets",
  "row":   "AdminPass",
  "match": { "matchedBy": "tag", "tag": "TDEV1412_CopySecretValue" },
  "status": "ok"
}
      

Prefer Tag matching for stable AI scripts — Header text often carries localization or accelerator markers that drift release to release. Tags are author-set in code-behind and stay stable across cosmetic UI changes.

Page coverage (v1)

v1 wires only pages that expose the canonical GridControlObj element name — every W3ContentsControl-derived grid (Tags, Devices, Alarms, Datasets, Security, Reports, etc.). Display editors and the project tree return PAGE_NOT_SUPPORTED; future releases extend the verb's surface area.

Error Codes

list_wizard_options and pick_wizard_variant — solution-creation wizard

The solution-creation wizard exposes its template catalog through two paired DesignerMCP tools. Use them in sequence when an AI workflow needs to create a new solution from a built-in template rather than from a blank slate: list_wizard_options enumerates the templates the wizard would present in its UI; pick_wizard_variant selects one by name and feeds it into the subsequent create_solution call.

Flow

1. Call list_wizard_options to enumerate the available solution templates. The response carries the template name, a short description, and any variant tags (e.g., HeaderLayout, AlarmsTrendLayout, WideScreenLayout, plus sector-specific templates when the matching package is installed).
2. Call pick_wizard_variant with the chosen template name. The platform records the selection and returns the parameter payload the wizard would otherwise collect from a user.
3. Issue create_solution with the returned payload to materialize the new solution.

# 1. Enumerate templates
list_wizard_options()
# -> { variants: [ { name: "HeaderLayout", description: "..." }, ... ] }

# 2. Pick one
pick_wizard_variant(name="HeaderLayout")
# -> { variant: "HeaderLayout", params: { ... } }

# 3. Create the solution
create_solution(name="ai-test-headerlayout-demo",
                path="C:/Users/.../Documents/FrameworX/Dev Test/",
                template="HeaderLayout")
      

The wizard tools are read-only with respect to the solution graph — nothing is written until create_solution runs. An AI workflow that needs to inspect the template catalog without creating anything can call list_wizard_options safely on any open Designer session.

set_object_value — live Object Model write

set_object_value writes a single row in the live Object Model — a tag value, an attribute, or any other runtime-writable object exposed under the 12 Object Model roots. It is distinct from write_objects: write_objects targets the solution's configuration tables (Tags, Devices, ScriptsTasks, etc., as authored in Designer), while set_object_value targets live runtime state on the connected solution.

Use set_object_value when an AI workflow needs to drive a control loop, exercise a tag-bound dynamic, or seed runtime state for a smoke test against a running solution. Use write_objects when the change should land in the saved solution and survive a restart.

# Drive a live tag value in the running runtime
set_object_value(name="Tag.Plant.Line1.Setpoint", value=72.5)
      

The runtime equivalent on the RuntimeMCP surface carries the same tool name — see Runtime MCP Reference. On the DesignerMCP surface, set_object_value requires a runtime to be bound to the active Designer session; calls against a solution that has no running runtime return an error.

Error Codes

In this section...