Enable AI-powered industrial automation through Model Context Protocol integration.
- Name: MCPServer
- Version: 1.0.0.0
- Interface: TCP/IP
- Configuration:
- Scripts / Classes
Overview
The AI Runtime service bridges FrameworX solutions with AI language models, enabling intelligent automation assistance while maintaining industrial-grade safety. This connector exposes your solution's live data and functionality as structured tools that AI models can invoke.
Note: This connector is for querying live data from running solutions (connects to TServer.exe). For AI-assisted solution configuration, see AI Designer Connector.
Key Capabilities
- Real-time Data Access — Query live tag values, historian data, and alarm states through AI
- Unified Namespace Browsing — Explore your tag structure and discover available data
- Historical Analysis — Query historian for trend analysis and past behavior investigation
- Alarm Monitoring — Check active alarms and query alarm history
- Custom Methods — Extend with your own solution-specific AI tools
- Platform Agnostic — Works with Claude, GitHub Copilot, and other MCP-compatible AI models
Integration Architecture
| AI Model | ↔ | MCP Protocol | ↔ | FrameworX Solution | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Claude, GPT, GitHub Copilot | Model Context Protocol | TServer.exe (Runtime) | ||||||||||
| ↓ | ||||||||||||
| Structured Methods | ||||||||||||
| ||||||||||||
This diagram shows an AI model (such as Claude or GPT) communicating with a FrameworX solution through the MCP Protocol, which acts as a standardized bridge for exchanging context and invoking tools. FrameworX then exposes structured methods that the model can call to access tag data, query historical records, monitor alarms, and run custom operations.
When to Use AI Runtime
| Use Case | Example |
|---|---|
| Process monitoring | "What is the current temperature in Tank1?" |
| Alarm investigation | "Are there any active alarms? What's causing them?" |
| Historical analysis | "Show me the temperature trend for the last 24 hours" |
| Data discovery | "What tags are available under Plant1/Line2?" |
| Operational questions | "What is the system uptime?" |
Why Custom Tools Matter
Some platforms may offer only built-in MCP tools that let AI read or write tags, or run queries, or perform specific tasks in the platform. In practice, this approach has limited value:
- Real solutions have hundreds of equipment items and thousands of tags
- Operators don't memorize tag names and their needs goes beyond plain data, it requires context, aggregation, and analysis
- Open access to running systems creates safety concerns and privacy issues
- LLM hallucination risk makes direct control inappropriate
FrameworX approach: Custom Runtime Tools
Because FrameworX compiles .NET code at runtime, you can create domain-specific tools that expose exactly what you want, with descriptions that guide AI to correct usage. External applications query at the semantic level: "get tank levels" instead of "read Tag.Area1.Tank3.LT001.PV".
This gated access model means:
| Generic Tools | Custom Tools |
|---|---|
| AI needs to know exact tag paths | AI uses semantic descriptions |
| Full system access (security risk) | You control what's exposed |
| Requires tag naming knowledge | Natural language queries |
| Hallucination can cause errors | Validation in your code |
Prerequisites
- FrameworX 10.1 or later
- Cross-platform .NET Desktop Runtime matching your FrameworX version: .NET 8 for 10.1.4 and earlier, .NET 10 for 10.1.5 and later
- Claude Desktop or compatible MCP client (In this documentation it might mention "AI Client", but all the tests were done using Claude from Anthropic)
- Running FrameworX solution (TServer.exe)
- Network connectivity
Configuration
The MCP Server starts automatically when your solution runs. To connect an AI client you install the FrameworX extension that matches how the client reaches the runtime. No manual editing of the AI client configuration file is required.
The FrameworX installer creates the setup folder on the machine where FrameworX is installed:
C:\Users\<user>\Documents\FrameworX\AISetupThis folder holds one ready-to-install extension bundle per connection method.
| Method | Use Case | Extension to install |
|---|---|---|
| Local | AI client on the same machine as the solution | frameworx-runtime-mcp.mcpb |
| Remote (HTTP) | AI client on a different machine | frameworx-runtime-mcp-http.mcpb |
Local Access: Same Machine
Use this method when the AI client runs on the same machine as your FrameworX solution.
Step 1 — Install the extension
- Open Claude Desktop
- Go to File → Settings → Extensions
- Click Advanced Settings
- Click Install Extension
- Select
frameworx-runtime-mcp.mcpbfrom theAISetupfolder - Click Install, then Install again on the confirmation popup
Anthropic updates the Claude Desktop settings interface regularly. If these menu entries are not where described, check Claude's official documentation for the current location.
Step 2 — Adjust the installation folder or port (only if not default)
The extension points at the default FrameworX installation folder, C:\Program Files\Tatsoft\FrameworX, and at the default runtime port 3101. If either differs on your machine, change them here:
- Go to File → Settings → Extensions
- Find FrameworX AI Runtime in the list and click Configure
- Set the FrameworX installation folder to your install path
- Set the port to the TServer port your solution is running on
The port configured in the extension must match the port your FrameworX runtime is actually listening on. FrameworX uses 3101 by default. If you change the port your solution runs on, change it in the extension's Configure panel as well, then restart Claude Desktop.
Step 3 — Restart Claude Desktop
Fully quit and reopen Claude Desktop so the extension is loaded. See Applying Changes below.
Remote Access: HTTP
Use this method when the AI client runs on a different machine from the FrameworX solution. The steps are the same as the local method, with one addition: an HTTP bridge must be running on the FrameworX machine.
Step 1 — Install the extension
On the AI client machine, follow the same procedure as the local method, selecting frameworx-runtime-mcp-http.mcpb instead.
Prerequisite: Node.js (LTS) must be installed on the AI client machine. The HTTP bundle runs the mcp-remote bridge, which is an npm package. The local (stdio) bundle does not need it.
- Open Claude Desktop
- Go to File → Settings → Extensions
- Click Advanced Settings
- Click Install Extension
- Select
frameworx-runtime-mcp-http.mcpbfrom theAISetupfolder - Click Install, then Install again on the confirmation popup
Step 2 — Start the HTTP bridge on the FrameworX machine
On the machine where FrameworX is installed, run RuntimeMCPHttp.exe from the installation folder:
C:\Program Files\Tatsoft\FrameworX\fx-10\net10.0\RuntimeMCPHttp.exeAdjust the runtime folder to match your FrameworX version (net8.0 for 10.1.4 and earlier, net10.0 for 10.1.5 and later). If you installed FrameworX somewhere other than the default location, use that path instead.
Leave the console window open. The bridge starts looking for a FrameworX runtime immediately. As soon as a solution is running, it connects automatically and the AI client has a live remote connection to the runtime. Order does not matter: you can start the bridge before or after the solution.
Step 3 — Adjust the installation folder or port (only if not default)
Go to File → Settings → Extensions, find FrameworX AI Runtime (HTTP) and click Configure. This variant takes two values: RuntimeMCPHttp Host, the address of the machine running the bridge (default 127.0.0.1), and RuntimeMCPHttp Port, the bridge port (default 10120). Note that this is the bridge port, not the TServer port: the TServer host, port, and credentials are configured in RuntimeMCPHttp.json on the runtime machine.
Step 4 — Restart Claude Desktop
Fully quit and reopen Claude Desktop so the extension is loaded.
Advanced: HTTP Bridge Settings
The defaults work for a trusted local network. To change the listen port, set an API key, or enable TLS, edit this file on the FrameworX machine before starting the bridge:
C:\Users\Public\Documents\FrameworX\MachineSettings\RuntimeMCPHttp.json| Setting | Description |
|---|---|
X_API_KEY | Optional authentication password |
CertFileName | SSL certificate file (for HTTPS) |
CertPass | SSL certificate password |
CertHash | SSL certificate thumbprint (alternative to file) |
ListenPort | HTTP endpoint port (default: 10120) |
Runtime.Host | FrameworX runtime host (default: localhost) |
Runtime.Port | FrameworX runtime port (default: 3101) |
Runtime.Username | Runtime authentication user |
Runtime.Password | Runtime authentication password |
Security note: set a strong X_API_KEY if the bridge is reachable over a network. Leave CertFileName empty to use plain HTTP.
Multiple Connections: to serve multiple runtimes from one machine, start the bridge with the /instance:<number> argument and add matching numbered settings (for example X_API_KEY2, ListenPort2, Runtime2).
Applying Changes
Claude Desktop loads extensions once, when the process starts. After installing an extension, reinstalling an updated one, or changing values in the Configure panel, you must fully restart the client. Opening a new chat is not enough. The restart of the AI Client is necessary after running the solution as well.
- Windows: Close the process in the Task Manager. Only closing the AI Client window is not enough.
Verifying Connection
- In the chat, click in the '+' button > Connectors > See if "FrameworX AI Runtime" is listed there.
- Ask the AI a simple question like "What is the server uptime?"
Available Tools
AI Runtime provides 14 built-in platform tools plus solution-authored custom tools, organized by category. The tool count your AI client reports is the sum of both: a client connected to a solution that defines two custom tools lists 16. Each category is gated independently in Solution Settings → Data Servers → MCP for Runtime; the Info tools (runtime_connect, runtime_describe_binding) are gated only by the master toggle so AI clients can bootstrap and verify the target before any sub-category is enabled.
Info (2 tools)
Tool | Purpose |
|---|---|
runtime_connect | Connect to a FrameworX runtime and receive the Context Package (solution identity, profile, namespaces, quality codes, tool workflows, objType schemas, custom tools). Call this first at the start of every session. No-args returns the current Context Package for the runtime this MCP is bound to. On HTTP retargetable instances, accepts optional |
runtime_describe_binding | Pre-auth introspection — calls the anonymous |
UNS Tools (5 tools, gate: Enable UNS Tools)
Tools for querying live data and structure from the runtime Object Model — the 12-root hierarchy that includes the Unified Namespace (Tag.*) plus the built-in namespaces (Server, Client, Alarm, Device, Historian, Dataset, Script, Display, Security, Report, Info).
Tool | Purpose |
|---|---|
runtime_get_value | Get the current LIVE value of a tag or runtime object, including quality (0=Bad, 64=Uncertain, 192=Good), timestamp, and metadata (description, units, min/max). For historical values, use |
runtime_browse_object_model | Browse the live runtime object-model tree — returns child nodes at the specified path. Works across all roots: |
runtime_search_uns | Ranked semantic search across the live UNS — UserTypes, Tags, members, Enumerations, and AssetTree folders. Scores across Name, DisplayText, Labels, SourceIri, and Attributes annotation content. Returns ranked matches with |
runtime_describe_object | Describe a single UNS object — inheritance chain, derived UDTs, and (for Tag paths) live current value, quality, timestamp, and alarm state. Pass either |
runtime_list_instances | List all live tags of a given UDT (UserType), with current value, quality, and timestamp for each. Optional |
Alarm Tools (2 tools, gate: Enable Alarm Tools)
Dedicated alarm-query tools that hit the alarm subsystem's state machine and historian. Reading an Alarm.* namespace value through runtime_get_value, or reading a tag's current alarm-state through runtime_describe_object, stays under UNS Tools — those are UNS data reads, not dedicated alarm queries.
Tool | Purpose |
|---|---|
runtime_get_active_alarms | Get currently ACTIVE alarms — alarms in alarm state right now, not yet normalized. Returns tag name, message, priority, active time, area, and group. For past normalized alarms, use |
runtime_query_alarm_history | Query historical alarm records from the Alarm Historian database. Only SELECT statements are allowed; INSERT, UPDATE, DELETE, and other modifying statements are blocked. Available columns: TagName, Message, ActiveTime, AckTime, NormTime, UserName, Priority, Area, GroupName. |
Historian Tools (2 tools, gate: Enable Historian Tools)
Tools for querying historical time-series data.
Tool | Purpose |
|---|---|
runtime_get_tag_history | Query historical time-series data for a tag from the Historian database. The tag must be configured for Historian storage. Returns raw stored samples (truncated at 2000 points). For the current live value, use |
runtime_get_aggregated_history | Bucketed aggregation over historical time-series data — the kernel reduces each time bucket into a single value rather than returning raw samples. Specify an ISO-8601 time range and |
Client Session Tools (3 tools, Development only)
Tools for inspecting and driving connected client sessions during local development and automated testing. They are not general operations tools and are not exposed through the MCP for Runtime gate panel. Each one answers only when all of the following hold: the runtime's QaTestMode gate is active, the caller reaches the runtime over true loopback (127.0.0.1 / ::1), the target client is itself on true loopback, and this MCP host is on a transport a remote caller cannot reach (STDIO always; HTTP only when launched with ListenLoopbackOnly=true). When a gate refuses, the tool returns an errorCode and a message instead of data.
Tool | Purpose |
|---|---|
runtime_list_client_sessions | List the client sessions currently connected to the running TServer — one row per connected client (Rich Client, Smart Client, HTML5, Designer, Data Access, protocol drivers). Read-only flat projection: session GUID, client type, additional name, whether it is a view client, whether it is connected over loopback, logged-in user, UTC connect time, and client version. Call it first — the other two tools address a session by the GUID it returns. |
runtime_client_screenshot | Capture a screenshot of ONE connected WPF Rich Client session's window, addressed by its session GUID. Pass an empty display name to capture the whole open layout, or a display name to capture that single display. Returns a local file path on the runtime host. WPF Rich Client only — the HTML5 WebClient cannot be captured and returns |
runtime_client_input | Inject an operator-input value into ONE connected client session, addressed by its session GUID. The value is delivered into that client's own commit pipeline — range-clamped, security-checked, and e-signature-gated exactly as if a human typed it into the named input control and tabbed away. It does not write the tag directly, and it refuses while e-signature is enabled. A successful call means the injection was enqueued, not committed: the client can still reject it. Verify the commit by reading the tag back with |
A screenshot can expose any on-screen content, and an input injection drives a live client. Both are restricted to localhost Development for that reason. Neither is reachable from a remote AI client over the HTTP bridge unless that bridge was deliberately launched loopback-only.
Custom Tools (gate: Enable Custom Tools)
Solution-authored [McpServerTool] methods on Scripts ? Classes of type MCP Tool. See the Custom Methods section below for authoring guidance.
Reading Live Values (runtime_get_value):
- "What is the current value of Tag.Temperature1?"
- "Get the value of Tag.Plant1/Line2/Pressure"
- "What is the Server.SystemMonitor.CPUUsage?"
- "How many active alarms are there?" (uses Alarm.TotalCount)
Browsing the Object Model (runtime_browse_object_model):
- "What tags are available under Tag.Plant1?"
- "Show me the members of Tag.Pump1" (for UserType tags)
- "What alarm groups exist?"
- "Browse the Server namespace"
Searching the UNS (runtime_search_uns):
- "Find all tags containing 'Temperature'"
- "Search for UserTypes related to 'motor'"
- "Find anything with 'pump' in the description or labels"
Historical Analysis (runtime_get_tag_history):
- "Show me the temperature history for today"
- "Get the historian data for Tag.Pressure from 8am to noon"
- "What was the highest temperature value today and when did it occur?"
Active Alarms (runtime_get_active_alarms):
- "Are there any active alarms?"
- "What alarms are currently in alarm state?"
- "Show me all unacknowledged alarms"
Alarm History (runtime_query_alarm_history):
- "Show me alarms from the last 24 hours"
- "How many alarms were acknowledged today?"
- "Query the alarm history for Tag.Temperature1"
- "What alarms occurred during the night shift?"
Custom Methods
You can extend the MCP server with your own solution-specific tools by creating custom methods in Scripts.
Tool names in runtime: When naming your runtime tools, it's strongly recommended that you keep the pattern
runtime_<toolName>. When AI is also running AI Designer, or other third-party tools, that helps to correctly identify the right tool to use. For adherence with MCP standards use snake_case for method names (e.g.,runtime_get_tank_level), instead of RuntimeGetTankLevel that would be a typical C# convention.
Creating Custom Methods
- Navigate to Scripts → Classes
- Create a new class with type MCP Tool
- Define methods using MCP decorators:
[McpServerTool, Description("Get current tank level for a specific tank")]
public string runtime_get_tank_level(
[Description("Tank identifier (1-4)")] string tank_id = "1")
{
return @Tag[$"Tank{tank_id}_Level"].ToString();
}
Method Structure:
| Element | Purpose |
|---|---|
[McpServerTool] | Marks method as MCP tool |
[Description("...")] | Explains what the tool does (shown to AI) |
| Method name | Tool name (use snake_case) |
| Parameter descriptions | Explains expected input to AI |
| Return value | Result sent to AI |
Custom Method Examples
Simple Value Retrieval:
[McpServerTool, Description("Get production count for today")]
public string runtime_get_production_count()
{
return @Tag.Production.TodayCount.ToString();
}
With Error Handling:
[McpServerTool, Description("Get data for a specific tag with validation")]
public string runtime_get_tag_data(
[Description("Full tag path")] string tag_name)
{
try
{
if ([email protected](tag_name))
return $"Error: Tag '{tag_name}' not found";
return @Tag[tag_name].ToString();
}
catch (Exception ex)
{
@Info.Trace($"MCP Error: {ex.Message}");
return "Error: Unable to retrieve data";
}
}
Aggregated Data:
[McpServerTool, Description("Get summary of all tank levels")]
public string runtime_get_all_tank_levels()
{
var result = new StringBuilder();
for (int i = 1; i <= 4; i++)
{
var level = @Tag[$"Tank{i}_Level"].Value;
result.AppendLine($"Tank {i}: {level}%");
}
return result.ToString();
}
Important: After creating or modifying custom methods, fully restart the AI client (close from Task Manager, not just the window).
Deprecated / Removed Tools
Customers upgrading from 10.1.4 should update any AI prompts, solution-authored wrappers, or integration scripts that reference the old tool names. Bit positions in ModelOptions are unchanged — existing solutions decode identically; only the tool surface and category labels changed.
| Old name (10.1.4 and earlier) | 10.1.5 replacement | Notes |
|---|---|---|
runtime_get_info | runtime_connect | Same payload on no-args. HTTP retargetable instances accept optional solution / profile to rebind to a different running TServer. |
runtime_set_target | runtime_connect(solution, profile) | Merged as the with-args branch of runtime_connect. |
runtime_browse_uns | runtime_browse_object_model | Same parameters plus a bounding max_results. Renamed because the tool walks all 12 runtime roots, not just the strict UNS (Tag.*). |
runtime_get_object_context | runtime_describe_object | Same single-object intent; absorbs external-IRI lookup via a new iri parameter. |
runtime_find_by_iri | runtime_describe_object(iri=...) | Merged into runtime_describe_object — different lookup key, same single-object response. |
runtime_list_by_type | runtime_list_instances | Renamed. Adds max_results and name_mask wildcard filter. |
runtime_list_derived_types | — (removed) | Redundant: runtime_describe_object already returns derivedTypes in its context block. |
runtime_search_tags | runtime_search_uns | Broader scope — searches UserTypes, members, Enumerations, and AssetTree folders in addition to Tags. |
Best Practices
For AI Queries
- Be specific about tag paths when asking for values
- Use "active alarms" for current state, "alarm history" for past events
- Specify time ranges clearly for historical queries
- Ask the AI to browse the namespace if you're unsure of tag names
For Custom Methods
- Use descriptive names and descriptions — the AI relies on these
- Include parameter validation and error handling
- Return clear error messages that help the AI understand what went wrong
- Follow snake_case naming convention for consistency
- Keep methods focused on single tasks
Security Considerations
- Use
X_API_KEYauthentication for HTTP connections - Configure appropriate runtime user permissions
- Be cautious with write operations — consider read-only access for AI
- Review custom methods for security implications
Troubleshooting
AI Runtime server not starting
- Verify the cross-platform .NET Desktop Runtime matching your FrameworX version is installed (.NET 8 for 10.1.4 and earlier, .NET 10 for 10.1.5 and later)
- Check firewall settings for the configured port
- Confirm the FrameworX installation folder is correct in the extension's Configure panel
AI cannot access methods
- Ensure solution is running (the TServer.exe application is running)
- Verify AI client configuration matches server settings
- Restart AI client completely (close via Task Manager)
- Check that MCP decorators are properly applied to custom methods
Data not updating
- Confirm tags are properly configured in the solution
- Verify real-time database connectivity
- Check custom method error handling for exceptions
Custom methods not appearing
- Verify class type is set to "MCP Tool"
- Check for syntax errors in method code
- Restart AI client completely after changes
HTTP connection failing
- Confirm
RuntimeMCPHttp.exeis running on the FrameworX machine - Verify ListenPort is not blocked by firewall
- Check X_API_KEY matches between server and client
- For HTTPS, verify certificate is properly configured
- Test with
http://localhost:10120first before remote access
Related Documentation
Quick Start Tutorial
- AI Runtime Tutorial — Creating and deploying MCP Tools
Example Implementation
- SolarPanels MCP Demo — Full solution demonstrating MCP Tools with solar panel monitoring
Technology Information
- AI-Ready by Design — Platform architecture for AI integration
Reference Information
- Scripts Module Reference — Complete scripting documentation
AI Designer
For AI-assisted solution configuration (creating tags, displays, alarms):
- AI Designer Connector — Enable AI to configure solutions
- AI Designer In Action — See AI Designer capabilities in action
Change Log
| Version | Date | Changes |
|---|---|---|
| 1.5 | 2026-07 | 14 platform tools (was 11). Adds Client Session tools — runtime_list_client_sessions, runtime_client_screenshot, runtime_client_input — for local development and automated testing, gated by QaTestMode, true loopback, and a local-only MCP transport. |
| 1.4 | 2026-07 | Extension-based configuration. Local and remote connections are now installed from the ready-made .mcpb bundles in Documents\FrameworX\AISetup. Manual editing of the AI client configuration file is no longer required; the HTTP bundle carries the mcp-remote bridge configuration, which still needs Node.js on the AI client machine. |
| 1.3 | 2026-06 | 11 platform tools (was 9) |
| 1.2 | 2026-05 | 9 platform tools (was 7) plus solution-authored custom tools. Session bootstrap unified as runtime_connect (merges runtime_get_info + runtime_set_target). Tool renames for scope-accurate categories: runtime_browse_uns → runtime_browse_object_model (walks all 12 runtime roots); runtime_search_tags → runtime_search_uns (searches UserTypes, members, enums, folders); runtime_get_object_context → runtime_describe_object (absorbs runtime_find_by_iri via iri parameter); runtime_list_by_type → runtime_list_instances with wildcard name_mask. runtime_list_derived_types removed (folded into runtime_describe_object.derivedTypes). Gate-bit categories relabeled to Enable *Tools. |
| 1.1 | 2026-02 | 7 built-in tools; Updated architecture diagram; Added runtime_ prefix best practices. |
In this section...