MCP Module Early Access

[paul-griffith]

MCP Module Early Access

We are excited to announce the Early Access (EA) release of the new MCP Module for Ignition. This initial, limited-scope release is designed to demonstrate IA's commitment to the emerging AI landscape, providing a streamlined way to use Ignition to connect OT data with external Large Language Model (LLM) clients and tools.
This module requires a nightly build of the Ignition platform to run until the full release of Ignition 8.3.5.

What is the Early Access MCP Module?

The Model Context Protocol (MCP) Module is a new addition to the Ignition ecosystem, developed to bridge Ignition’s data with generative AI tools. This EA build provides the base infrastructure for connectivity and is focused on establishing a secure server implementation.

Limited Scope: What to Expect

This initial early access release is solely intended for early adopters who are willing to experiment and provide feedback.

Key Non-Goals for this EA Release:

• This is not intended to provide complete, out-of-the-box solutions for using MCP.
• The module will not include an Ignition-native MCP client.
• The module itself does not provide any “primitives” (tools/resources/prompts).

The EA release will be provided free**, as-is** here on the forum for users to experiment with. While we have no plans to do so, we reserve the right to break any user defined primitives created in this early access during this EA period. This is an official IA module, but is not being offered with our usual backwards compatibility and stability guarantees. Crucially,

Support is not available for this early access release.

Future Plans

We recognize that the novelty of the Model Context Protocol means there are no true experts in the industry, and this EA phase is designed with a "learn-as-we-go" approach. We plan to iteratively develop and roll out new features based on real-world usage data and user feedback.

The full “1.0” release of the module will be a standard Ignition module available for use with 8.3 some time after this early access period concludes, and will be available as part of an existing solution suite.

Technical Details

The EA module implements the Model Context Protocol (MCP) version 2025-06-18 using the streamable HTTP transport layer and is compatible with Standard, Cloud, and Maker editions.

Each MCP “server” instance must be configured manually on disk by creating an appropriate config.json and resource.json file; more on that below. The 1.0 release will have a standard web based configuration experience.

The MCP module introduces three new resource types in the Designer for different "primitives":

• Tools - Allows users to define a script to run when invoked by an MCP client.
• Resources - Provides static data to share with MCP clients.
• Prompts - Creates a function to invoke whenever an MCP client requests the given prompt, allowing you to generate a custom prompt for the client to use or customize further.

We look forward to gathering feedback and working with the community during this Early Access period.

To download the module, please complete our survey.

[paul-griffith]

Getting Started

1. Open the Designer.
2. Create a new ‘Tool’ resource in the Model Context Protocol workspace.
   1. Give the tool a description to help your LLM choose to invoke it.
3. Save the project and note your project’s name.
4. Go to the Ignition installation directory and locate the /data/config/resources/core/ directory.
5. Create a new folder named com.inductiveautomation.mcp/. Navigate into it.
6. Create a new folder named server-config/. Navigate into it.
7. Create a new folder named testing/. Navigate into it. Remember this resource name, we’ll reference it later.
8. Create a new resource.json file. Enter the below contents:

{
    "scope": "A",
    "version": 1,
    "restricted": false,
    "overridable": true,
    "files": [
        "config.json"
    ],
    "attributes": {
        "uuid": "4895f9b3-eeb1-436f-b327-e54ab873db86"
    }
}

8. Create a new config.json file. Enter the below contents; replace $test with the name of the project where you defined your test tool earlier.
   1. Note! The wildcard after the project/test entry means that all defined tools in this project will be exposed on this particular MCP server. This is useful for testing, but could lead to context pollution. Instead of a literal string ”*”, you can pass an array of paths to limit to a discrete set of tools/resources/prompts.

{
  "title": "Testing",
  "version": "1.0.0",
  "permissions": {
    "type": "AllOf",
    "securityLevels": [
      {
        "children": [],
        "name": "Authenticated"
      }
    ]
  },
  "tools": {
    "project/$test": "*"
  },
  "resources": {},
  "prompts": {}
}

9. Scan the config filesystem, on the Platform Overview page.
10. Create an API Key and copy it to a text file.
11. In your LLM client of choice, figure out how to define an MCP server; often this is with an mcp.json file. The exact specification varies between clients, but generally you will end up with something like this. Note that the trailing portion of the url, testing, must match the resource name created as a folder earlier.

{
    "servers": {
        "ignition": {
            "url": "http://localhost:8088/data/mcp/testing",
            "type": "http",
            "headers": {
                "X-Ignition-API-Token": "your-token-here"
            }
        },
    }
}

12. In your LLM client, confirm you are connected to the MCP server and ask it to invoke your test tool.

---

Easy Mode

Alternately, for an easier setup you can run this curl snippet, populating with your API key and project name(s) as needed:

curl -X POST http://localhost:8088/data/api/v1/resources/com.inductiveautomation.mcp/server-config \
     -H "Content-Type: application/json" \
     -H "X-Ignition-API-Token: your-token-here" \
     -d '[
  {
    "name": "testing",
    "collection": "core",
    "enabled": true,
    "description": "Test MCP Server Implementation",
    "config": {
      "title": "Testing",
      "version": "1.0.0",
      "permissions": {
        "type": "AllOf",
        "securityLevels": [
          {
            "children": [],
            "name": "Authenticated"
          }
        ]
      },
      "tools": {
        "project/test": "*"
      },
      "resources": {
        "project/test": "*"
      },
      "prompts": {
        "project/test": "*"
      }
    }
  }
]'

---

Alternate Scripted Setup

Summary

def createMcpServer(
	api_token, 
	server_name = "testing",
	project = system.project.getProjectName(),
	server_url = system.vision.getGatewayAddress(),
):
	if api_token is None:
		print "api token is missing"
		return

	url = "{}/data/api/v1/resources/com.inductiveautomation.mcp/server-config".format(server_url)
    
	data = [
    	{
    		"name": server_name,
    		"collection": "core",
    		"enabled": True,
    		"description": "{} MCP Server Implementation".format(server_name),
    		"config": {
    			"title": server_name,
    			"version": "1.0.0",
    			"permissions": {
    				"type": "AllOf",
    				"securityLevels": [
    					{
    						"children": [],
    						"name": "Authenticated"
						}
					]
				},
				"tools": {
					"project/{}".format(project): "*"
				},
				"resources": {
					"project/{}".format(project): "*"
				},
				"prompts": {
					"project/{}".format(project): "*"
				}
			}
		}
	]

	headers = {"X-Ignition-API-Token": api_token}
	
	return system.net.httpClient.post(url, data=data, headers=headers)

Usage:

createMcpServer("test:apiTokenHere")

[Shay_Johnson]

Hey everyone,

The response to the MCP Early Access has been awesome so far. I wanted to share a quick snapshot of what we’re seeing in the data to give you an idea of how the community is putting this thing to work based on initial download surveys.

The TL;DR:

• Who’s playing with it? About 75% of you are Controls or Automation Engineers, and over 70% consider yourselves "Intermediate" to "Advanced" with AI tools.

• What are you doing? The top use case (~80%) is using agents to help with project development (writing scripts and building Perspective views). Data analysis and real-time troubleshooting aren't far behind.

  • I am curious to understand if folks are still feeling excited about configuration and development using the MCP or if Analysis or Troubleshooting take the lead.

• The Tech Stack: Claude Desktop is the clear favorite for the client side, used by about 75% of people.

We need your help (again!)

Now that the module has been out in the wild for a bit, we want to know if it’s actually sticking in your workflow or if it was just a "cool weekend project."

Have you found any unique or unexpected use cases? Did you hit a wall we didn't foresee? Are you able to share anything you’ve created?

If you have a second, please check out our follow-up survey here: Survey Link

Thanks!

[guanghui]

According to the configuration method you provided, I have made some simple attempts in Ignition, and implemented the most basic LLM calls and MCP interactions. Some customers are also quite interested in AI integration.

Below is a question from one user:

*“Our factory collects a large amount of data, stores all the data in a SQL Server database through Ignition, and builds an application. However, the pain point is that many engineers do not know which screen to find the data on, let alone how to use SQL Server query commands to find the data they need.

I am wondering if it is possible to create a digital assistant through an AI Agent, or use a specific API, so that in the Ignition interface, employees only need to type their questions into a text box, and the AI Agent can automatically query the corresponding database and return the results.”*

As for us integrators, we are more concerned about how to use AI to assist with project development. It would be greatly appreciated if you could provide some usage examples of these methods.

[richard.blanchette]

I installed the module and saw there were no tools/resources/or prompts. Not surprised but unsatisfying out the gate. Searching online I couldn’t find any. Thought I would share my first pass at making my own. Usual disclaimer though this isn’t something I recommend for production use at this time and need way more testing before I turn this loose on anything I care about. However, I was able to build a simulator of my asset with just these tools.

Would definitely welcome feedback. I found the development cycle a bit clunky all things considered. I’d like to be able to work on scripts from within my vscode env not the ignition designer. If someone knows of a way to do that please let me know. My debugging process had me juggling between designer, vscode, and claudes mcp developer logs. I’m clearly doing things the hardway

ignition-examples/standard/mcp_tools/tools at feat/mcp ·...

[Gratliff]

Hey all, I've been working with the MCP module and I'm stuck. My server initializes fine but returns empty capabilities, so tools/list fails with -32600.

Setup:

• Ignition 8.3.5 nightly (b2026021307), MCP module v1.3.5-SNAPSHOT
• 4 tools created in Designer under a global resources project (browse_tags, read_tags, etc.)
• I created the server config created manually at data/config/resources/core/com.inductiveautomation.mcp/server-config/my-dev/
• On the platform overview page, I see it there though it shows last updated = ‘N/A’, enabled = True and status = ‘N/A’
• API key works fine, initialize returns 200

config.json:
{
"title": "My Dev Server",
"version": "1.0.0",
"permissions": {
"type": "AllOf",
"securityLevels": [{"children": , "name": "Authenticated"}]
},
"tools": {"project/My_Global": "*"},
"resources": {},
"prompts": {}
}

What happens:
Initialize response comes back with "capabilities": {} — no tools capability advertised. Calling tools/list after that returns {"error":{"code":-32600}}.
everything matches structurally.

Am I missing something obvious? Is there a step between creating tools in the designer and having the server config pick them up that I'm not seeing?

[paul-griffith]

global resources project

Is this project inheritable? It needs to be standalone/not inheritable.

Are you able to DM me a gateway backup?

[Gratliff]

Sorry, I had some other work pull me away for a couple of days. Yes, it was in an inherited project. We moved it to a child project and it started working right away. Thanks for the tip!

[nat87.delpuppo]

Hi paul-griffith,

Thanks for showing up how to do the setup!

Quick question: is there any documentation available for the MCP Module? I'd love to dig deeper into the configuration options, best practices for setting up tools/resources/prompts, and any other features I might be missing. The module looks promising and I want to make sure I'm using it correctly.

Thanks again!

[levente.bagoly]

I'm experiencing the exact same issue on a newer platform build.

Setup:

• Ignition 8.3.5-SNAPSHOT (b2026033116), MCP module v1.3.5-SNAPSHOT (b2026021307)

• Fresh project test_mcp created as inheritable, with a simple hello world tool created in Designer

• Server config created manually at data/config/resources/core/com.inductiveautomation.mcp/server-config/testing/

• API key works, initialize returns 200

• Config filesystem scanned, container restarted multiple times

config.json:

{
  "title": "Testing",
  "version": "1.0.0",
  "permissions": {
    "type": "AllOf",
    "securityLevels": [{"children": [], "name": "Authenticated"}]
  },
  "tools": {"project/test_mcp": "*"},
  "resources": {},
  "prompts": {}
}

What happens: Initialize always comes back with "capabilities": {} — no tools capability advertised. tools/list returns {"error":{"code":-32600}}.

I've tried: creating a brand new project, deleting and recreating the server-config folder with a fresh UUID, bumping the resource.json version, and updating to the latest nightly (b2026033116). Nothing changes the empty capabilities response. The module starts cleanly with no errors in the logs.

Is there a step I’m missing to get the module to discover tools from the project?

[paul-griffith]

The project must not be inheritable. Sorry, my first post was ambiguous.

@nat87.delpuppo

Quick question: is there any documentation available for the MCP Module? I'd love to dig deeper into the configuration options, best practices for setting up tools/resources/prompts, and any other features I might be missing. The module looks promising and I want to make sure I'm using it correctly.

Not really at this time. Once a "full" version 1 release happens it'll get the standard treatment in our user manual, possibly a supplemental IU video, etc. Until then, this is a learn by doing endeavor.

[nat87.delpuppo]

Ok perfect, thank you for your feeback, gonna play with it!

[Porter_Ellis]

This may be a silly question, but are there any endpoints/importable packages/objects that could grant my agent access to the console output? I am trying to write tools that produce a readable and understandable console output, and it would be useful for the agent to be able to read this output for long running development.

Also, will there ever be support for creating/modifying Vision components, or will I be forced to migrate to Perspective?

[paul-griffith]

@Porter_Ellis

are there any endpoints/importable packages/objects that could grant my agent access to the console output?

I don't really understand what this means in the context of this module. Are you asking if you can create a tool that returns the logs output by the execution of another tool?

@Porter_Ellis

Also, will there ever be support for creating/modifying Vision components, or will I be forced to migrate to Perspective?

At the moment, there aren't any plans to introduce first party MCP tools in the MCP module to create project resources of any kind. However, I'll say that the nature of Perspective makes it a much easier target for agentic development (and we've had already got third parties doing that). If we do something first party, it's less likely that we exclude Vision inasmuch as we focus on Perspective. That's not because Perspective is "better", just because a lot of decisions within Perspective make it a better target for machine consumption and generation.
For instance, each component has a defined JSON schema. Current large language models can readily understand that as-is, and you can easily turn into a deterministic validator to ensure a base level of coherence with reality. Vision has no such easy on-ramp, and if you pass Vision even slightly invalid XML you get a totally broken window with poor visibility into what went wrong, where Perspective is better at capturing errors at component boundaries.

[Porter_Ellis]

@paul-griffith

I don't really understand what this means in the context of this module. Are you asking if you can create a tool that returns the logs output by the execution of another tool?

I Would like to create a tool that can retrieve the current output of the logs. A workflow example would be ‘Use toolX to perform taskX, then validate taskX was performed correctly in the logs by using checkConsole’.

@paul-griffith

even slightly invalid XML

Will developers ever be granted access to Vision component creation/editing lifecycle? I can think of a dozen ways creating, editing, and binding components programmatically would be useful. I have gotten some XML based component creation working in a hacky/unreliable way using the Deserializer, but I would like to do it the supported way. Seeing that Vision is no longer being improved, I would consider this information fair play.

[paul-griffith]

You can use a script to retrieve logs:

Scripting to read gateway logs

Ahh, that does the trick. Code for prosperity from com.inductiveautomation.ignition.gateway import IgnitionGateway from com.inductiveautomation.ignition.common.logging import LogQueryConfig loggingManager = IgnitionGateway.get().getLoggingManager() queryFilter = LogQueryConfig.newBuilder().build() logResults = loggingManager.queryLogEvents(queryFilter) events = logResults.getEvents() system.perspective.print(events) I did notice this documentation error for the LogQueryConfig it stat…

@Porter_Ellis

Will developers ever be granted access to Vision component creation/editing lifecycle?

Again, I'm not quite sure what you mean. Who is "developers" in this sentence, and what does "granted access" mean to you? This might be a good digression for a different topic (I'm happy to talk about it - I just think we're getting away from the spirit of the MCP module as it currently exists).