TL;DR Creator 1.8 is bringing a command-line interface and an MCP server for AI agents. Both are the direct result of a deliberate architectural decision made 18 months ago: stop depending on Beckhoff’s Automation Interface and build our own parser and semantic model instead. That move gives us full control over code analysis and generation, independent of IDE, vendor, or whatever Beckhoff ships next. If you run a PLC software business and haven’t started thinking about this yet, it’s worth reading on.
The story of how we got here is worth reading. There’s also a demo video further down.
Beckhoff announced PLC++ at SPS 2024. Plain-text structured text, no more XML, no more .TcPOU files, and critically: the future of the Automation Interface left intentionally vague.
For most TwinCAT teams, that’s background noise. For us it was a forcing function.
Creator has always lived inside the TwinCAT XAE environment, and for years it relied on the Automation Interface to do the hard work: finding declarations, resolving implementations, navigating function block hierarchies. The Automation Interface is powerful and well-suited to IDE-integrated workflows, but it requires the IDE to be open, runs on Windows, and is COM-based. These are constraints that don’t fit headless or cross-platform scenarios. If Beckhoff significantly changes it for PLC++, every tool built on top of it has a problem.
We decided to solve that problem before it arrived.
The Foundation: AML as a Machine Description Language
Before getting into what changed, it’s worth explaining something that hasn’t changed: we’ve used AutomationML (AML) as the backbone of Creator since the beginning.
AML is an open XML standard for exchanging engineering data across tools. For us it serves a specific purpose: it describes the structure of a machine (units, equipment, I/O, axes, sequences) in a way that’s abstract and vendor-neutral. When you use Creator to compose your mechatronic structure, that structure is persisted in an AML document. This document is the authoritative source of what your application consists of, separate from any generated code.
That separation matters. It means we can generate code, regenerate it, migrate it, or generate it again for a completely different target, because the description is clean and the generation is a separate concern.
What We Actually Built: A Parser and Semantic Model
The concrete problem we needed to solve: Creator previously relied on the Automation Interface to navigate TwinCAT source code. When we needed to know whether a function block extended a particular base type, or what methods a unit exposed, we asked the Automation Interface.
In its place, we built our own parser and populated a semantic model from it.
The parser reads TwinCAT structured text source files directly. For the traditional XML-wrapped .TcPOU format, it extracts the ST content and builds up a model of namespaces, function blocks, methods, properties, interfaces, and inheritance chains. The semantic model is queryable in exactly the ways we need: the same things the Automation Interface offers for code navigation, and then some.
The Automation Interface isn’t gone. Creator still integrates with it for the Visual Studio extension, and that’s not changing. But it’s no longer the only path. We now have a code generation engine that works independently of the IDE, and both approaches share the same underlying model. That means the VS extension and the CLI/MCP server are two projections of the same thing, not separate tools with separate implementations.
The more significant piece underneath all of this is the abstraction layer: a codec interface that separates “what is this source code” from “how is it stored on disk.”
ISourceCodec
├── TwinCatPlcCodec (.TcPOU / .TcDUT / .TcGVL, the classic XML format)
└── StructuredTextCodec (plain .st files, PLC++, Simatic AX, and others going that direction)
Both codecs feed the same semantic model. The same code generation logic, the same AML-backed structure, the same CLI commands, all working regardless of which codec you’re running against.
This means Creator is no longer a TwinCAT-only tool in its architecture. It can generate framework-compliant structured text for any vendor that uses plain-text ST files. Simatic AX already does. PLC++ will. Others will follow.
The CLI
Once the semantic model existed and the codec abstraction was in place, a command-line interface became straightforward.
zkcreator is a CLI that exposes every Creator operation (creating units, composing equipment, adding axes, managing I/O) without the IDE. You call it against a project directory, it reads the AML, loads the semantic model from source, and executes the operation.
What makes this interesting isn’t just headless operation. It’s what it enables downstream.
Every CLI command maps directly to an AML operation backed by real schema definitions. The commands themselves are generated from the AML library, not hand-coded. When we add a new equipment type to the AML library, the CLI command for it is generated automatically from the same schema. Same descriptions, same attribute bindings, same validation. The CLI is a direct projection of the machine model.
Some examples of what you can do:
# Create a new automation project from scratch
zkcreator zautomationproject-create --name Zeugwerk_Quickstart
# Add a unit
zkcreator zunit-create --name Conveyor
# Add a digital output to that unit
zkcreator digitaloutput-create --name ConveyorDrive --unit <unit-guid>
# List all objects in the project (JSON output for scripting)
zkcreator list-objects --output json
# Validate the project (full re-parse, reports syntax errors)
zkcreator validate-project
Output format is selectable: human-readable text for interactive use, JSON for scripting and integration.
The MCP Server
The CLI is useful. The MCP server is where things get interesting.
MCP (Model Context Protocol) is the protocol that AI agents like Cursor, Claude Desktop, and others use to call external tools. An MCP server exposes a set of tools the agent can invoke during a conversation. The agent decides when to call them; the server executes them deterministically.
Creator 1.8 brings an MCP server built on top of the CLI engine:
zkcreator mcp
That’s all you need. The server starts on stdio, registers all Creator tools, and any MCP-compatible agent can use them. The tools are, again, generated from the AML schema. Descriptions, parameters, validation: all derived from the same source that drives the CLI.
The result is that an AI agent can build a complete TwinCAT application from scratch:
- Agent calls
zautomationproject_create→ project skeleton and solution files appear on disk - Agent calls
zunit_create→ a unit function block is generated with the correct Zeugwerk Framework inheritance - Agent calls
digitalinput_create,zequipmentactuator_create, etc. → I/O and actuator code generated deterministically - Agent calls
sequence_create→ state sequences scaffolded correctly - Agent calls
validate_project→ full re-parse confirms no syntax errors
The agent doesn’t write this code by guessing. It calls tools that generate structurally correct, framework-compliant code every time. The LLM handles intent (what should this machine do); the MCP handles structure (how the code must be laid out).
Watch the video demo below.
The Documentation Tool: Getting the Logic Right
Deterministic structure generation solves one half of the problem. The other half is logic: when the agent writes the actual ST bodies (state machine transitions, sequence conditions, actuator control) it needs to know the correct method signatures, property names, and available overloads for framework types.
LLMs don’t reliably know the Zeugwerk Framework API. They shouldn’t have to guess it from reading existing source files.
Creator 1.8’s MCP server will include a get_doc tool that fetches live documentation for any framework type:
get_doc(type_name="ZApplication.Sequence#Await2")
→ returns the full method signature, parameters, description, and examples
directly from the published framework documentation
get_doc(type_name="ZEquipment.DigitalInput")
→ returns the type summary, properties, inherited methods
The documentation comes from the same source we maintain for human developers: doc.zeugwerk.dev. It’s always current, it’s comprehensive, and it includes examples written for real use cases. The MCP server just makes it machine-readable in a form agents can consume on demand.
The combination is what closes the loop: structured code generation that the agent can’t get wrong, plus API documentation that lets it write correct logic.
Why This Matters Beyond Beckhoff
We started this work because of PLC++. But the architecture we landed on has implications that go further than adapting to a shifting ecosystem.
The codec abstraction isn’t theoretical. A project using Simatic AX today can be targeted by the same Creator engine. Any vendor shipping plain-text ST files (and the industry is moving that direction) can be served by the same toolchain. The AML document describing the machine doesn’t change when the code format changes.
The MCP interface makes Creator’s capabilities available to any agent, in any host environment. Not just Cursor. Not just Windows. Not just Visual Studio. Wherever MCP is supported, you can run a Creator-powered agent workflow.
And the documentation integration means agents working with the Zeugwerk Framework don’t have to rely on training data. They query live docs. This is a significant reliability difference: the agent confirms method signatures rather than hallucinating them.
What This Means If You’re Building PLC Tooling
Building a parser and semantic model for structured text is genuinely non-trivial work. Handling the full type system, inheritance chains, interface resolution, namespace scoping: none of this is straightforward when you’re working from scratch with source files and no IDE to lean on.
We’ve been building this infrastructure for years. The semantic model that drives Creator’s CLI and MCP is the same one that drives the VS extension. It’s tested, maintained, and handles the edge cases that production TwinCAT codebases generate.
If you’re running a PLC software business and thinking about what a potential shift away from the Automation Interface means for your tooling, or thinking about how to expose your own framework or IP to AI agents, we can help with that. Not just by pointing at our products, but by helping you build the parsing and semantic layer you’d need underneath it.
What’s Coming in Creator 1.8
Here’s what the release includes:
zkcreatorCLI: Full command-line access to all Creator operations. SupportsTwincatPlcandStructuredTextcodecs via--codec. JSON output via--output jsonfor scripting.zkcreator mcp: MCP server on stdio. All CLI tools exposed as MCP tools, descriptions and parameters generated from AML schema.get_doctool: Live documentation lookup for any Zeugwerk Framework type, with member-level resolution (Type#Membersyntax).validate_projecttool: Full re-parse with syntax error reporting. Updates semantic model for subsequent calls.list_objects/get_object_by_id: Query the AML application model. Returns all created objects with types, GUIDs, and attribute data.- Codec abstraction:
TwincatPlcCodec(.TcPOU/.TcDUT/.TcGVL) andStructuredTextCodec(plain.st) feeding a shared semantic model. - Axes in AML: Axis types are now first-class AML objects with their own SystemUnitClasses, making them manageable through the same CLI/MCP interface as all other equipment.
- AML schema migrations: Automated migration from AmlLibs 1.7 to 1.8 with backward compatibility.
- Installer integration: CLI and MCP server are bundled with the standard Creator installer.
Creator 1.8 is releasing soon. Questions, or want to see a demo of the agent workflow in practice? Reach out.
Resources from the demo
- Zeugwerk Framework documentation: the live docs the agent queries via
get_doc - Tutorial-Quickstart on GitHub: the project the agent implements in the demo; a reference showing how a Zeugwerk Framework application is structured
- Tutorial-Quickstart-Visualization on GitHub: 3D visualization of the same project