node-opcua-modeler-mcp-server

Official

by node-opcua

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.3.0
Disambiguation5/5
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.
Naming Consistency3/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.1/5 across 11 of 11 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

node-opcua-modeler-mcp-server MCP server

Copy to your README.md:

[![node-opcua-modeler-mcp-server MCP server](https://glama.ai/mcp/servers/node-opcua/node-opcua-modeler-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/node-opcua/node-opcua-modeler-mcp-server)

Score Badge

Copy to your README.md:

[![node-opcua-modeler-mcp-server MCP server](https://glama.ai/mcp/servers/node-opcua/node-opcua-modeler-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/node-opcua/node-opcua-modeler-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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