This MCP server provides AI agents with access to the OPC UA companion specification type system and tools for validating, generating, reverse-engineering, and creating OPC UA information models.
Discovery (offline, no API key):
List all 25 companion spec namespaces with aliases, URIs, and dependencies.
Resolve full, topologically sorted dependency chains for use in YAML namespaces: blocks.
List ObjectTypes, VariableTypes, and InterfaceTypes in a namespace (589 types across 22 namespaces).
Get detailed type structures including components, properties, methods, and inherited members.
Search for types across all specs by keyword.
Find reusable interfaces and add-ins by capability or member name.
Look up UNECE Rec. 20 engineering unit symbols with fuzzy/natural language matching (1,533 units + 134 aliases).
Model tooling (cloud/local backend; API key may be required):
Validate OPC UA YAML models for correctness with diagnostics (up to 50 anonymous calls/day).
Generate NodeSet2.xml, Symbols.CSV, and optional markdown docs from validated YAML (requires API key).
Reverse-engineer existing NodeSet2.xml files back into YAML DSL (requires API key).
AI-generate YAML models from natural language descriptions with automatic spec detection and error correction (requires API key, cloud only).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@node-opcua-modeler-mcp-server Find the engineering unit symbol for revolutions per minute"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI agents access to the OPC UA companion specification type system — 589 types across 22 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.
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.
Related MCP server: OpenKer Modeler MCP Server
Add to your claude_desktop_config.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 foropcua_model_generate,opcua_model_reverse, andopcua_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.
npx node-opcua-modeler-mcp-serverThe server communicates over stdio using the Model Context Protocol.
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):
opcua-modeler serveThen set one environment variable in your MCP client config:
{
"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 |
|
| Which backend serves the model tools |
|
| API key, |
| 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.
list_namespacesList all 25 OPC UA companion spec namespaces with aliases, URIs, and dependencies.
→ 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_dependenciesResolve the full dependency chain for companion spec aliases. Returns a topologically sorted list for the YAML namespaces: block.
→ resolve_dependencies({ aliases: ["machineTool"] })
← ["di", "ia", "machinery", "isa95JobControl", "machineryJobs", "machineTool"]list_typesList all ObjectTypes and VariableTypes defined in a companion spec namespace.
→ list_types({ alias: "robotics" })
← [
{ "browseName": "MotionDeviceType", "kind": "ObjectType", "subtypeOf": "di:ComponentType", ... },
{ "browseName": "AxisType", "kind": "ObjectType", "subtypeOf": "di:ComponentType", ... },
...
] // 25 typesget_type_detailsGet the full structure of a type — components, properties, methods, interfaces, including inherited members.
→ 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_typesSearch for types across all companion specs by keyword.
→ search_types({ query: "temperature" })
← [
{ "alias": "glass", "browseName": "MotorTemperatureTooHighEventType", ... },
{ "alias": "padim", "browseName": "TemperatureMeasurementVariableType", ... },
{ "alias": "amb", "browseName": "OverTemperatureConditionClassType", ... }
]find_engineering_unitFind the official UNECE Rec. 20 engineering unit symbol. Supports fuzzy matching and natural language aliases.
→ 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 }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 5 calls/day).
→ 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.
→ 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.
→ 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.
→ 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 }
}Alias | Specification | Types |
| OPC UA for PA-DIM | 101 |
| OPC UA for IJT Base | 65 |
| OPC UA for Machine Tools | 63 |
| OPC UA for Devices | 44 |
| OPC UA for Glass Manufacturing | 36 |
| OPC UA for Machine Vision | 36 |
| OPC UA for Analyzer Devices | 35 |
| OPC UA for Commercial Kitchen Equipment | 35 |
| OPC UA for Robotics | 25 |
| OPC UA for Industrial Automation | 20 |
| OPC UA for AMB | 18 |
| OPC UA for AutoID | 18 |
| OPC UA for Metal Forming | 16 |
| OPC UA for Machinery | 15 |
| OPC UA GDS | 14 |
| OPC UA for Woodworking | 13 |
| OPC UA for CNC Systems | 12 |
…and 5 more | ||
Total | 22 namespaces | 589 types |
1,533 official UNECE Rec. 20 symbols plus 134 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.
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.
┌──────────────────────────────────────────────────┐
│ node-opcua-modeler-mcp-server │
│ │
│ LOCAL TOOLS (offline, free) │
│ ┌────────────────────────────────────────┐ │
│ │ catalog.json (1.7 MB) │ │
│ │ • 25 companion spec registries │ │
│ │ • 589 type summaries + details │ │
│ │ • 1,533 engineering units │ │
│ └────────────────────────────────────────┘ │
│ 6 tools → query the catalog │
│ │
│ CLOUD TOOLS (via api.opcua-modeler.sterfive.io) │
│ 4 tools → validate / generate / reverse / create│
│ │
│ stdio transport (JSON-RPC) │
└──────────────────────────────────────────────────┘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
Node.js ≥ 18
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
Three layers, stated once:
What | Licence |
This package ( | 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 ( | Sterfive API Terms of Use — anonymous discovery, free and paid plans. |
The OPC UA Modeler CLI and | 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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Description or common name of the unit (e.g. "revolutions per minute", "celsius", "pressure bar") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. However, it does not mention any behavioral traits such as idempotency, side effects, error handling, or what happens if the query is not found. This lack of transparency could leave the agent uncertain about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that convey purpose and usage guideline without any unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema, no nested objects), the description is fairly complete. It explains the tool's purpose and usage context. However, it does not describe the return format or potential error scenarios, but for a lookup tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'query'. The tool description adds value by repeating that it's a description or common name, but this does not significantly extend beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: finding the official UNECE Rec. 20 engineering unit symbol for a given description. It uses the specific verb 'find' and resource 'official engineering unit symbol', and distinguishes itself from sibling tools which are about modeling and types, not unit lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit imperative: 'ALWAYS call this before using any engineering unit — NEVER guess unit symbols.' This provides clear guidance on when to use the tool, though it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Member name or capability keyword (e.g. "SerialNumber", "health", "calibration") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool searches for standard blocks by capability and explains how they are applied (interfaces: vs addIns:). It does not mention any side effects, permissions, or rate limits, but given it's a read-only search operation, the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using only three sentences. It front-loads the purpose and provides actionable usage guidance without unnecessary detail. Code formatting and clear structure enhance readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema, no annotations), the description covers everything needed: what it does, how to use it, and when to prefer it. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the parameter 'query' with examples. The description adds meaning by specifying it is a 'member name or capability keyword' and that it returns blocks that 'expose it'. This enriches the schema definition, which already has 100% coverage, so a score above baseline is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds reusable Interfaces/AddIns by capability (member name or keyword). It distinguishes itself from sibling tools like list_types or search_types by focusing on standard blocks that expose a capability, with specific examples like 'SerialNumber' or 'DeviceHealth'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer applying/composing an existing block over redefining members inline, and provides concrete guidance on when to use Interface vs AddIn: a single property uses Interface, a whole sub-object uses AddIn. This helps the agent make correct decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | Companion spec alias where the type is defined (e.g. "machinery") | |
| browseName | Yes | The type browse name (e.g. "MachineryItemIdentificationType") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly indicates a read operation without side effects but does not elaborate on return format, pagination, or any potential restrictions. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no extraneous text. It efficiently communicates the tool's purpose and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 simple parameters and no output schema, the description sufficiently covers what the tool does and when to use it. It lacks details on return format but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (alias, browseName) described in the schema. The description does not add additional meaning beyond what the schema provides, such as constraints or examples. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific type, listing components, properties, methods, interfaces, and optional members. This distinguishes it from sibling tools like list_types (which likely lists types) and search_types (which searches), making the purpose specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the tool to understand a type's structure before creating instances or subtypes. While it does not list when not to use it, the use case is clear and contextually relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the operation as listing 'well-known' namespaces, implying a read-only, simple lookup. No annotations exist, so the description carries full burden. It adequately conveys the behavior, though it could explicitly state it's non-destructive and fast.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with the action and purpose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description adequately explains what the tool returns (names, URIs, dependencies). Could be improved by specifying the output format (e.g., list of objects), but it's sufficient for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so parameter documentation is trivially complete. Per guidelines, 0 parameters gives a baseline of 4. Description adds no parameter info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'List', resource 'well-known OPC UA companion spec namespace aliases', and specifies returned data: full names, URIs, dependencies. Also includes usage hint 'discover what namespaces are available'. Distinguishes from sibling tools which are for modeling, validating, and searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context 'Use this to discover what namespaces are available'. No explicit when-not-to-use or alternative tools, but siblings don't overlap in function, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | Companion spec alias (e.g. "machinery", "di", "robotics") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'List ALL' implies read-only, but no details on performance, error handling, or what happens if alias is invalid. Adequate for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. Front-loaded with purpose and imperative usage instruction. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required param and no output schema, the description provides sufficient context: what it lists, when to use it, and the parameter meaning. Could mention output format but not necessary for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema description for 'alias' already explains it. Tool description adds only 'Companion spec' which is similar to schema. No additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies 'List ALL ObjectTypes, VariableTypes, and InterfaceTypes' with a clear verb and resource. It distinguishes from siblings like search_types and get_type_details by emphasizing 'ALL' and a specific namespace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'ALWAYS call this before using any type from a namespace — NEVER guess type names.' Provides strong guidance on when to use but lacks mention of alternatives like search_types for cases where types are known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Natural language description of the OPC UA model to generate | |
| forceSpecs | No | Companion spec aliases to force (e.g. ["di", "ia"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the AI-driven process, auto-detection of companion specs, validation, and auto-correction of errors. It does not describe output location or side effects, but covers key behavioral traits beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, then prerequisites, then process details. Every sentence adds value with no redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 params, no output schema, no annotations), the description covers core functionality, prerequisite, and behavior. It lacks explicit mention of output format or next steps but is sufficient for an experienced user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description reiterates the purpose of 'prompt' (natural language) and implies context for 'forceSpecs' (companion specs), but does not add significant meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an OPC UA YAML model from natural language, using AI. It distinguishes from siblings like opcua_model_reverse (reverse engineering) and opcua_model_generate (possibly from other inputs) by specifying 'from a natural language description'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (API key) but does not explicitly state when to use this tool vs alternatives like opcua_model_reverse or opcua_model_generate. The usage context is implied by the tool's name and sibling names, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| yaml | Yes | The full YAML model source to generate from | |
| include_docs | No | Set to true to include markdown documentation (slower) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: requires an API key, returns base64 artifacts on success or diagnostics on failure, and optionally generates documentation. It does not explicitly state whether it is destructive or if other side effects exist, but these are minor omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences: first states purpose and resources, second mentions prerequisite and return behavior, third adds optional parameter. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 params, no output schema, no annotations), the description covers purpose, prerequisites, return values, and optional behavior. Minor gaps exist such as unclear diagnostic format and lack of mention of side effects, but overall it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description repeats the schema's parameter descriptions almost verbatim, adding no significant new meaning beyond what is already in the input schema for either 'yaml' or 'include_docs'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and the specific resources (NodeSet2.xml, Symbols.CSV, optionally markdown docs) from a YAML model, distinguishing it from sibling tools like validation or reverse engineering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the required API key prerequisite and optional include_docs, providing clear context for when to use this tool, but it does not explicitly state when not to use it or compare to alternatives like opcua_model_create or opcua_model_validate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| xml | Yes | The NodeSet2.xml content to reverse-engineer | |
| namespace_uri | No | Target namespace URI to extract (auto-detected if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the API key requirement but does not disclose whether the tool is read-only, what side effects exist, or the exact output format (though it implies YAML). The behavioral traits are insufficiently specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that cover purpose and prerequisites. It avoids fluff, but could be improved by structuring information (e.g., separating requirements from options) for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify the output format and potential errors. It states 'back into the YAML DSL format' which gives a hint, but lacks details about the exact return type or error handling. Adequate but not fully complete given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of the namespace_uri parameter ('Optionally specify the target namespace URI to extract') adds no new meaning beyond the schema's existing description. No extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'reverse-engineer' and the resource 'NodeSet2.xml' with the output format 'YAML DSL'. However, it does not explicitly differentiate from sibling tools like 'opcua_model_generate' or 'opcua_model_create', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (API key) and an optional parameter, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., 'Use this when you have an existing NodeSet2.xml to convert'). No when-not or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| yaml | Yes | The full YAML model source to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the rate limit (50 calls/day) and indicates the tool returns diagnostics with severity, codes, messages, and line numbers. This suggests a read-only validation operation, which is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: clear purpose, key behavioral note (rate limit), and imperative usage hint. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description sufficiently explains the input, output (diagnostics with specific fields), and a notable constraint (rate limit). It could mention output format more explicitly, but overall it's complete for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'yaml', which is described as 'The full YAML model source to validate'. The description adds no additional semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates an OPC UA YAML model for correctness, using a specific verb and resource. This distinguishes it from sibling tools like opcua_model_generate or list_namespaces, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'ALWAYS validate before generating', providing clear when-to-use guidance. It also notes the tool works without an API key (50 calls/day limit), giving context on availability. It does not explicitly state when not to use, but the sibling context implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| aliases | Yes | Companion spec aliases to resolve (e.g. ["machineTool", "robotics"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks details on side effects, authorization needs, or return format. It only states it 'returns the full resolved dependency list' without specifying the data structure or confirming it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no unnecessary words. It efficiently conveys the tool's purpose and usage instruction, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and no annotations, the description adequately explains the tool's core purpose and when to use it. However, it omits the return format (e.g., array of strings) and any behavioral traits, which could lead to incomplete understanding for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of the single parameter, and the description adds context by labeling it 'companion spec namespace aliases' with an example. This clarifies the intended input beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves companion spec namespace aliases into a dependency list for the YAML `namespaces:` section. The verb 'resolves' and resource 'dependency list' are specific, but it doesn't explicitly differentiate from sibling tools like list_namespaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Always call this before generating the namespaces block' provides a clear usage context. However, it doesn't mention when not to use the tool or suggest alternatives, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keyword (e.g. "identification", "temperature", "motion") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses search across all specs, returns matching types with namespace alias. Implies read-only behavior, no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded action and scope. No wasted words. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one required parameter, no output schema, and simple behavior, the description fully covers what the tool does and returns. Sibling tools are different (e.g., find_reusable_block is for blocks not types).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description for 'query' parameter. Description adds examples of search keywords (e.g., 'identification', 'temperature'), providing extra helpful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search for types across ALL companion specs by keyword.' The verb 'search' and resource 'types' are specific, and the scope 'across all companion specs' distinguishes it from siblings like list_types or get_type_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when you don't know which namespace defines a type.' Provides clear context for when to use, though doesn't explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct purpose: discovering namespaces, types, blocks, and units; creating models via reverse or AI; validating and generating. No significant overlap; agents can clearly differentiate.
Tools follow two naming patterns: verb-based (list_namespaces, resolve_dependencies, etc.) and prefix-based (opcua_model_reverse, opcua_model_create, etc.). This inconsistency may cause minor confusion.
11 tools cover the full modeler workflow: discovery, creation, validation, and generation. The count is well-scoped for the domain without superfluous or missing tools.
Core lifecycle (discover, create, validate, generate) is covered. Missing editing or deletion of existing models, but these are not essential for the stated purpose of generating models.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Machine-readable utilities and datasets for AI agents.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Search, fetch (with provenance), scan, and convert AI instruction files for agents.
Open scientific and engineering knowledge for AI agents: search, evidence, document publishing.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/node-opcua/node-opcua-modeler-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
