Page History

Draft preview of the 10.1.5 additions to designer_action and related DesignerMCP tools — new build action parameters and compile feedback on write/read responses.

designer_action Reference

Reference for the designer_action MCP tool: navigation, visual targeting, runtime control, and dynamic tab actions.

AI Integration → designer_action Reference (10.1.5 draft)

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: string,             "build",
  rebuild_all:       // one of the core actions below, or any tabActions value
  target: string bool = false,   // false = incremental, true = full rebuild
  validate_displays:  bool = true     // meaning depends on action run Display compile pass in addition to Scripts
) -> object { build: <block> }
      

When the server does not recognize the action, the response includes a validActions array with the core list. Dynamic tab actions are discovered through tool responses (for example, the tabActions array returned by get_objects).

The response is the shared build block. See MCP SDK Reference (10.1.5 draft) 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.

Core Actions

Dynamic Tab Actions

Each Designer tab advertises extra actions in the tabActions array on get_objects responses. Call designer_action with any advertised value. Common examples:

Unknown dynamic actions return a clear error with the current tab's tabActions list, so the client always has a recovery path.

Examples

Error Codes

In this section...