Deterministic release-compatibility preflight for OPC UA NodeSet2 XML.
Scored across 5 tools
The upload tools (begin_nodeset_upload, append_nodeset_chunk) are clearly distinct, and the two audit tools are separated by input source (direct XML vs. previously uploaded IDs). However, nodeset_compatibility_status has no description, leaving its relationship to the audit tools and upload lifecycle ambiguous, which could cause misselection.
Four tools follow a consistent snake_case verb_noun pattern (append_nodeset_chunk, audit_nodeset_compatibility, audit_uploaded_nodesets, begin_nodeset_upload). The fifth tool, nodeset_compatibility_status, breaks the pattern by omitting a verb, but the overall convention remains readable.
Five tools is well-scoped for a NodeSet compatibility gate: two handle chunked upload, two handle auditing by different input methods, and one reports status. Each tool appears to earn its place without obvious redundancy.
The core workflow of uploading NodeSets and auditing compatibility is covered, including large-file chunking and both direct/uploaded audit paths. Minor gaps include no explicit abort/cleanup for in-progress uploads and an undefined role for nodeset_compatibility_status, which may leave some lifecycle management unclear.
Append the next text chunk to a temporary NodeSet upload. Send chunks in original order without modification.
| Name | Required | Description | Default |
|---|---|---|---|
| chunk | Yes | ||
| upload_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the upload is temporary and that chunk ordering matters, but says nothing about permissions, chunk size or count limits, whether a finalization step is required, or what happens on out-of-order/duplicate appends for a mutation tool.
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 short sentences, zero filler, with the operation front-loaded and the ordering constraint immediately after. Nothing could be trimmed without losing information.
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 annotations, no output schema, 0% parameter coverage, and a multi-step sibling workflow, the description is too thin. An agent still cannot tell how to obtain upload_id, how large chunks may be, or whether the upload must be completed/finalized after the last chunk.
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 0% and the schema only gives titles, so the description must compensate. It implies chunk is raw text that must be unmodified, but does not explain where upload_id comes from (presumably begin_nodeset_upload) or any size/format constraints on chunk.
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?
States a specific verb (append) and resource (text chunk to a temporary NodeSet upload), which is enough to distinguish it from begin_nodeset_upload and the audit/status siblings. It stops short of explicitly naming those siblings, so it lands just below the top.
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?
"Send chunks in original order without modification" gives a real sequencing constraint, which is implied usage guidance. However, it never states the prerequisite that an upload must be started first (begin_nodeset_upload) or when this tool should be preferred over auditing an already-uploaded nodeset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two OPC UA NodeSet2 XML documents and report deterministic release-compatibility changes.
| Name | Required | Description | Default |
|---|---|---|---|
| new_nodeset_xml | Yes | ||
| old_nodeset_xml | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no indication of read-only vs mutating behavior, permission requirements, document size limits, or how 'deterministic' is achieved. It also doesn't clarify whether the comparison requires consistent NodeSet versions or namespaces.
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?
A single tight sentence with the core action front-loaded and no filler. It is efficient, though its brevity is partly a symptom of under-specification rather than disciplined conciseness.
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 annotations, no output schema, and zero parameter documentation, the definition leaves key questions unanswered: what the compatibility report contains, how the result is structured, and what input format the two XML parameters expect. For a domain-specific audit tool this is materially incomplete.
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 0%, so the description must compensate, but it only implies that two documents are compared. It never explains that old_nodeset_xml and new_nodeset_xml are inline XML strings (as opposed to file IDs or uploaded references) or any size/encoding constraints.
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 gives a specific verb (compare) plus resource (two OPC UA NodeSet2 XML documents) and names the output (deterministic release-compatibility changes). It is clear enough to distinguish from append_nodeset_chunk and begin_nodeset_upload, though it never contrasts itself with audit_uploaded_nodesets or nodeset_compatibility_status.
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?
There is no guidance on when to use this tool versus the closely named siblings audit_uploaded_nodesets and nodeset_compatibility_status. Nothing states prerequisites, such as whether the compared documents must already be uploaded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit two NodeSets previously uploaded with begin_nodeset_upload and append_nodeset_chunk. Upload IDs are consumed after this call.
| Name | Required | Description | Default |
|---|---|---|---|
| new_upload_id | Yes | ||
| old_upload_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose one genuinely important trait: upload IDs are consumed after the call, making this effectively a one-shot side-effectful operation. But it says nothing about permissions required, whether the audit mutates stored state, or what the call produces.
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 short sentences, zero filler, with the resource and the ID-consumption warning front-loaded where an agent will read them.
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 annotations, no output schema, and 0% parameter coverage, the description should do much more. It omits what the audit actually does or returns, whether both uploads must be fully assembled first, and what happens on failure, leaving an agent unable to predict the call's effect.
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 0% for two undocumented required parameters. The description's phrase 'two NodeSets' plus the old/new parameter names implies a comparison of an older against a newer upload, which adds some meaning, but it never explains the role or ordering of old_upload_id vs new_upload_id.
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?
States a specific verb ('Audit') and resource ('two NodeSets previously uploaded'), and ties the inputs to the begin_nodeset_upload/append_nodeset_chunk workflow, which helps distinguish it from siblings. However, 'audit' itself is not defined (comparison? validation?), leaving the actual operation somewhat opaque.
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 reference to begin_nodeset_upload and append_nodeset_chunk implies the prerequisite workflow, so usage context is partially conveyed. But there is no guidance on when to prefer this over the sibling audit_nodeset_compatibility, nor any stated exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a temporary in-memory NodeSet XML upload and return an upload_id. Use for large NodeSets that should be sent in multiple chunks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 key trait that the upload is 'temporary in-memory', hinting at a lifecycle limit, but says nothing about expiry/TTL, whether an abandoned upload is cleaned up, required permissions, or how the upload is finalized.
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, zero filler, and the core action plus return value are front-loaded ahead of the usage condition. 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?
With no output schema, the description correctly names the returned upload_id, and with zero params there is little else required. It is slightly thin on the multi-step upload lifecycle (expiry, how chunks are appended, how the session completes), which the siblings imply is the agent's next concern.
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 tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description adds only the return value (upload_id), which is useful but not parameter semantics.
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?
States a specific verb and resource ('Start a temporary in-memory NodeSet XML upload') plus the concrete return value ('upload_id'). The mention of multi-chunk sending implicitly distinguishes it from the append_nodeset_chunk sibling, so an agent can route correctly.
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 scopes usage: 'Use for large NodeSets that should be sent in multiple chunks.' This gives a clear when-to-use condition, but it never names the follow-up tool (append_nodeset_chunk) or says when NOT to use it (e.g. small NodeSets submitted in one call).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no 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?
Tool has no 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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
append_nodeset_chunkaudit_nodeset_compatibilityaudit_uploaded_nodesetsbegin_nodeset_uploadnodeset_compatibility_statusDeterministic preflight for FactoryTalk View tag and alarm CSV imports before re-import.
Independent static verification for exact immutable public GitHub commits.
Deterministic acceptance report for a supplied product catalog: validates price/currency/availabi...
EN 16931: validate invoice data, UBL/CII or PDF; emit XRechnung/Peppol XML, never a PDF.
Add one secure layer between your agents and this server.
