How to build an MCP server for Ignition (MES/SCADA)
Short answer
Build an Ignition MCP server as a small service that exposes read-only tools over the Gateway: tag values, historian aggregates, active alarms and MES queries. Use WebDev endpoints or a read-only database account behind it, authenticate each user, cap result sizes and log every call. It then works with Claude, ChatGPT and other MCP clients.
A Model Context Protocol server is a thin adapter. On one side it speaks MCP to whatever client the user prefers. On the other it speaks to Ignition in the ways Ignition already supports. The value is that you define the tools once and they work across clients, rather than rebuilding a custom integration for each assistant.
For a SCADA and MES platform, tool design matters more than protocol details. A tool that returns the entire tag tree is useless and risky. A tool that returns the last twelve hours of aggregated values for one validated tag path is useful and safe. The shape of your tools is the shape of your permission model.
This page covers how to structure an Ignition MCP server: which tools to expose first, how to reach the Gateway, how transports and authentication work, and how to keep it safe in a plant environment.
What teams use it for
Tag lookup and discovery
search_tags finds tag paths by name, description or UDT type from a cached catalog, and get_tag_values returns current values with quality and timestamp for a validated list.
Historian queries
query_tag_history returns aggregated series (average, min, max, count) for a bounded window, so a client can explain a trend without pulling raw samples.
Alarm investigation
list_active_alarms and get_alarm_history provide the event trail for an area and a time range, with priority and source.
Production and downtime summary
get_production_summary and find_downtime_events wrap named queries against your MES schema and return counts, rejects and reason codes.
Project documentation access
A resource lists UDT definitions and view descriptions so a client can answer where a value originates without opening Designer.
Inductive Automation Ignition (MES/SCADA) integration surface
- WebDev module: scripts at doGet and doPost on the Gateway can implement a private JSON API that the MCP server calls. Supports reading tags and running named queries.
- Gateway scripting functions (system.tag, system.db, system.alarm and historian query functions) are what those endpoints call. Check exact signatures in the manual for your 8.1 or 8.3 version.
- Named queries with typed parameters give a controlled SQL layer, with permissions managed per project and database connection.
- Direct read-only SQL to the historian and MES databases is an option for heavy or bulk queries, bypassing the Gateway but needing care with partitioned historian table names.
- OPC UA and the Sparkplug or MQTT ecosystem are alternative data paths, useful if a broker already carries your tags and you prefer to subscribe rather than poll.
- Gateway identity providers and security zones let you align MCP users with existing roles instead of inventing a new permission store.
How it works
- 1
Pick the language and SDK
Use the official MCP SDK in Python or TypeScript. Run it as a service, containerised if your site allows it, in the same network zone as the Gateway.
- 2
Design tools with narrow schemas
Each tool takes explicit parameters, such as a tag path list with a maximum length, a start and end time with a maximum span, and an aggregate type. Reject anything outside the schema.
- 3
Build the Gateway side
Create a project with WebDev resources and named queries that implement each tool. Keep them read-only and return compact JSON with units, quality codes and timestamps.
- 4
Choose the transport
Use stdio for a single user on a workstation. Use an HTTP-based transport for shared use, behind TLS, with token authentication and per-user identity.
- 5
Enforce permissions
Map each MCP user to an allowed set of tag providers, areas and lines. Do this in the server, not in the prompt, and log denials.
- 6
Add audit, limits and tests
Write each call to a log table, apply rate and size limits, and run contract tests against a staging Gateway before any production use.
- 7
Add write tools last
If a write is truly needed, implement it as a request that creates a pending item for human approval, not a direct tag write.
Example flows
Where does this number come from
Trigger: A user asks a client for the source of the OEE value on the Line 5 screen.
- Client calls search_tags for the OEE tag on Line 5.
- Server returns the tag path, UDT type and expression or source reference from the catalog.
- Client calls get_tag_values for the input tags that feed it.
Result: A plain explanation of the calculation and its current inputs.
Bounded history query with guardrails
Trigger: A client requests thirty days of one-second data for a motor current tag.
- Server checks the requested span against the maximum window.
- Server rejects the call and suggests hourly aggregates for thirty days or raw data for one hour.
- Client retries with a valid request.
Result: The historian is protected and the client learns the limit from the error message.
Audit of a shift conversation
Trigger: A supervisor questions what an assistant told the night team.
- Reviewer opens the audit table filtered by user and time.
- Each tool call, parameters and result summary appear in order.
Result: A clear record that supports quality review and trust in the tool.
Keeping data on-prem
An MCP server is a natural fit for on-prem Ignition because it runs wherever you put it. Host it in the plant or site data center, give it a route only to the Gateway and the databases it needs, and connect it to clients on the internal network. Pair it with an open-weight model served locally so that no tool result leaves the site. If some users work remotely, expose the MCP HTTP endpoint through your existing VPN or zero-trust gateway rather than opening a port. The same server can later serve a cloud client if policy changes, because the protocol does not change.
Security checklist
- Authenticate every user and tie their identity to allowed tag providers, areas and lines inside the server.
- Never accept raw SQL or arbitrary scripts from the client; all queries are named and parameterised.
- Cap response size, history span and tags per call, and rate limit by user.
- Use read-only database credentials and a dedicated Gateway service identity with no designer or admin rights.
- Treat tool descriptions and returned text, including alarm descriptions, as content that could carry injected instructions.
Ways to get it done
Open-source or community MCP server for generic SQL or OPC UA
Effort: Hours to days, but limited controls and no Ignition specific tools.
Quick experiments against a test historian database.
Build your own on WebDev and named queries
Effort: Two to six weeks for a solid read-only set with logging.
Teams who want tight scope control and own the code.
Partner build such as Netray
Effort: Scoped per site, often a pilot on one area first.
Plants that want the MCP layer plus an on-prem model, permissions and review process.
Pitfalls
- !Exposing a generic query tool that lets a model write its own SQL against the historian.
- !Forgetting that historian table names can change by partition and by version.
- !Returning raw samples by default, which overloads both the database and the model.
- !Running the server on the control network instead of a controlled zone above it.
- !No test plan, so a Gateway upgrade silently breaks a tool and the assistant starts answering from stale or empty data.
Frequently asked questions
Does Ignition have a built-in MCP server?
Check the current release notes and the module marketplace, because offerings change quickly. If nothing meets your needs, building a server over WebDev and named queries is practical and gives you full control over what is exposed.
Should the MCP server talk to the Gateway or the database?
Use the Gateway for live tags and alarms, since the values exist only there. Use named queries or a read-only database account for historian and MES history, where the data already sits in SQL.
Which transport should we use?
Stdio suits a single engineer on a workstation. For several users, use an HTTP-based transport with TLS and token auth behind your reverse proxy. The choice affects deployment and identity, not the tool definitions.
Will it work with ChatGPT as well as Claude?
MCP is supported by a growing list of clients, including Claude and some other assistants. Support in each product varies by plan and version, so confirm before committing. A well built server does not depend on one client.
How do we prevent unsafe writes?
Do not expose write tools initially. When needed, make them create a pending request that a named, authorised person approves in Perspective, and have the Gateway perform the write under that person's identity with logging.
Want MCP server working on your Inductive Automation Ignition (MES/SCADA)?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment