# How to build an MCP server for Ignition (MES/SCADA)

> Source: https://netray.co/integrations/ignition-mcp-server
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Integrations

## 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.

## System

Inductive Automation Ignition (MES/SCADA)

## Capability

mcp-server

## Intro

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.

## Use Cases

### Tag lookup and discovery

**Description:** 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

**Description:** 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

**Description:** 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

**Description:** get_production_summary and find_downtime_events wrap named queries against your MES schema and return counts, rejects and reason codes.

### Project documentation access

**Description:** A resource lists UDT definitions and view descriptions so a client can answer where a value originates without opening Designer.

## System 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

### Pick the language and SDK

**Detail:** 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.

### Design tools with narrow schemas

**Detail:** 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.

### Build the Gateway side

**Detail:** 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.

### Choose the transport

**Detail:** 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.

### Enforce permissions

**Detail:** 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.

### Add audit, limits and tests

**Detail:** Write each call to a log table, apply rate and size limits, and run contract tests against a staging Gateway before any production use.

### Add write tools last

**Detail:** 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.

**Steps:**

- 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.

**Steps:**

- 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.

**Steps:**

- 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.

## 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

- 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.

## Options

### Open-source or community MCP server for generic SQL or OPC UA

**Fit:** Quick experiments against a test historian database.

**Effort:** Hours to days, but limited controls and no Ignition specific tools.

### Build your own on WebDev and named queries

**Fit:** Teams who want tight scope control and own the code.

**Effort:** Two to six weeks for a solid read-only set with logging.

### Partner build such as Netray

**Fit:** Plants that want the MCP layer plus an on-prem model, permissions and review process.

**Effort:** Scoped per site, often a pilot on one area first.

## 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.

## Faq

### Does Ignition have a built-in MCP server?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

ignition mcp server, mcp server for scada, model context protocol ignition, inductive automation mcp, build mcp server for mes, ignition webdev mcp, mcp server historian, mcp for industrial automation, ignition llm tools, scada mcp on-prem

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json