Loading ToolBench
MCP server for Ignition Gateway REST API automation. Provides curated, well-described tools that give AI assistants a developer-oriented interface to the Ignition Gateway.
Ignition MCP Server demonstrates good overall definition quality with 28 well-named tools, comprehensive descriptions, and mostly complete schemas. All tools follow verb_noun naming convention (get_*, list_*, create_*, delete_*, etc.). Descriptions are detailed and context-aware (150-400 chars typical), explaining WHAT each tool does, WHEN to use it, and relevant prerequisites. Parameter schemas are present and typed. However, gaps exist: output schemas are not formally documented in the tool definitions; some parameters lack enum constraints where applicable (e.g., log level, aggregation mode); error handling guidance is generic; and a few tools expose moderate risk without explicit confirmation patterns. The HTTP transport is current (streamable-http supported). Overall, this is a mature, production-oriented server that would benefit from output schema documentation and tighter parameter validation.
Acknowledge one or more active alarms. Requires alarm event IDs, which you can get from get_active_alarms. The acknowledgement is logged in the alarm journal with the current user (as configured on the WebDev endpoint) and the optional note. Requires the WebDev alarm endpoint. See docs/webdev-setup.md.
Clone an existing Ignition project to a new name. Creates an exact copy of all project resources. The new name must not already exist on the gateway.
Create a new empty Ignition project. The project name must be unique on the gateway. Optionally set a parent project for resource inheritance.
Create a new tag provider on the gateway. Most use cases need a STANDARD provider, which stores tags locally. REMOTE providers connect to another gateway's tags over the gateway network.
Permanently delete an Ignition project. THIS IS IRREVERSIBLE. All project resources (views, scripts, named queries, etc.) will be lost. Consider exporting the project first with export_project.
Output schemas not formally documented in tool definitions. Users and LLMs must infer result structure from descriptions alone. This violates pattern:response-shaper and increases hallucination risk when agents chain tool calls.
Enum constraints missing for categorical parameters. 'level' in get_gateway_logs should be enum [TRACE, DEBUG, INFO, WARN, ERROR]; 'aggregation' in get_tag_history should list valid modes. This forces LLMs to guess valid values and increases failure rate.
Destructive tools (delete_project, delete_project_resource, delete_tag_provider) lack dry-run or confirmation patterns. An agent could accidentally wipe production projects without a safety gate.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | A | 86 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Delete a specific project resource. THIS IS IRREVERSIBLE. Permanently removes the resource from the project. This cannot be undone. Consider listing project resources first (list_project_resources) to confirm the exact path before deleting. No WebDev required — uses native REST API.
Delete a tag provider and ALL of its tags. THIS IS IRREVERSIBLE. All tags within this provider will be permanently deleted. This cannot be undone. Make sure you have a backup if the tags are important.
Export an Ignition project as a ZIP archive (base64-encoded). Returns {filename, content_base64, size_bytes}. The content is the standard Ignition project export format — you can save it as a .zip file and re-import it with import_project. Useful for backups or migration between gateways.
Get currently active alarms from the gateway. Returns active alarm events with source path, display name, priority, state (active/acked), and timestamps for activation and acknowledgement. Requires the WebDev alarm endpoint. See docs/webdev-setup.md.
Query historical alarm journal entries. Returns alarm events (activations, acknowledgements, clears) within the specified time range. Use this to investigate past alarm activity or build audit trails. Requires the WebDev alarm endpoint. See docs/webdev-setup.md.
List all database connections and their current status. Returns connection name, driver, state (Valid/Faulted), and error info. Uses native REST API endpoint /data/api/v1/connections/database.
Get Ignition Gateway version, edition, state, and uptime. Use this first to verify connectivity and confirm the gateway is running. No parameters required.
Fetch recent gateway log entries. Returns log entries with timestamp, level, logger, and message. Use this to investigate errors, module faults, or unexpected gateway behaviour. Note: Uses the native Ignition REST API (/data/api/v1/logs).
List all installed Ignition modules and their health status. Returns module name, version, state (LOADED/FAULTED), and any error messages. Useful for diagnosing why something isn't working before investigating further.
List all OPC-UA / OPC-COM connections and their current state. Returns connection name, type, connection status, and any fault details. Uses native REST API endpoint /data/api/v1/connections/opc.
Get full details of a specific Ignition project by name. Returns the project's configuration including title, description, parent, default database, tag provider, user source, and enabled state.
Fetch the content of a specific project resource. Returns the raw resource content — usually JSON for views and queries, Python source for scripts. AI can read this to understand or modify the resource. Examples: - Perspective view: 'com.inductiveautomation.perspective/views/Dashboard/view.json' - Script module: 'com.inductiveautomation.ignition/script-python/utils/code.py' - Named query: 'com.inductiveautomation.ignition/named-query/GetSensorData/query.json' Use list_project_resources to discover available resource paths.
Get gateway system metrics: CPU, memory, thread counts, active sessions. Returns a snapshot of gateway resource usage. Useful for diagnosing performance issues or understanding current gateway load. Uses native REST API endpoint /data/api/v1/system/metrics.
Query historical tag values from the Ignition historian. Returns time-series data for the specified tags over the given time range. Results include timestamp and value for each data point. Tag history must be enabled on each tag (History tab in tag properties). Use browse_tags to find tag paths and get_tag_config to verify history is enabled. Aggregation modes: - LastValue: raw stored values (default) - Average: average value over each interval - Minimum / Maximum / Range: statistical aggregations - Count: number of values stored per interval Requires the WebDev tagHistory endpoint. See docs/webdev-setup.md.
Get the full configuration of a specific tag provider. Returns the provider type (STANDARD, REMOTE, DERIVED), settings, and metadata. Use list_tag_providers first to see available names.
Import an Ignition project from a base64-encoded ZIP archive. The ZIP should be in Ignition's standard project export format (as returned by export_project). WARNING: if overwrite=true, any existing project with the same name will be replaced.
List active Ignition Designer sessions. Shows who is connected to the Designer, which project they have open, and since when. Useful to check if anyone is actively editing before making programmatic changes to a project.
List all resources in an Ignition project. Returns paths for all project resources: Perspective views, scripts, named queries, report templates, transaction groups, and more. Resource paths follow the pattern: {module-id}/{resource-type}/{name}/{filename} Common module IDs: - com.inductiveautomation.perspective — Perspective views and styles - com.inductiveautomation.ignition — Scripts, named queries, tags, etc. - com.inductiveautomation.vision — Vision windows and templates Use get_project_resource to fetch the content of a specific resource.
List all Ignition projects with their metadata. Returns project names, titles, descriptions, enabled state, parent project, and other configuration. No parameters needed.
List all configured tag providers on the gateway. Tag providers are containers for tags. Most installations have a 'default' provider of type STANDARD. This returns provider names, types, and config. These are *configuration* resources — for runtime tag values, use read_tags.
Rename an Ignition project. This changes the project's identifier. Any references to the old name (e.g. in gateway scripts) will need to be updated manually.
Execute a Python script on the Ignition gateway and return the result. WARNING: This tool executes arbitrary code on the Ignition gateway. It is DISABLED by default. Set IGNITION_MCP_ENABLE_SCRIPT_EXECUTION=true to enable. The script runs in the gateway scripting scope with access to all system.* functions available on the gateway (system.tag, system.db, etc.). It does NOT have access to client-only functions like system.gui.*. Execution is logged on the gateway with a script hash for audit purposes. Guardrails: - Feature flag: must set IGNITION_MCP_ENABLE_SCRIPT_EXECUTION=true - Timeout: enforced both here and on the gateway WebDev side - Dry-run: set dry_run=True to preview without executing - Audit: every execution is logged on the gateway Example script: tags = system.tag.readBlocking(['[default]MyTag']) result = tags[0].value The gateway WebDev script must be deployed — see docs/webdev-setup.md.
Create or overwrite a project resource (view, script, named query, etc.). Writes the provided content to the specified resource path. If the resource doesn't exist it is created; if it does, it is overwritten. WARNING: This directly overwrites the resource on the gateway. There is no undo — consider reading the existing resource with get_project_resource first if you want to preserve or merge content. Common use cases: - Modify a Perspective view's JSON to update component properties - Update a script module with new Python code - Create a new named query No WebDev required — uses native REST API.
run_gateway_script is gated by environment variable but tool description could be clearer about the security implications. Script execution on a production gateway is irreversible, consider requiring explicit user approval or providing a safer sandbox variant.
Error handling descriptions are minimal. Tools lack recovery guidance (e.g., 'If project not found, call list_projects() to see available projects'). This forces agents to guess the next step on failure.
set_project_resource description notes 'content' parameter accepts object, but doesn't clarify whether string is valid for Python scripts or only JSON for views. Parameter type is 'object' but real usage accepts mixed types, ambiguous for LLMs.
Pagination not visible in tool definitions. Tools like list_project_resources could return hundreds of items. No limit, offset, or cursor parameters documented suggests unbounded result sets risk context window exhaustion.
WebDev endpoint dependencies noted in descriptions but configuration details scattered. Tools like get_active_alarms, get_alarm_history, get_tag_history, run_gateway_script all require WebDev setup, but setup instructions are opaque ('See docs/webdev-setup.md'). LLMs cannot verify prerequisites.