OPC UA Modeler

Official12 toolsLive

by node-opcua · TypeScript

OPC UA companion spec types, namespace dependencies, and engineering units for AI agents

The io.github.node-opcua/node-opcua-modeler-mcp-server is an MCP server for AI agents that provides OPC UA companion specification types, namespace dependencies, and engineering units. It focuses on model-related metadata needed to interpret or construct OPC UA information reliably.

🛠️ Key Features

OPC UA companion spec types
Namespace dependencies
Engineering units
Exposes 12 tools via MCP

🚀 Use Cases

Supplying AI agents with OPC UA model type information
Resolving or documenting namespace dependencies
Providing engineering-unit context for OPC UA data

⚡ Developer Benefits

Centralizes OPC UA modeler data (types, namespaces, units) for agent workflows
Tool-based access for integrating these elements into MCP clients

⚠️ Limitations

Scope is limited to companion spec types, namespace dependencies, and engineering units based on available documentation

📌 Metadata

Slug: io-github-node-opcua-node-opcua-modeler-mcp-server
License: Apache-2.0

Captured live from the server via tools/list.

resolve_dependencies

Given one or more companion spec namespace aliases, returns the full resolved dependency list that MUST go in the YAML `namespaces:` section. Always call this before generating the namespaces block.

Parameters1

aliases

array

required

Companion spec aliases to resolve (e.g. ["machineTool", "robotics"])

Raw schema

{
  "type": "object",
  "properties": {
    "aliases": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Companion spec aliases to resolve (e.g. [\"machineTool\", \"robotics\"])"
    }
  },
  "required": [
    "aliases"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

list_namespaces

List all well-known OPC UA companion spec namespace aliases with their full names, URIs, and dependencies. Use this to discover what namespaces are available.

Parameters

No parameters.

Raw schema

{
  "type": "object",
  "properties": {},
  "$schema": "http://json-schema.org/draft-07/schema#"
}

list_types

List ALL ObjectTypes, VariableTypes, and InterfaceTypes defined in a specific companion spec namespace. ALWAYS call this before using any type from a namespace — NEVER guess type names.

Parameters1

alias

string

required

Companion spec alias (e.g. "machinery", "di", "robotics")

Raw schema

{
  "type": "object",
  "properties": {
    "alias": {
      "type": "string",
      "description": "Companion spec alias (e.g. \"machinery\", \"di\", \"robotics\")"
    }
  },
  "required": [
    "alias"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

get_type_details

Get detailed information about a specific type: its components, properties, methods, interfaces, and optional members. Use this to understand a type's structure before creating instances or subtypes.

Parameters2

alias	string	required	Companion spec alias where the type is defined (e.g. "machinery")
browseName	string	required	The type browse name (e.g. "MachineryItemIdentificationType")

Raw schema

{
  "type": "object",
  "properties": {
    "alias": {
      "type": "string",
      "description": "Companion spec alias where the type is defined (e.g. \"machinery\")"
    },
    "browseName": {
      "type": "string",
      "description": "The type browse name (e.g. \"MachineryItemIdentificationType\")"
    }
  },
  "required": [
    "alias",
    "browseName"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

search_types

Search for types across ALL companion specs by keyword. Use this when you don't know which namespace defines a type. Returns matching types with their namespace alias.

Parameters1

query

string

required

Search keyword (e.g. "identification", "temperature", "motion")

Raw schema

{
  "type": "object",
  "properties": {
    "query": {
      "type": "string",
      "description": "Search keyword (e.g. \"identification\", \"temperature\", \"motion\")"
    }
  },
  "required": [
    "query"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

find_reusable_block

Find reusable Interfaces / AddIns by capability — pass a member name or keyword (e.g. "SerialNumber", "DeviceHealth", "Location") and get the standard blocks that already expose it. PREFER applying/composing an existing block over redefining its members inline. Interfaces are applied with `interfaces:`; addins (types with a DefaultInstanceBrowseName) are composed with `addIns:`. A single property → use the Interface; a whole named sub-object → use the AddIn.

Parameters1

query

string

required

Member name or capability keyword (e.g. "SerialNumber", "health", "calibration")

Raw schema

{
  "type": "object",
  "properties": {
    "query": {
      "type": "string",
      "description": "Member name or capability keyword (e.g. \"SerialNumber\", \"health\", \"calibration\")"
    }
  },
  "required": [
    "query"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

find_engineering_unit

Find the official UNECE Rec. 20 engineering unit symbol for a given description. ALWAYS call this before using any engineering unit — NEVER guess unit symbols.

Parameters1

query

string

required

Description or common name of the unit (e.g. "revolutions per minute", "celsius", "pressure bar")

Raw schema

{
  "type": "object",
  "properties": {
    "query": {
      "type": "string",
      "description": "Description or common name of the unit (e.g. \"revolutions per minute\", \"celsius\", \"pressure bar\")"
    }
  },
  "required": [
    "query"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

get_dsl_reference

Get the grammar reference for the OPC UA modeler YAML DSL: file header, top-level sections, name-prefix conventions, minimal examples, and common mistakes. Call this FIRST before writing any YAML model by hand. Works without an API key.

Parameters

No parameters.

Raw schema

{
  "type": "object",
  "properties": {},
  "$schema": "http://json-schema.org/draft-07/schema#"
}

opcua_model_validate

Validate an OPC UA YAML model for correctness. Returns diagnostics with severity (error/warning/info), codes, messages, and line numbers. Works without an API key (limited to 50 calls/day). ALWAYS validate before generating.

Parameters1

yaml

string

required

The full YAML model source to validate

Raw schema

{
  "type": "object",
  "properties": {
    "yaml": {
      "type": "string",
      "description": "The full YAML model source to validate"
    }
  },
  "required": [
    "yaml"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

opcua_model_generate

Generate OPC UA NodeSet2.xml and Symbols.CSV from a YAML model. Requires an API key (set OPCUA_MODELER_API_KEY env var). Returns base64-encoded artifacts if the model is valid, or diagnostics if validation fails. Optionally set include_docs=true to also generate markdown documentation.

Parameters2

yaml	string	required	The full YAML model source to generate from
include_docs	boolean	optional	Set to true to include markdown documentation (slower)

Raw schema

{
  "type": "object",
  "properties": {
    "yaml": {
      "type": "string",
      "description": "The full YAML model source to generate from"
    },
    "include_docs": {
      "type": "boolean",
      "description": "Set to true to include markdown documentation (slower)"
    }
  },
  "required": [
    "yaml"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

opcua_model_reverse

Reverse-engineer a NodeSet2.xml file back into the YAML DSL format. Requires an API key (set OPCUA_MODELER_API_KEY env var). Optionally specify the target namespace URI to extract.

Parameters2

xml	string	required	The NodeSet2.xml content to reverse-engineer
namespace_uri	string	optional	Target namespace URI to extract (auto-detected if omitted)

Raw schema

{
  "type": "object",
  "properties": {
    "xml": {
      "type": "string",
      "description": "The NodeSet2.xml content to reverse-engineer"
    },
    "namespace_uri": {
      "type": "string",
      "description": "Target namespace URI to extract (auto-detected if omitted)"
    }
  },
  "required": [
    "xml"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

opcua_model_create

Generate an OPC UA YAML model from a natural language description using AI. Requires an API key (set OPCUA_MODELER_API_KEY env var). The AI will auto-detect relevant companion specs, generate a validated model with documentation, and auto-correct validation errors.

Parameters2

prompt	string	required	Natural language description of the OPC UA model to generate
forceSpecs	array	optional	Companion spec aliases to force (e.g. ["di", "ia"])

Raw schema

{
  "type": "object",
  "properties": {
    "prompt": {
      "type": "string",
      "description": "Natural language description of the OPC UA model to generate"
    },
    "forceSpecs": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Companion spec aliases to force (e.g. [\"di\", \"ia\"])"
    }
  },
  "required": [
    "prompt"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

README.md15 KBView on GitHub

node-opcua-modeler-mcp-server

npm downloads total

An MCP server that gives AI agents access to the OPC UA companion specification type system — 764 types across 30 industrial namespaces, plus 1,533 engineering units — and lets agents validate, generate, reverse-engineer, and create OPC UA information models.

Built on node-opcua, the most widely used OPC UA stack for Node.js.

Why?

When an AI agent needs to build an OPC UA information model, it must know:

What companion spec types exist (DI, Machinery, Robotics, Machine Tools…)
What components, properties, and methods each type has
What namespace dependencies are required
What engineering unit symbols are valid (UNECE Rec. 20)

This MCP server answers all of those questions — offline, for free, in milliseconds.

Quick Start

With Claude Desktop

Add to your claude_desktop_config.json:

json

{
  "mcpServers": {
    "opcua-modeler": {
      "command": "npx",
      "args": ["-y", "node-opcua-modeler-mcp-server"],
      "env": {
        "OPCUA_MODELER_API_KEY": "stfv_your_api_key_here"
      }
    }
  }
}

Note: The API key is optional for discovery tools (offline) and opcua_model_validate (50 anonymous calls/day). It is required for opcua_model_generate, opcua_model_reverse, and opcua_model_create. Register at opcua-modeler.sterfive.io and create a key under Settings → API — the free tier gives 25 calls/day for 90 days; see pricing for paid plans.

With any MCP client

bash

npx node-opcua-modeler-mcp-server

The server communicates over stdio using the Model Context Protocol.

Using a local backend instead of the hosted API

If you run the OPC UA Modeler CLI on the same machine, the model tools can be served from it instead of the hosted API — your YAML never leaves the host.

Start the server (requires a licence that includes the serve entitlement):

bash

opcua-modeler serve

Then set one environment variable in your MCP client config:

json

{
  "mcpServers": {
    "opcua-modeler": {
      "command": "npx",
      "args": ["-y", "node-opcua-modeler-mcp-server"],
      "env": {
        "OPCUA_MODELER_BACKEND": "local"
      }
    }
  }
}

No API key is needed in this mode — the client discovers the local endpoint and its credentials automatically.

Variable	Values	Purpose
`OPCUA_MODELER_BACKEND`	`cloud` (default), `local`	Which backend serves the model tools
`OPCUA_MODELER_API_KEY`	`stfv_…`	API key, `cloud` backend only
`OPCUA_MODELER_API_URL`	URL	Override the hosted API base URL

Notes

The two backends are never mixed, and there is no fallback between them. If local is selected and no server is running, the call fails with instructions rather than silently sending your model to the hosted API.
The seven discovery tools are local to this package and work offline on either setting.
opcua_model_create (AI generation) is available on the cloud backend only.

Tools

`list_namespaces`

List all 30 OPC UA companion spec namespaces with aliases, URIs, and dependencies.

code

→ list_namespaces()
← [
    { "alias": "di", "name": "OPC UA for Devices", "uri": "http://opcfoundation.org/UA/DI/", "dependencies": [] },
    { "alias": "robotics", "name": "OPC UA for Robotics", "uri": "http://opcfoundation.org/UA/Robotics/", "dependencies": ["di", "ia"] },
    ...
  ]

`resolve_dependencies`

Resolve the full dependency chain for companion spec aliases. Returns a topologically sorted list for the YAML namespaces: block.

code

→ resolve_dependencies({ aliases: ["machineTool"] })
← ["di", "ia", "machinery", "isa95JobControl", "machineryJobs", "machineTool"]

`list_types`

List all ObjectTypes and VariableTypes defined in a companion spec namespace.

code

→ list_types({ alias: "robotics" })
← [
    { "browseName": "MotionDeviceType", "kind": "ObjectType", "subtypeOf": "di:ComponentType", ... },
    { "browseName": "AxisType", "kind": "ObjectType", "subtypeOf": "di:ComponentType", ... },
    ...
  ]   // 25 types

`get_type_details`

Get the full structure of a type — components, properties, methods, interfaces, including inherited members.

code

→ get_type_details({ alias: "robotics", browseName: "MotionDeviceType" })
← {
    "browseName": "MotionDeviceType",
    "kind": "ObjectType",
    "subtypeOf": "di:ComponentType",
    "interfaces": ["di:IVendorNameplateType", "di:ITagNameplateType"],
    "components": [
      { "browseName": "robotics:Axes", "nodeClass": "Object", "typeDefinition": "FolderType", "modellingRule": "Mandatory" },
      { "browseName": "robotics:PowerTrains", "nodeClass": "Object", "typeDefinition": "FolderType", "modellingRule": "Mandatory" },
      ...
    ],
    "properties": [
      { "browseName": "di:Manufacturer", "dataType": "LocalizedText", "modellingRule": "Mandatory" },
      { "browseName": "robotics:MotionDeviceCategory", "dataType": "MotionDeviceCategoryEnumeration", "modellingRule": "Mandatory" },
      ...
    ]
  }

`search_types`

Search for types across all companion specs by keyword.

code

→ search_types({ query: "temperature" })
← [
    { "alias": "glass", "browseName": "MotorTemperatureTooHighEventType", ... },
    { "alias": "padim", "browseName": "TemperatureMeasurementVariableType", ... },
    { "alias": "amb", "browseName": "OverTemperatureConditionClassType", ... }
  ]

`find_reusable_block`

Find reusable Interfaces and AddIns by capability — pass a member name or keyword and get the standard blocks that already expose it. Prefer composing an existing block over redefining its members by hand.

code

→ find_reusable_block({ query: "SerialNumber" })
← [
    {
      "browseName": "di:IVendorNameplateType",
      "alias": "di",
      "kind": "interface",
      "matchedMembers": ["di:SerialNumber"],
      "members": ["di:Manufacturer", "di:Model", "di:SerialNumber", ...]
    },
    {
      "browseName": "machinery:MachineIdentificationType",
      "alias": "machinery",
      "kind": "addin",
      "matchedMembers": ["di:SerialNumber"],
      "members": ["machinery:Location", "di:SerialNumber", ...]
    }
  ]

kind tells you how to apply it: interface goes in interfaces:, addin in addIns:.

`find_engineering_unit`

Find the official UNECE Rec. 20 engineering unit symbol. Supports fuzzy matching and natural language aliases.

code

→ find_engineering_unit({ query: "celsius" })
← { "symbol": "°C", "matchType": "alias", "confidence": 1 }

→ find_engineering_unit({ query: "revolutions per minute" })
← { "symbol": "r/min", "matchType": "alias", "confidence": 1 }

→ find_engineering_unit({ query: "bar" })
← { "symbol": "bar", "matchType": "exact", "confidence": 1 }

`get_dsl_reference` ☁️

Fetch the YAML DSL grammar reference — the file header, top-level sections, type and instance syntax, and a list of common mistakes. No API key required.

Served from the API rather than bundled into this package, so the reference an agent reads always matches the validator that will judge its output.

code

→ get_dsl_reference()
← { "version": "1", "reference": "# OPC UA Modeler YAML DSL ..." }

`opcua_model_validate` ☁️

Validate an OPC UA YAML model for correctness. Returns diagnostics with severity, codes, messages, and line numbers. Works without an API key (limited to 50 calls/day per IP).

code

→ opcua_model_validate({ yaml: "namespaces:\n  di:\n..." })
← {
    "valid": true,
    "diagnostics": [
      { "severity": "warning", "code": "W001", "message": "...", "line": 42 }
    ]
  }

`opcua_model_generate` ☁️

Generate OPC UA NodeSet2.xml and Symbols.CSV from a validated YAML model. Returns base64-encoded artifacts. Requires an API key.

code

→ opcua_model_generate({ yaml: "namespaces:\n  di:\n...", include_docs: false })
← {
    "valid": true,
    "artifacts": {
      "nodeset2_xml": "PD94bWwg...",
      "symbols_csv": "bmFtZSxu..."
    },
    "diagnostics": []
  }

`opcua_model_reverse` ☁️

Reverse-engineer a NodeSet2.xml file back into the YAML DSL format. Requires an API key.

code

→ opcua_model_reverse({ xml: "<?xml version=..." })
← {
    "yaml": "namespaces:\n  di:\n...",
    "diagnostics": []
  }

`opcua_model_create` ☁️

Generate an OPC UA YAML model from a natural language description using AI. The AI will auto-detect relevant companion specs, generate a validated model with documentation, and auto-correct validation errors. Requires an API key.

code

→ opcua_model_create({ prompt: "A robotic welding cell with two robot arms, each having 6 axes, temperature monitoring on each motor" })
← {
    "success": true,
    "yaml": "namespaces:\n  di:\n  robotics:\n...",
    "attempts": 2,
    "diagnostics": [],
    "model": "gemini-2.5-pro",
    "tokens": { "input": 4200, "output": 1800 }
  }

→ opcua_model_create({ prompt: "A CNC lathe with spindle speed and temperature", forceSpecs: ["di", "cnc"] })
← {
    "success": true,
    "yaml": "namespaces:\n  di:\n  cnc:\n...",
    "attempts": 1,
    "diagnostics": [],
    "model": "gemini-2.5-pro",
    "tokens": { "input": 3500, "output": 1200 }
  }

Coverage

Companion Specifications (30)

Alias	Specification	Types
`padim`	OPC UA for PA-DIM	101
`ijtBase`	OPC UA for IJT Base	65
`machineTool`	OPC UA for Machine Tools	63
`scales`	OPC UA for Scales	58
`lads`	OPC UA for Laboratory Devices	53
`di`	OPC UA for Devices	44
`glass`	OPC UA for Glass Manufacturing	36
`machineVision`	OPC UA for Machine Vision	36
`adi`	OPC UA for Analyzer Devices	35
`commercialKitchenEquipment`	OPC UA for Commercial Kitchen Equipment	35
`i4aas`	OPC UA for I4AAS	32
`robotics`	OPC UA for Robotics	25
`ia`	OPC UA for Industrial Automation	20
`amb`	OPC UA for AMB	18
`autoId`	OPC UA for AutoID	18
`iolink`	OPC UA for IO-Link	16
`metalForming`	OPC UA for Metal Forming	16
	…and 12 more
Total	29 namespaces with types	764 types

The registry holds 28 specs; irdi is a dictionary-entry namespace and defines no ObjectTypes or VariableTypes. These figures come from catalog/catalog.json and are asserted against it by test/catalog-coverage.test.ts, so they cannot drift silently.

Engineering Units

1,533 official UNECE Rec. 20 symbols plus 136 natural language aliases (e.g., "celsius" → °C, "revolutions per minute" → r/min). Every alias resolves to a symbol the modeler engine accepts — the lookup never invents one.

How It Works

The server ships with a pre-generated catalog.json containing all type information extracted from OPC Foundation's official NodeSet2.xml files via node-opcua. All queries are answered from this static catalog — no network required, no API key needed.

code

┌──────────────────────────────────────────────────┐
│  node-opcua-modeler-mcp-server                   │
│                                                  │
│  LOCAL TOOLS (offline, free)                      │
│  ┌────────────────────────────────────────┐       │
│  │ catalog.json (1.7 MB)                  │       │
│  │ • 30 companion spec registries         │       │
│  │ • 764 type summaries + details         │       │
│  │ • 1,533 engineering units              │       │
│  └────────────────────────────────────────┘       │
│  7 tools → query the catalog                     │
│                                                  │
│  CLOUD TOOLS (via api.opcua-modeler.sterfive.io) │
│  5 tools → reference / validate / generate /     │
│           reverse / create                       │
│                                                  │
│  stdio transport (JSON-RPC)                      │
└──────────────────────────────────────────────────┘

Use Cases

AI-assisted OPC UA modeling — agents can discover types, resolve dependencies, and validate unit symbols before generating YAML/XML models
Copilot integration — add OPC UA awareness to coding assistants
Industrial digital twin design — explore companion spec type hierarchies interactively
Learning OPC UA — ask an AI to explain types and their relationships

Requirements

Node.js ≥ 18

OPC UA Modeler on GitHub — the open YAML DSL specification, the JSON Schema and example models; the place for questions and issues about the language
OPC UA Modeler — web app — Create, validate, and generate OPC UA information models in the browser
Product page — OPC UA Modeler overview, features, and licensing
Documentation — Guides, YAML DSL reference, and how-tos
Specification reference — Rendered OPC UA information-model specification
node-opcua — Full OPC UA stack for Node.js
Model Context Protocol — Open protocol for AI tool integration

Licensing

Three layers, stated once:

What	Licence
This package (`node-opcua-modeler-mcp-server`, the MCP client and its catalog)	Apache License 2.0 from version 1.5.0 — see NOTICE for trademark and third-party notices. Versions 1.0–1.4.x were published under MIT and remain so.
The hosted OPC UA Modeler API (`opcua-modeler.sterfive.io/api/v1`) that the cloud backend calls	Sterfive API Terms of Use — anonymous discovery, free and paid plans.
The OPC UA Modeler CLI and `opcua-modeler serve` (the local backend)	Sterfive commercial licence — see the product page.

"OPC UA Modeler" and "Sterfive" are trademarks of Sterfive SAS; the Apache licence grants no rights to them. Contributions are accepted under the Developer Certificate of Origin.

Install

Tools (12)

resolve_dependencieslist_namespaceslist_typesget_type_detailssearch_typesfind_reusable_blockfind_engineering_unitget_dsl_reference

Add to VS Code Add to Cursor

claude_desktop_config.json

json

{
  "mcpServers": {
    "node-opcua-modeler-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "node-opcua-modeler-mcp-server@1.6.1"
      ]
    }
  }
}

🛠️ Key Features

🚀 Use Cases

⚡ Developer Benefits

⚠️ Limitations

📌 Metadata

resolve_dependencies

list_namespaces

list_types

get_type_details

search_types

find_reusable_block

find_engineering_unit

get_dsl_reference

opcua_model_validate

opcua_model_generate

opcua_model_reverse

opcua_model_create

node-opcua-modeler-mcp-server

Why?

Quick Start

With Claude Desktop

With any MCP client

Using a local backend instead of the hosted API

Tools

list_namespaces

resolve_dependencies

list_types

get_type_details

search_types

find_reusable_block

find_engineering_unit

get_dsl_reference ☁️

opcua_model_validate ☁️

opcua_model_generate ☁️

opcua_model_reverse ☁️

opcua_model_create ☁️

Coverage

Companion Specifications (30)

Engineering Units

How It Works

Use Cases

Requirements

Related

Licensing

Install

Related servers

`list_namespaces`

`resolve_dependencies`

`list_types`

`get_type_details`

`search_types`

`find_reusable_block`

`find_engineering_unit`

`get_dsl_reference` ☁️

`opcua_model_validate` ☁️

`opcua_model_generate` ☁️

`opcua_model_reverse` ☁️

`opcua_model_create` ☁️