AI agents can write SCL. TIA Portal MCP is what lets them open the project.

A few weeks ago a model wrote a conveyor-sorting state machine for an S7-1500 in about ninety seconds. Clean SCL, correct state numbering, IEC timers instead of hand-rolled scan counting. It compiled on the first try.

Then it stopped. Not because it ran out of ideas — because it had no way to open the project, add the CPU it had just written code for, or check whether the block it produced even fits the hardware on the bench.

That gap is the whole story of AI in industrial automation right now. The model is good enough. The connection is missing.

Writing code was never the hard part

Watch an experienced controls engineer for an hour and count how much of the hour is "typing logic". It's small. The rest is: reading the existing project, checking which DB members a network already writes, adding a module, assigning an IP, wiring an IO system, compiling, downloading to a simulator, forcing an input, reading the tag back.

An LLM can do the first thing on that list from a paste. It cannot do any of the others unless something exposes them as callable operations.

That is what an MCP server does here. Not a chatbot with TIA Portal documentation in its context — a TIA Portal MCP server turns TIA Portal operations into tools the agent can call and whose results the agent can read back.

What a TIA Portal MCP server actually exposes

Concretely, the useful surface is not one big "do PLC things" tool. It's a set of operations grouped by what they touch:

• Read — project tree, block source, tag tables, UDTs, cross-references, HMI screens, hardware configuration.
• Understand — index the project into a knowledge graph: blocks and interfaces, who calls whom, which DB members a network reads or writes, dangling references, what a change would break.
• Write — create or rewrite SCL, import SimaticML (LAD included), edit block interfaces, compile one block or the whole PLC.
• Configure — add a CPU, insert modules, create subnets, wire IO systems, assign IP addresses and PROFINET device names.
• Verify — unit-level scenario suites against a simulator (PASS/FAIL, CI-friendly), and machine-level runs on S7-PLCSIM Advanced with tag values compared against expectations.
• Archive — save, export SimaticML, archive the project so the change has a before/after.

The list matters less than the order it allows:

read the block → propose a change → dry-run → write → compile → simulate → read back → keep or roll back.

That ordering is the difference between "the model wrote something plausible" and "the model changed the project, and here is the evidence". Every step leaves an artifact a human reviewer can check without re-running the session.

If you are evaluating a TIA Portal AI tool, the question to ask is not "can it write SCL". Almost everything can. The question is whether it can read back what it wrote, and whether it can be stopped before the write lands.

The part people underestimate: project context

Feed a model a single FB and it writes good code. Feed it a 400-block project and ask for a change to network 7 of FB_ConveyorSort, and it will happily use a tag name that exists in a different DB, or call a function block whose interface it guessed.

This is why the "understand" step above exists. In practice the first useful query is not generate but what does this project already do:

• which blocks call this FB, and with which instance DBs
• which DB members this network reads and writes
• which references dangle after the last import
• which of these tags are already used elsewhere with a different type

An agent that skips this step produces code that compiles and then surprises you at commissioning. The failure is not the model's ability — it's that nobody gave it the project.

Guardrails, because writing is the easy half

Three rules that turned out to be non-negotiable:

1. Dry run before every write. The write is previewed as a diff against the current project. Nothing touches the file until a human or the agent's own policy accepts it.
2. Compile is a gate, not a formality. A block that does not compile is never downloaded. This sounds obvious until you watch an agent retry a download four times against a stale compile.
3. Simulation decides, not confidence. S7-PLCSIM Advanced runs the scenario and returns tag values; pass/fail is a comparison, not an opinion. Changes stay reversible at block level, so a bad edit is a diff, not an incident.

And the limit, stated plainly: safety stays in hardware. Emergency stop, hardwired interlocks and timing tuning are not verified in a simulator. What the agent verifies is the software part — logic, structure, interfaces, compile cleanliness, scan-cycle behaviour. Anything that could hurt a person belongs to a hardwired circuit and an engineer's signature.

Three ways teams automate TIA Portal today

Approach	What it touches	Where it breaks
GUI automation (click the window)	The UI	Any dialog change or language switch breaks the script, and almost nothing reads back reliably
Openness scripts (C# / PowerShell, one per task)	The API	Precise, but a human writes one script per task and the agent cannot explore beyond it
MCP server (Openness exposed as tools)	The API, via MCP	The agent picks the tool and reads the result — which is exactly why write paths need guardrails

The first two are what most teams already have, and neither is wrong. An MCP server pays off when the same kinds of operations repeat: another motor, another interlock, another block to port from an old project. For a one-off script, it's overkill.

Connecting it

The server runs on the same Windows machine as TIA Portal, because Openness only exists there. Clients can sit anywhere on the LAN. Any MCP client that speaks Streamable HTTP with a bearer token works:

# Claude Code
claude mcp add --transport http tialink http://192.168.1.110:8080/mcp \
  --header "Authorization: Bearer <token>"
claude mcp list

{
  "mcpServers": {
    "tialink": {
      "url": "http://192.168.1.110:8080/mcp",
      "headers": { "Authorization": "Bearer <token>" },
      "timeout": 180
    }
  }
}

Clients that only speak stdio use a small MIT-licensed forwarder:

npx tialink-mcp --url http://192.168.1.110:8080/mcp --token <token>

One practical note: raise the client timeout. Adding a CPU or importing an SCL block takes tens of seconds on a slower machine, and a 60-second default fails on the "normally slow" operations. That failure looks like a bug in the server and is really a client setting.

A small batch-copy example — one device program copied from a spreadsheet of tag names, then compiled and checked — is in the public repo, along with the docs.

Requirements and limits, without the marketing

• TIA Portal V19 / V20 / V21 on Windows (V21 needs TiaLink 1.5.0 or later).
• The Windows account running the gateway must be in the Siemens TIA Openness user group.
• A licence is issued per machine, bound to the machine code, and runs offline. Without it the connection is read-only — which is a reasonable default to start from.
• Commercial, closed-source. The public repository holds documentation, examples and the MIT-licensed stdio adapter; the adapter cannot work without the gateway.
• Third-party tool by Hubwiz. Not a Siemens product, and not an alias for anything Siemens ships.
• No cloud, no outbound connection. Project data stays on the machine.

When this is the wrong tool

• You need it today for a one-off. Writing the Openness script is faster than wiring an agent.
• You want the agent to decide safety-relevant behaviour. It should not. Hardwired interlock, human sign-off.
• Your TIA Portal version is older than V19. Openness coverage drops; the tool surface shrinks accordingly.
• The project is unversioned and nobody can review a diff. Automation without a before/after is how you get a 2 a.m. rollback with no baseline.

The shift worth paying attention to

The interesting change is not "AI writes PLC code". Tools have done that for two years.

It is that the agent can now close the loop on the bench: propose, write, compile, simulate, read back, and hand you the evidence. Once that loop exists, the human's job moves up a level — from typing the state machine to deciding which change is acceptable, and which part of the system must never be automated at all.

We built TiaLink for that loop: one MCP endpoint for project read/understand/write, hardware configuration, ladder via a JSON contract, compile, and simulation, on V19–V21. If your team is testing whether an agent can do real work in TIA Portal rather than just talk about it, that's the shortest path we know to find out.