TL;DR Point a coding agent at a TwinCAT solution and it will invent methods, enum values and library APIs that do not exist in the versions you actually pin. That is a visibility problem: the types live in
.libraryand.compiled-libraryarchives the agent cannot open. plcsense gives agents a correct, read-only view of your solution and every referenced library over MCP. It runs locally. Early access is open for a small number of real TwinCAT projects.
If you have pointed Cursor, Claude Code or another coding agent at a TwinCAT solution, you already know the failure mode. Ask it to touch Structured Text and it will confidently call a method that does not exist, invent an enum value, or mix in an API from a library version you never installed. Reviewing that output ends up costing more than writing the code yourself.
That is not a typing problem. It is a visibility problem. The types your code depends on live in referenced .library and .compiled-library archives, which are not source an agent can open directly, so it fills the gap with something plausible. Structured Text is also thin in training data compared to mainstream languages, and nothing in the prompt tells the model which library version your project actually pins.
plcsense gives agents a correct, read-only view of your TwinCAT solution and every library it references, over MCP.
What it actually does
Four things agents get wrong today, answered from your project instead of guessed:
- Symbol resolution, not grep. Resolve a name to its declaration across POUs, DUTs, GVLs and referenced libraries, then find implementors and call sites, including the
SUPER^override calls that text search walks straight past. - Library APIs without XAE. Reads
.libraryreferences straight out of the solution, so an agent sees the members and signatures of the versions your project actually pins. - Documentation that matches the version. If you publish with zkdoc, plcsense reads the pages for the release your project actually references, not last year’s export. Agents can also pull Beckhoff Infosys for official vendor prose and hardware specs, or Atlassian Confluence Cloud spaces you configure for internal and OEM docs.
- Diagnostics before you commit. Validate Structured Text and get syntax errors back in original file coordinates, so an agent can check its own edit instead of hoping.
The agent calls these tools over MCP. Here is the equivalent CLI output against a demo solution:
$ plcsense tool list_plc_libraries --include_type_names true --library_name AcmeSealingLib
Solution SealingCell · 1 PLC project
SealingCell (1 library)
AcmeSealingLib 1.0.0.0 · resolved (reference) · 4 types
types: FB_SealHead, FB_SealJaw, E_SealMode, ST_SealRecipe
$ plcsense tool read_plc_source --symbol_name FB_SealHead
FunctionBlock FB_SealHead · __library__/FB_SealHead.st
[source=vendor_library, confidence=source_provided, library=AcmeSealingLib]
Declaration · L1-14
```iecst
FUNCTION_BLOCK FB_SealHead
VAR_INPUT
iEnable : BOOL;
iTemperatureSetpoint : LREAL;
END_VAR
VAR_OUTPUT
qReady : BOOL;
qFault : BOOL;
END_VAR
```
### Method Seal
Declaration · L16-22
```iecst
METHOD Seal : BOOL
VAR_INPUT
iRecipe : ST_SealRecipe;
END_VAR
```
$ plcsense tool validate_plc_project
HasErrors · 1 project · 48 types · 1 error
root: ./SealingCell (from --root)
POUs/FB_Main.TcPOU
42:9 error Unknown identifier 'SealHeadd' (SealHeadd)
Every answer comes with that kind of provenance, so you can see where it came from.
It runs on your machine
plcsense is a local process that reads local files. Your source, your proprietary libraries and your customers’ projects are never uploaded for analysis. What leaves the machine is short enough to list in full: a licence check, opt-out tool-usage telemetry with no code or symbol names in it, and opt-in feedback you can enable explicitly. Nothing else.
When you will actually notice it
Probably not on the first small task. Add one line to a function block you already know, and reading the file is enough: an agent guessing from what is on screen looks just as good.
Touch a referenced library type and it can still look fine, not because the agent understands the library, but because you compile constantly in TwinCAT, and the .tmc from the last build can already have that member’s name and signature on the symbol tree, ready to grep. What it will not have is the rest of the library surface you have not called yet, which override actually runs when more than one type implements the same interface, or a single view across a multi-project solution.
That is where the gap opens: a rename across many POUs, an interface with more than one implementer, or a project someone else wrote. find_plc_implementations and find_plc_references answer by type, not by text. The failure this is meant to catch is not an obviously wrong answer. It is a rename that compiles with one call site quietly left untouched.
What it is not
plcsense reads. Your editor writes, TwinCAT builds and deploys, and that split is deliberate. No inline completions, no code generation, no ADS or runtime access. plcsense is also meant to integrate into Beckhoff CoAgent later, and for that it has to stay read-only intelligence, not a second editor or deploy stack.
Early access
plcsense is in development. We are taking on a small number of real TwinCAT projects before launch, to find what breaks on them before anyone else does. Tell us what you are working on, the libraries you depend on and the agent you use, and if it is a solution we can learn from, you get an access token and a licence key directly from the people building it. No newsletter, no sales sequence.