MCP tools

The MCP server exposes twelve tools. Seven answer from a catalogue bundled with the package — offline, no account, no key. Five call the hosted API, and only three of those need a key.

npx -y node-opcua-modeler-mcp-server

Tool	Where it runs	Key
list_namespaces	local	—
list_types	local	—
get_type_details	local	—
search_types	local	—
find_reusable_block	local	—
find_engineering_unit	local	—
resolve_dependencies	local	—
get_dsl_reference	cloud	—
opcua_model_validate	cloud	—
opcua_model_generate	cloud	yes
opcua_model_reverse	cloud	yes
opcua_model_create	cloud	yes

The remote connector cannot carry your key

Added by URL in Claude, the connector cannot supply your API key, so the three key-gated tools answer "authentication required". Run the server locally with OPCUA_MODELER_API_KEY set to use them — see the connector guide.

Discovery — the local tools

These are the ones to reach for first. An agent that queries the catalogue before writing YAML produces a model that reuses standard types instead of inventing parallel ones.

list_namespaces

Every companion specification the server knows, with alias, full name, URI and dependencies. No arguments.

list_types

Every ObjectType and VariableType in one specification.

alias — the spec alias, e.g. "machinery", "di", "robotics".

get_type_details

One type in full: components, properties, methods, the interfaces it implements, and its availableOptionals.

alias, browseName — e.g. "machinery", "MachineryItemIdentificationType".

This is the one that answers "what can I actually put on this type", and its availableOptionals is the authoritative list for optionals:.

search_types

Keyword search across every specification, returning the type and the spec that owns it.

query — e.g. "identification", "temperature", "motion".

find_reusable_block

Interfaces and AddIns that already expose a member or capability. Prefer composing one of these over redeclaring its members by hand.

query — a member name or capability, e.g. "SerialNumber", "health".

Each result says whether it is an interface (goes in interfaces:) or an addin (goes in addIns:), and which member matched.

find_engineering_unit

The official UNECE Rec. 20 symbol for a unit, with fuzzy matching and natural language aliases — "celsius" resolves to °C, "revolutions per minute" to r/min.

query — the unit as a human would say it.

Using this is how an agent avoids DSL-E-UNIT-001.

resolve_dependencies

Aliases in, a transitively resolved and load-ordered list out — ready for the namespaces: block.

aliases — e.g. ["machineTool", "robotics"].

Order matters to the loader, so resolve rather than guess.

Working with models — the cloud tools

get_dsl_reference

The YAML DSL grammar: file header, top-level sections, type and instance syntax, and common mistakes. No arguments, no key.

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

opcua_model_validate

Compile a model and return the diagnostics — severity, code, message, line. No key; anonymous callers get 50 calls a day per IP.

yaml — the full model source.

opcua_model_generate

Generate NodeSet2.xml and symbols from a model. Requires a key.

yaml — the full model source. include_docs (optional) — also return the Markdown documentation; slower.

opcua_model_reverse

Turn an existing NodeSet2.xml back into the YAML DSL. Requires a key.

xml — the nodeset content. namespace_uri (optional) — which namespace to extract; auto-detected if omitted.

opcua_model_create

Generate a model from a natural-language description, with spec detection and self-correction. Requires a key, and is the one tool that is deliberately not idempotent — the same prompt may produce different models.

prompt — what you want modelled. forceSpecs (optional) — pin the companion specs, e.g. ["di", "ia"].

See Generating with AI for how the loop works.

A workflow that works

The order matters more than any single tool:

1. list_namespaces — what exists
2. search_types or list_types — find the type to build on
3. get_type_details — see its members and optionals
4. find_reusable_block — before declaring anything by hand
5. resolve_dependencies — get the namespaces: block right
6. opcua_model_validate — before showing anyone the result

Steps 1–5 are free and offline. Only step 6 touches the network, and it does not need a key.

Backends

OPCUA_MODELER_BACKEND=local points the cloud tools at a local opcua-modeler serve over a socket instead of the hosted API, so models never leave the host. The two backends are never mixed and there is no fallback: shipping a model to the hosted API because a local daemon was down would be a data-egress bug, not a convenience. opcua_model_create is unavailable on the local backend.