Anyone have any guidance for how to use Ignition with Claude or any other LLM? You can make expert level web pages with just a few properly structured prompts. Can we do the same with Ignition? I have a Vision project that I want to port over to Perspective, and I think Claude would make an expert level dashboards but I am not sure where to start with it.
-
Please read the FAQ, particularly the rule about LLM content here.
-
Don't expect LLMs to produce working code or configurations for Ignition. Ignition is too small a niche. You have to already know how to work with Ignition to deal with the hallicinations and mis-application of what LLMs think are the right standards.
learn how to use perspective is the short way. Ai can help with making styles or blueprint in html so you can use as a reference for building your perspective views. and try to use standard features of perspective to keep your project stable and maintainable. good luck
@a.alghannam is 100% correct. The allure of LLM/AI is that it will be the magic push button to just make your project for you. But even in cases where it does - it is making a lot of decisions/assumptions that maybe you wouldn’t want. And with Ignition too I don’t think any LLM' is that great with it.
You will waste more time trying to get Claude to do it correclty, going back to fix things manually etc, than to just learn to do it imo. Ignition already makes it easy for you with a drag and drop page builder, learn the basics and just start imo.
Ah, looks like I kind of stepped into something here. I appreciate all the feedback.
I spent about 6 months on this vision project mostly working on the tag side contextualizing and normalizing data, and make the corresponding dashboards in Vision because the license was potentially cheaper (that was my thought process anyway). I have been very deep in the weeds with the tags, scripting, expressions, etc and have achieved very nice results. AI is absolutely ducks guts on working with the JSON files. It makes very stupid mistakes and you often have to “start over” with a chat window, and most of the time I wonder if I would be quicker and better without it but at the end of the day, it is just going to do better and better so better get used to it and once you get across the learning curve you will be pretty unstoppable with your AI enhanced workflows. Enhanced being the key word there.
The main problem I have is that I do not have access to the real banger IDE’s like Claude, so I use Google products which are not as good at coding. Claude released 4.5 Opus yesterday and it absolutely leap frogged everything before it. In 6 months, nobody will even be talking about it, as it itself will be leapfrogged.
I think in 20 years we will be talking about AI hallucinations like Boomers talk about the sound of dial up modems….
Walker Reynolds at the Tulip Operation Calling recently said that the drag and drop old way of creating dashboards is dead, and that AI will know better what to do with the data and how to present it (If you prompt it correctly of course) and will do it lightning fast. Look at how it does websites apps already it is insane. So pretty short sighted I think to not think that very shortly this will happen for Perspective.
The MCP module for Ignition is supposed to drop 1st quarter next year right? That is pretty much along the lines of what I am talking about. It will probably be a year or so I predict before we are fully at the create yourself dashboards, so Engineers will focus on the contextualizing the data with their domain expertise.
Again, appreciate all the comments. I think for now the best bet is to learn perspective the hard way, and use the tools where I can (like JSON files) but with heavy heavy heavy oversight. It is kind of funny when I first started using AI i was super polite to it, calling it Sir sometimes. now I pretty much just rag doll it any chance I get, lol. Hope that it doesn’t hold a grudge in a few years, 
Not to get too off topic on an ignition forum but having spent the last few weeks pouring over AI business stuff -
In 6 months, nobody will even be talking about it, as it itself will be leapfrogged.
We will see. There’s basically no more training data left in the world for LLM’s. The only extra juice they’re getting out of them now are by making them reasoning aka burning more tokens/compute. Anthropic and openAi are the ones we know about are spending more on inference (the computation for the results of your prompt) then their revenue. There’s also no good way to properly quantify and sell things like a prompt. This leads to things like https://www.viberank.app/ where someone can pay 2k a month and then cost anthropic over 50k in less than 1 month. This is the case across the board, the more users and more usage AI companies have the more money they are burning. The new inference chips are the next / probably last hope at reversing this. So we will see if these companies are even financially viable in a few years and not just the money pit’s they have been for the last 4-5 years. Not trying to be petty or cute here but you can also just get better and better at perspective by using it yourself.
I think in 20 years we will be talking about AI hallucinations like Boomers talk about the sound of dial up modems….
Not possible. They are inherently a part of LLMs infrastructure and how they work. They cannot be coded out or done away with with more training data (of which there isn’t anymore anyways!).
Walker Reynolds at the Tulip Operation Calling recently said that the drag and drop old way of creating dashboards is dead,
No idea who this person is but that is what feels short sighted imo. What is faster, dragging and dropping components in the exact manner you know you want them to appear, or to prompt, view, re-prompt, re-view, re-query. You said it yourself you need to prompt it in the right way. Or you can just drag and drop it once lol. It feels like people are just like oh cool new toy! But the old way of doing it yourself is direct, from your mind onto the screen. Not this from your mind, into a prompt, into hoping AI understands your prompt correctly, and then reviewing and re-trying.
Hope that it doesn’t hold a grudge in a few years,
We’ll see if it hasn’t given way to the next tech hype train by then in quantum lol
Yup. Us volunteers on this forum have seen a lot of LLM hallucinations in the past couple years, and aren't happy. Feel free to carry on with LLMs, but don't bring that broken [expletive] here for us to help fix.
I know Walker personally, and he's super smart, but he might be overdosing on his own hype.
But even if you end up right about LLM code assistance, the fact that Ignition is such a small niche is still going to be a huge hurdle. I will continue toying with LLMs, but I won't rely on them for my business. We'll see about the future.
Things LLM’s struggle with:
- They scrap sites, including forums, which often times injects non-functional code that people post. So there’s often hallucinations on functions that do not work but the LLM will repeatedly push it as working
- They also struggle with versions, often they suggest code that is deprecated. They often don’t properly track the differences between say 7.9 and 8.3.
What LLMs do well and can be useful for:
- Create test cases or inject diagnostics into your code when you are running into issues you are trying to track down
- Formatting and documentation after scripts are finished
- Feeding it specific object formatting and having it replicate with input data
Things people using LLMs do poorly:
- Not understanding defining requirements and setting up contextual guidance in the prompts.
At the end of the day LLMs are simply a tool and need to be treated as such. They can be quite powerful when used well but they can, and often do, lead people astray and cause grief.
Thanks for all the feedback. I decided to jump feet first into Perspective with no LLM assistance and after about 8 hours of deep dive I am starting to understand my way around a little bit better. I understand there is no easy way. Coding has always, always, always been the easy part, so anyone using LLM strictly because they do not know how to code in the first place is very scary. Anyway, glad I asked the question and now I better understand how to approach the problem. Wish I would have dove into Perspective sooner, finding a lot of awesome resources on the Exchange.
In my view, Ignition’s value has always come from simplifying things that used to be hard. AI is rapidly erasing that barrier. We already have IDE agents that write code, generate tests, and automate workflows that used to require real expertise. If AI keeps shrinking that complexity while enabling deeper customization, Ignition’s main differentiator weakens.
I don’t think Ignition can afford to sit this out. The newest models are on a different level, and progress is accelerating. Ignition needs to align with that reality.
What part of “Inductive Automation announced an MCP plugin for ignition” strikes you as IA sitting this one out?
My comment was a response to the skepticism I’m seeing here about the module’s possibilities. I don’t think Ignition is falling behind, but the discussion here makes it seem like the module is more of an AI-trend reaction than a real competitive advantage.
I've said it before and I'll say it again. Any monkey can write code, including LLMs and AI. But that’s not the value of a system integrator or engineer using Ignition…Ignition is after all, just a tool. It’s akin to anyone can swing a hammer and drive a nail. But are you going to trust anyone to put a roof on your house? AI and people that rely on it to build fully implemented and integrated SCADA and controls systems are going to build some shitty and leaky roofs.
My impression of the MCP module is that it will be a godsend for analyzing all the data a SCADA system produces, to derive useful insights and improvement opportunities. Without necessarily pushing the data to 3rd parties.
This topic is about using LLMs to creatively construct a Perspective project. Instead of derivatively, which is all that I see LLMs doing in the code space. For now. 
Yes, skepticism. Justified by the face-plants that show up here.
This just popped up on my radar:
If you are using Claude, you may be in trouble.
Hello everyone,
In these last days of May 2026, we set up a hardware and software test lab to produce views, named queries, scripts, and much more using Claude Code CLI and Ignition. The results far exceeded our expectations, allowing us to develop a complete SCADA BMS from scratch in approximately 8 hours, simply by asking the AI ​​for the system content and behavior, including screens. Here are some examples of how a simple prompt is transformed into a functional screen, with scripting, named queries, bindings, etc.
Sample Prompt 1:
WORKFLOW YOU SHOULD FOLLOW
- Build a LOCAL harness in Python that replicates the rendering logic (same code
as will be in Jython) and rasterizes the SVG to PNG using Chrome headless. Iterate the DESIGN therequickly
with REAL DATA from the DATABASE before touching Ignition. To validate the complete logic
(query->events->SVG), run it with stubs from
system.
Check the Gateway trial before each burst of changes (renew it if it expires).
Edit the Gateway via MCP (patch_script/add_component/add_binding). Validate syntax
by mirroring to disk + ast.parse, and validate the rendering with the harness.
Maintain a "memory" file with the inventory of the original view and the gotchas.
Do NOT commit/push until the user requests it; when they do, mirror the Gateway to the repository and commit only your specific files (using
git add, never-a).ACCEPTANCE CRITERIA
The view looks like the mockup (professional weekly timeline, UPC aesthetic).
Users can: select equipment, navigate weeks, add schedules (any equipment from AllEquipments, recurring/one-off/holiday, with instructions), delete the selected equipment,
upload to the PLC, and go to the calendar. The timeline refreshes automatically upon saving.Local hours. The original Scheduler view and the Add_Events popup are not broken.
RESULT
Of course, we had to build an mcp-ignition server, which allows us to insert the screens into the project directories, and this took us a week of work. Then we had to "teach" the LLM how to design screens, use components, and train the system by "viewing" many SCADA systems made with Ignition, but the result is more than promising.
See you Skynet !! 
Bye.
I’m not certain that MCP is required for adding resources to the project directories. An agent could have access to existing tag structure and project folder without MCP. However, you prompted for REAL DATA, so it may have used MCP for that.
Details aside, I will second that workload can be substantially reduced by utilizing a modern agent. There’s still a lot of cleanup required… Yesterday, (without MCP) Claude built a view to populate a table via a historical query within a nested for-loop, and a trend that updated based on mouse events… Even still, hours were saved, and a couple of fresh ideas were implemented that I wouldn’t have otherwise considered.
It's true that simply modifying resources doesn't require mcp-ignition, as accessing the project path C:\Program Files\Inductive Automation\Ignition\data\projects is sufficient for adding screens, views, named queries, etc.
However, mcp-ignition provides a way to centralize complete control of an Ignition deployment on a local or remote machine.
Our mcp-ignition has 124 commands, allowing you to manage not only designer resources but also gateways, restart systems, access the project database, edit \Ignition\data\db\config\config.idb, add devices to the gateway, add tag providers, manage users, and more. This grants us almost total control over the creation of Ignition applications on a client machine.
Actually MVP draft version of this mcp-ignition allows make the follow actions
list_projects · create_project · delete_project · set_perspective_home
list_views · read_view · write_view · create_view · delete_view · move_view · copy_view · validate_view · diff_view · patch_view ·get_view_summary · find_view_references · describe_component
list_scripts · read_script · write_script · create_script · delete_script · move_script · copy_script diff_script · patch_script
get_resource_info · list_resource_types · list_resources · read_resource · write_resource · delete_resource · move_resource · copy_resource
list_backups · restore_backup
list_styles · read_style · write_style · read_stylesheet · write_stylesheet · read_session_props · patch_session_props
list_webdev_endpoints · read_webdev_endpoint · write_webdev_endpoint
list_named_queries · read_named_query · write_named_query · create_named_query_with_sproc
tags_config · tags_connect_check · tags_browse · tags_read · tags_write
gateway_ping · gateway_info · list_perspective_projects_http · gateway_log_path · read_gateway_log · get_gateway_diagnostics ·list_designers
gateway_license_state · gateway_trial_status
get_mcp_token · provision_mcp_webdev · runtime_ping · runtime_scan · runtime_tag_read · runtime_tag_write · runtime_tag_browse · runtime_log
list_components · add_component · remove_component · add_binding · remove_binding · add_button_navigation · add_label · add_button ·
add_dropdown · add_numeric_entry · add_table · add_power_chart · add_equipment_schedule · add_event_script · remove_event_script ·add_custom_method · add_message_handler · scaffold_view_from_template
git_repo_status · git_repo_diff · git_repo_log · git_repo_commit · git_repo_branch · mirror_resource_to_repo · mirror_project_to_repo
db_list_connections · db_show_active · db_add_connection · db_set_active · db_remove_connection · db_test_connection · sql_exec_query
sql_exec_dml · sql_list_databases · sql_list_tables · sql_describe_table · sql_list_sprocs · sql_get_sproc_definition ·sql_create_or_alter_sproc · sql_drop_sproc · sql_test_sproc_call
lint_named_queries_against_db · lint_project_scripts_against_db
But we are working to expand these functionalities to allow us to configure projects more efficiently.
Hopefully one day we can enjoy an Inductive MCP with many more features than these, allowing us to use the manufacturer's own tools; meanwhile, we have to "make do" to satisfy our customers.
Genuine question, what is the value add of a lot of these commands? Any of the list_resource style command you are now introducing the non-determinism of a LLM where you can see it directly either in designer, in the gateway, or you could code up a very simple deterministic API endpoint to serve you the values. Same with any read_resource thing. Feels like you're just injecting a LLM into a spot where there's already a very simple and deterministic way to do something, and now introducing the odd hallucination.
I can see write_style being very helpful espeically as someone who is not well versed with CSS but that also is typically the least important of the HMI at least in terms of the damage it can do, and in terms of verifying it, I can just look at the project view and see if it looks right and if a component is being hidden it shouldn't be etc.
All these others. Are you really shipping products where a LLM wrote the code and queries and did the bindings on a view and configured the tags etc? I know you'll probably say you review it all but I also know the research shows that after a few good responses or after sufficient fatigue developers stop checking responses, so it may be true now but if you start getting on the pace of oh we can ship a project a week, your hand reviewing will start to dwindle. Not to also mention if you're reviewing every single line of code and every single component binding and every single tag config after the LLM did it, then it feels like now you actually doubled your work then if you just did it yourself the first time correctly?
I don't know maybe im turning into a crank about LLM's but even if you do the best of things, and I am not saying you don't, the possiblity that someone out there is shipping projects with code, tag configs, queries, etc etc, that they are completely trust claude or w/e did correctly after one cursory glance, is scary to me in this field specifically where physical harm is a potential outcome.
Sorry I know this is a pro LLM forum post here but I am not saying that LLMs are completely useless but I still think a lot of your commands here seem like a solution looking for a problem and maybe there is a better use case for it in iginiton in general for the mcp module?