Provides tools for interacting with Siemens NX CAD software, enabling AI agents to create and edit parameterized parts, sketches, extrusions, holes, patterns, features, body measurements, STEP AP242 export, and undo operations in a locally confined workspace.
Click on "Deploy 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., "@dsh-nx create a rectangular plate with four corner holes"
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.
English | 简体中文
dsh-nx is an experimental DeepSeek Harness bundle for safe, local Siemens NX automation through MCP. Version 0.1.0 ships the current DSH bundle manifest, a typed MCP server, a Chinese/English-compatible modeling skill, workspace policy, mock bridge, doctor command, and an explicit protocol boundary for a future validated NX 2512 bridge.
This project is not affiliated with or endorsed by Siemens or DeepSeek.
The MCP server, schemas, workspace confinement, mock bridge and stdio end-to-end tests run on Linux and Windows.
The repository does not yet contain a real-NX-accepted NX 2512 bridge.
Mock results always contain mock: true and never write .prt or STEP files.
Do not use this release on production parts.
Related MCP server: SolidworksMCP
DeepSeek Harness removed the old .dsh-plugin repository format. This project uses the current npm bundle form (package.json.dsh.bundle + cordis.patch.yml). From the profile where you want NX tools:
dsh plugin --profile web add github:ethanrise/dsh-nxTagged releases also publish a prebuilt, version-independent asset named
dsh-nx.tgz. It avoids building TypeScript on the target machine:
https://github.com/ethanrise/dsh-nx/releases/latest/download/dsh-nx.tgzInstall the included skill for project-scoped discovery:
New-Item -ItemType Directory -Force .dsh\skills\nx-modeling | Out-Null
Copy-Item node_modules\dsh-nx\skills\nx-modeling\SKILL.md .dsh\skills\nx-modeling\SKILL.mdDuring repository development:
npm install
npm run check
DSH_NX_MODE=mock npm run devVariable | Purpose |
| Only directory the server may use for CAD files |
| Loopback-only bridge URL, for example |
| Random bearer token shared with the local bridge |
| Tool timeout; default 30000 |
| Test-only stateful mock; never creates CAD files |
| NX installation root used by |
No arbitrary journal, Python, C#, or shell execution tool is exposed.
Health/capabilities, new part, named expression, rectangle/circle sketch, extrusion, simple hole, rectangular pattern, bounded fillet/chamfer, feature listing, body measurement, safe save-as, STEP AP242 export, and undo.
The workflow also exposes session-state, preflight and post-mutation verification tools. See docs/architecture.md, the sample four-hole-plate.json, and the Windows scripts under scripts/.
A real adapter is supported only after all checks pass on native Windows + licensed NX 2512: create a parameterized four-hole plate, inspect native feature history, change an expression and rebuild, verify body count/bounding box/volume, save-close-reopen, export STEP, and undo. Until evidence is recorded under docs/nx2512-validation.md, the default bridge fails closed.
DSH Desktop obtains community listings through dsh-market and the
awesome-dsh-plugin catalog. See docs/marketplace.md
for the release checklist and conservative submission entry. This repository
must not be advertised as real NX automation until the validation gate passes.
MIT applies to this repository's code. Siemens NX, NXOpen libraries, documentation, licenses, and user part files are not distributed.
Apply an equal-distance chamfer using bridge-validated edge selectors.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| distance | Yes | ||
| selector | No | all_outer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states that a chamfer is applied, implying mutation, but it does not describe what geometry is affected, whether the operation is reversible, what preconditions must exist, or how failures are handled.
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 a single sentence with no filler, and the key action and object are front-loaded. However, the phrase 'bridge-validated' is jargon and the brevity comes at the cost of valuable parameter and usage detail.
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 mutation tool with no annotations, no output schema, and 0% parameter description coverage, this definition is incomplete. It omits the meaning of the required 'name' parameter, the selector semantics, required preconditions, and any guidance on verifying the result—despite the existence of nx_verify_result as a sibling.
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 needed to compensate by explaining the parameters. It vaguely ties 'distance' to the equal-distance concept and mentions 'edge selectors,' but it does not explain the required 'name' parameter, the units or interpretation of 'distance,' or the meaning of the 'all_vertical' and 'all_outer' enum values.
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 states a concrete verb ('Apply') and resource ('chamfer') and qualifies the operation as 'equal-distance', which distinguishes it from related operations like fillets. The phrase 'bridge-validated edge selectors' hints at the selection mechanism, though the jargon is unexplained.
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?
No explicit guidance is given about when to use this tool versus alternatives such as nx_fillet or nx_extrude. The mention of edge selectors and the enum values provides implied context, but an agent is left to infer when this tool is appropriate and how selector choices affect the result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a constrained, named circle sketch on a principal datum plane.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| plane | Yes | ||
| centerX | No | ||
| centerY | No | ||
| diameter | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'create' without disclosing side effects, prerequisites (e.g., an open part), or consequences. For a mutation tool, this is a significant gap.
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?
One efficient sentence with no waste, front-loading the verb and resource. It is appropriately concise for the basic purpose.
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 5 parameters, no output schema, and no annotations, the description is grossly incomplete. It lacks parameter semantics, behavioral details, and any guidance on constraints or plane options, leaving an agent unable to call it correctly.
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 0%, and the description mentions no parameters at all. It does not explain what name, plane, diameter, or centerX/Y mean, failing to compensate for the schema's lack of descriptions.
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 creates a circle sketch on a principal datum plane, distinguishing it from rectangle sketch. The verb 'create' and resource 'circle sketch' are specific, though 'constrained' and 'named' add intent without elaborating.
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 implies usage for circle sketches on principal planes but does not explicitly state when to use this tool over alternatives like nx_create_rectangle_sketch or provide exclusions. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a named NX expression in the current work part.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| unit | No | mm | |
| value | 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 indicates a write operation ('Create') but does not disclose what happens on duplicate names, whether the operation can be undone, whether the expression drives geometry, or if a current work part is required. The 'current work part' phrase is the only behavioral context beyond the verb.
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 front-loaded sentence with no filler. Every word contributes the core action, the resource, and the target part. It is appropriately concise for a simple tool.
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?
The tool is simple and the schema covers parameter types and constraints, so the description is nearly adequate. However, no annotations or output schema exist, and the description omits failure modes, duplicate-name behavior, and explicit prerequisites, leaving clear gaps.
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 should compensate. It only hints at the name parameter via 'named' and the value via 'expression'; it does not explain the name pattern, the numeric type, or the fixed mm unit. The schema provides the raw constraints, but the description adds almost no semantic help.
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 names a specific action ('Create'), a specific resource ('named NX expression'), and a location ('current work part'). This is enough to distinguish it from sibling tools, which all target different NX objects such as parts, sketches, extrusions, holes, patterns, fillets, and chamfers.
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?
Usage is implied: the tool is for creating a named expression in the active part. There is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives, but the context of 'current work part' provides a minimal boundary. It could be stronger by stating prerequisites such as having a work part open.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new millimeter NX part below DSH_NX_WORKSPACE. Does not overwrite an existing file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Workspace-relative .prt path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses two key behaviors: it creates a part with millimeter units and it does not overwrite existing files. This adds concrete safety context beyond the name, though it does not explain what happens if a file exists (error vs. no-op), which is a minor gap.
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 with no fluff. The core action and location are front-loaded, and the safety note is secondary. Every word 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?
For a simple one-parameter tool with no output schema, the description covers the essential action, scope, and a safety guarantee. It omits edge-case behavior (what happens on existing file) and return values, but these are minor for a create operation.
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% – the single parameter 'path' is fully documented as 'Workspace-relative .prt path'. The description adds no additional meaning about the parameter, so the baseline of 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 action (create), the resource (new millimeter NX part), and the location (below DSH_NX_WORKSPACE). It also adds a distinct safety note about not overwriting, which separates it from other creation tools like nx_create_expression or nx_create_rectangle_sketch that operate on different object types.
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 implies usage – you need a new part file – but it does not explicitly mention when to use this over alternatives or any exclusions. Sibling tools like nx_save_part_as or nx_create_expression are not referenced, so an agent must infer context from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a constrained, named rectangle sketch on a principal datum plane.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| plane | Yes | ||
| width | Yes | ||
| height | Yes | ||
| centered | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It identifies the created object as a constrained, named sketch, but does not explain side effects, session mutation, coordinate system implications, or whether the operation is reversible. This is minimal behavioral context.
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 a single efficient sentence, front-loaded with the action and free of filler. It is concise, though it sacrifices useful detail; that gap is better penalized under other dimensions.
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 five parameters, no schema descriptions, no output schema, and no annotations, this one-sentence description is incomplete. It leaves width, height, centered behavior, plane enum semantics, units, and expected results undocumented.
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. It only indirectly hints at 'name' and 'plane', while width, height, and centered are completely unaddressed. No units, constraint meaning, or default behavior is explained.
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 uses a specific verb ('Create') and resource ('rectangle sketch'), and adds distinguishing traits: constrained, named, on a principal datum plane. This clearly separates it from sibling tools like nx_create_circle_sketch.
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 states what the tool does but gives no guidance on when to use it versus alternatives, such as nx_create_circle_sketch, nor any prerequisites like an active part or session state. An agent must infer usage purely from the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a native simple through or blind hole in the unique current solid.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes | ||
| name | Yes | ||
| depth | No | ||
| through | No | ||
| diameter | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It discloses the mutating nature of the operation and a precondition that exactly one solid must be current, but it does not mention coordinate system, units, failure modes, or whether the operation is reversible.
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 a single active-voice sentence that front-loads the action and target. There is no wasted wording, though it is brief enough that it sacrifices needed parameter detail.
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 6-parameter tool with no output schema and no annotations, this description is too thin to guide a correct call. It omits geometry reference details, parameter semantics, and any explanation of how through versus blind holes are resolved, making it inadequate for reliable invocation.
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 connects the 'through or blind' wording to the through/depth parameters. The meanings of x, y, diameter, depth, and name are entirely undocumented, leaving an agent without sufficient semantic grounding.
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 states a specific verb ('Create') and a precise resource ('native simple through or blind hole') with a target context ('unique current solid'). It clearly differentiates this from sibling sketch and extrude tools by naming the native hole feature it creates.
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?
No explicit when-to-use or alternative tools are mentioned. The phrasing implies usage when a hole must be added to the current solid, but it does not contrast with sketch-and-extrude workflows or state any exclusions. This is implied usage rather than direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the current work part as STEP AP242 below DSH_NX_WORKSPACE. Never overwrites.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior on its own. It states 'Never overwrites' and constrains output to DSH_NX_WORKSPACE, which are useful behavioral traits. However, it does not clarify what happens if the target file already exists (error vs. auto-rename) or what the return value looks like, leaving some ambiguity.
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 with zero filler. The primary action and format are front-loaded, followed by a critical constraint. Every word earns its place, making it 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?
The core function and constraints are clear, and the tool is simple (one parameter, no output schema). However, the ambiguity around the 'path' parameter and the lack of error handling details mean an agent may not fully understand how to supply correct input. Overall adequate for a straightforward export, but not exhaustive.
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 defines a single 'path' parameter with no description, and schema description coverage is 0%. The tool description gives no clue about what 'path' means—whether it's a filename, a relative path, or a directory—beyond the vague 'below DSH_NX_WORKSPACE'. The description fails to compensate for the undocumented parameter, making correct invocation uncertain.
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 states a specific verb ('export'), resource ('current work part'), format ('STEP AP242'), and destination ('below DSH_NX_WORKSPACE'), which clearly distinguishes it from sibling tools like save_part_as. The 'Never overwrites' clause adds a unique constraint, making the tool's identity unmistakable.
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 implies the tool is for exporting to STEP format but does not explicitly mention when to use it instead of alternatives like save_part_as or other export tools. There is no guidance on exclusions or conditions, leaving the agent to infer usage from the format mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a native NX extrusion from an existing sketch.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| distance | Yes | ||
| sketchId | Yes | ||
| operation | No | new_body |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create' without mentioning side effects, the impact of the optional 'operation' parameter (unite/subtract), failure conditions, or what happens to the part. This is a significant gap 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?
The description is a single sentence with no wasted words, which is concise, but it is also under-specified. It does not front-load any critical details beyond the basic purpose, and it lacks structure that would help an agent parse actionable 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?
For a tool with 4 parameters (3 required), no annotations, and no output schema, the description is grossly incomplete. It does not explain prerequisites beyond having a sketch, does not describe the operation parameter, and leaves the agent without enough information to call the tool correctly or interpret results.
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 0%, and the description provides no information about the parameters (name, sketchId, distance, operation). It only mentions 'sketch' indirectly, but does not explain the meaning of distance, the operation enum, or required versus optional parameters. The description fails to compensate for the lack of schema descriptions.
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 uses a specific verb ('Create') and a specific resource ('native NX extrusion') and states the prerequisite ('from an existing sketch'). This clearly distinguishes it from sibling tools like nx_create_rectangle_sketch or nx_create_simple_hole, which address different operations.
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 only implies that a sketch must already exist, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or conditions. There is no guidance on when not to use it or which sibling tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a constant-radius fillet using bridge-validated edge selectors.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| radius | Yes | ||
| selector | No | all_vertical |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It mentions 'bridge-validated edge selectors', which hints at validation behavior, but it does not disclose that this mutates the part, whether it requires an active part, what happens on invalid selectors, or whether the operation is reversible.
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 a single concise sentence with no filler. 'Constant-radius' and 'bridge-validated edge selectors' add specificity beyond the tool name, though the jargon could be expanded slightly without hurting 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?
For a tool with 3 parameters, no annotations, and no output schema, this description is under-specified. An agent would not know what 'name' refers to, how to choose a selector, what the operation requires beforehand, or what success or failure looks like.
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. It loosely maps 'radius' to constant-radius and 'edge selectors' to the selector parameter, but it does not explain the required 'name' parameter, the meaning of the selector enum values 'all_vertical' and 'all_outer', or the default behavior.
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 operation: apply a constant-radius fillet, with a specific resource and verb. It also adds the distinguishing mechanism of 'bridge-validated edge selectors'. It does not explicitly differentiate from sibling tools like nx_chamfer, but fillet vs chamfer is semantically distinct enough.
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 gives no guidance on when to use this tool versus alternatives such as nx_chamfer or nx_extrude. It implies the tool is for fillets but does not state preconditions, when not to use it, or how edge selector modes should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the NX adapter and its explicitly supported operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 is a listing operation, implying it is read-only, but it does not explicitly state that it has no side effects or that it is safe to call at any time. This is a minor gap for a simple introspection 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?
The description is a single, well-formed sentence with no fluff. It is front-loaded with the verb 'List' and clearly names the target and scope.
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 zero-parameter tool with no output schema, the description is sufficient. An agent can call it without needing additional context about parameters, side effects, or return formats, as the output is inherently a list of operations.
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 has zero parameters, so the schema is complete and the description need not add anything. The baseline of 4 applies because there is nothing to document beyond the tool's purpose.
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 states exactly what the tool does: it lists the NX adapter and its explicitly supported operations. This is specific and distinct from all sibling tools, which perform concrete CAD operations rather than introspection.
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?
While it does not explicitly state when to use it, its role as a discovery tool is obvious from the description. It is the only tool that provides an overview of capabilities, so there is no competing alternative that requires explicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read current work-part, feature-count and modified state without changing NX.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states 'without changing NX,' which clearly communicates non-mutating behavior. It does not disclose error conditions or behavior when no part is loaded, but the core side-effect profile is 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?
A single sentence that is front-loaded with the action ('Read') and packs the resource and the key side-effect guarantee efficiently. Every word earns its place with no filler.
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 zero-parameter, read-only status tool, the description provides the essential information: what is read and that it has no side effects. It lacks only minor context, such as whether a session must be active or what the return format looks like, but the tool's simplicity keeps this from being a significant gap.
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 has zero parameters and an empty input schema, so there is no parameter semantics to add. The baseline of 4 applies because there is nothing the description needs to explain about arguments.
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 uses a specific verb ('Read') and a specific resource ('current work-part, feature-count and modified state'), and explicitly states 'without changing NX,' which clearly distinguishes it from the many mutating sibling tools like nx_create_part, nx_extrude, and nx_fillet. An agent can immediately tell this is a read-only status tool.
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?
Usage is implied: you would use this tool to inspect the current session state without side effects. However, it gives no explicit guidance on when to prefer it over other read-only siblings such as nx_health or nx_get_capabilities, nor does it mention any prerequisites or 'when not to use' scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the configured Siemens NX bridge without modifying NX.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'without modifying NX,' which clearly indicates a read-only, non-destructive operation. However, it does not disclose other behavioral aspects such as what the check involves, whether it may fail under certain conditions, or what the return value looks like. Given the lack of annotations, this is an acceptable but incomplete disclosure.
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 a single, concise sentence that front-loads the purpose and includes the key behavioral qualifier. There is no fluff or redundancy. Every word contributes to understanding what the tool does and that it is safe to invoke.
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 (zero parameters, no output schema), the description is minimally adequate but lacks important context. It does not explain what a 'health check' entails, what the expected return value is, or how it relates to other tools in the sibling set. For an agent, this might be sufficient for a simple status probe, but the lack of return-value information and any error conditions leaves some ambiguity.
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 has zero parameters, and the schema coverage is 100% (trivially, since there are none). According to the rubric, a zero-parameter tool receives a baseline score of 4 because there is no need to explain parameter semantics. The description does not mention any parameters, which 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: 'Check the configured Siemens NX bridge' – a specific verb (check) and resource (Siemens NX bridge). The qualifier 'without modifying NX' distinguishes it as a read-only health check, setting it apart from sibling tools like nx_create_part or nx_extrude that imply modification. It is not a tautology and provides a precise purpose.
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 implies usage – to check the health of the bridge – but provides no explicit guidance on when to use this tool versus alternatives such as nx_preflight or nx_get_capabilities. There is no mention of conditions, prerequisites, or exclusions. The intended use is inferable from the name and description, but the description does not actively route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current work part feature tree.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Read' does indicate a non-mutating operation, but no additional behavioral context is given—such as what happens if no work part is active, whether it returns an empty tree, or if there are any side effects. It is minimally transparent but not deeply informative.
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 one short sentence with no redundant phrasing. It front-loads the action and the target resource, and every word 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?
For a zero-parameter read-only tool, the description is mostly complete: an agent knows what to call and why. It could be slightly more complete by describing the return format or error behavior, but given the tool's simplicity, this is not a significant gap.
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 zero parameters, so there is nothing to document. Schema description coverage is effectively 100%, and the description correctly avoids inventing parameter details. Baseline for zero parameters is 4, and no deduction 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 uses a specific verb ('Read') and resource ('current work part feature tree'), clearly distinguishing this tool from siblings like nx_create_part, nx_extrude, and nx_get_session_state. An agent can determine exactly what this tool does without needing additional context.
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 implies its usage: call it when you need the current work part's feature tree. However, it does not explicitly state when to prefer it over alternatives or when not to use it. The context is sufficient for a zero-parameter read tool, but there is no explicit guidance about related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read body count, bounding box, area, volume and centroid.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only says 'Read', which implies non-destructive behavior, but it does not state whether it modifies anything, what happens if no body exists, or any permissions required. The lack of explicit disclosure of side effects or error conditions is a notable gap.
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 a single, front-loaded sentence that lists the key measurements without any redundant phrasing. Every word contributes to conveying the tool's purpose.
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?
While the description lists what the tool reads, it lacks details about the return format (e.g., whether it returns a single object or an array), units of measurement, or behavior when no body is present. Since there is no output schema to fill these gaps, the description is not fully complete for an agent to anticipate the tool's response.
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 has zero parameters, so the schema is empty and there are no parameter semantics to clarify. The description focuses on the output rather than parameters, which is appropriate. With no parameters, a baseline of 4 is given, and the description adds no confusion.
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 uses a specific verb ('Read') with a clear resource ('body') and enumerates the exact outputs (count, bounding box, area, volume, centroid). This distinguishes it from sibling tools that create or modify geometry, making its purpose unambiguous.
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 does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. However, the read-only nature and the specific list of measurements imply it is for inspecting body properties, and siblings are mostly creation/modification tools. This implicit guidance is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate one exact planned operation against current NX state immediately before mutation.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| expectedFeatureDelta | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether validation is read-only, what checks are performed, what the return value or error behavior is, or whether it has side effects. The description only hints at timing, not actual behavior, leaving the agent uncertain about consequences.
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 a single sentence that front-loads the purpose and timing. No filler words; every element contributes to the core meaning.
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 absence of annotations, output schema, and parameter explanations, the description is insufficient. An agent cannot know what validation entails, how to interpret results, or what expectedFeatureDelta controls. For a preflight tool that gates mutations, this is dangerously 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 by explaining parameter meaning. It does not mention 'operation' or 'expectedFeatureDelta' at all, leaving the agent to infer semantics solely from the schema's enum and type. This is a critical gap for a tool that requires a specific operation to validate.
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 uses a specific verb (validate) and a precise resource (one exact planned operation against current NX state) and clearly positions the tool as a pre-mutation gate. It is distinct from siblings that perform mutations or post-mutation verification, so an agent can readily identify its role.
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 phrase 'immediately before mutation' provides explicit timing guidance. It implies this tool should precede mutation tools (e.g., nx_extrude, nx_create_expression) but does not name alternatives or explicitly state when not to use it. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a rectangular native feature pattern from an exact feature id.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| countX | Yes | ||
| countY | Yes | ||
| pitchX | Yes | ||
| pitchY | Yes | ||
| featureId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states 'Create', implying a mutation, but does not mention side effects, dependencies on existing geometry, or failure conditions. This adds little beyond what the tool name already suggests.
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 a single sentence with no filler, front-loaded action and object. It is easily parsed and appropriately concise, even if too terse for full utility.
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 six required parameters, no annotations, and no output schema, this description is severely incomplete. It omits prerequisites like an active part, definitions of counts and pitches, and any expected behavior. An agent cannot safely invoke it without more supporting information.
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%: the schema has no property descriptions and the description mentions only 'featureId', without explaining countX, pitchX, countY, or pitchY. With six required parameters, the description provides essentially no semantic value to an agent trying to fill them correctly.
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 a specific action ('Create') and resource ('rectangular native feature pattern'), and names the key input ('exact feature id'). This is enough to distinguish it from sibling creation tools like nx_create_rectangle_sketch or nx_extrude, though it doesn't fully elaborate the pattern dimensions.
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 alternatives, no prerequisites, and no exclusions. The intended use is only implied by the action 'Create', leaving the agent to infer that an active part and an existing feature are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the current part to a new workspace-relative .prt path. Never overwrites.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only states 'never overwrites.' It omits other side effects such as whether the active part changes, whether directories are created, and what happens if the path exists. This is a notable gap 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?
A single sentence with no redundancy. The key constraint is placed immediately after the action, making it easy to parse and remember.
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 simple one-parameter operation, the description covers the purpose and safety constraint, but it lacks information about return values, error behavior, and side effects on the active part. Given the absence of annotations, additional detail would improve completeness.
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 description adds meaningful context to the single 'path' parameter: it must be workspace-relative, have a .prt extension, and must not already exist (since it never overwrites). This goes well beyond the schema's bare string type.
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 identifies the action (save current part), the destination (workspace-relative .prt path), and a defining constraint (never overwrites). It is specific enough to distinguish from creation and export operations among the sibling tools.
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 implies when to use it (saving a copy to a new path) but provides no explicit guidance on alternatives or when not to use it. There is no mention of preferring this over nx_export_step or nx_create_part for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Undo the most recent dsh-nx transaction after inspecting current state.
| Name | Required | Description | Default |
|---|---|---|---|
| transactionId | No |
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 identifies the tool as an undo (a mutation), but does not disclose what the transaction reverts, whether the undo itself is reversible, what side effects occur, or what permission/state checks are needed. That is a significant gap for a destructive 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?
A single sentence with no filler, the key verb front-loaded and the sequencing advice kept short. Every word contributes to the core message.
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?
The signature is simple, but the absence of annotations and an output schema means the description should explain side effects, return behavior, and the meaning of transactionId. It does not, leaving an agent to guess the consequences of calling it.
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 0% and the description never mentions transactionId. The schema shows an optional UUID, but the agent cannot tell whether supplying it targets a specific transaction instead of the most recent one or what the default behavior is.
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 names a specific action ('Undo'), a clear resource ('the most recent dsh-nx transaction'), and a scope qualifier. No sibling tool appears to perform an undo, so an agent can distinguish it from the create/measure/preflight tools without further info.
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 only guidance is the sequencing instruction 'after inspecting current state', which tells the agent to verify before reverting. However, it never states when an undo is appropriate, when to avoid it, or how transactionId selects a different transaction; no alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify observed feature/body state after a mutation; mock mode never claims exact geometry.
| Name | Required | Description | Default |
|---|---|---|---|
| preflightId | Yes | ||
| expectedBodyCount | Yes | ||
| expectedFeatureCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the important behavioral trait that 'mock mode never claims exact geometry,' which alerts the agent to a limitation of the tool in simulation. However, it says nothing about whether the tool is read-only, requires specific permissions, or returns any status or error behavior, leaving significant gaps.
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 a single, front-loaded sentence that states the primary purpose before adding the mock-mode caveat. It contains no wasted words and is appropriately compact for a simple verification tool, though it could be more actionable with parameter or behavior details without becoming verbose.
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 (three required params, no output schema, and no annotations), the description is too sparse. It does not explain what the tool returns (e.g., a boolean, a report, a state snapshot) or how the expected counts are validated, leaving an agent to guess at the invocation contract and result semantics.
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 no descriptions for its three required parameters, and the description provides only a vague link to 'feature/body state' without mapping expectedFeatureCount, expectedBodyCount, or preflightId to concrete concepts. With 0% schema description coverage, the description fails to compensate by explaining what these counts mean or how the preflightId relates to a previous mutation.
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 states a specific verb ('verify') and resource ('observed feature/body state after a mutation'), which clearly answers what the tool does and distinguishes it from the creation and editing siblings like nx_extrude and nx_chamfer. However, it does not explicitly name a sibling alternative or contrast itself, so it misses the full 5-point bar for sibling differentiation.
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 phrase 'after a mutation' provides a clear temporal context for when to use this tool, implying it is the follow-up verification step to mutation operations like nx_extrude or nx_fillet. There is no explicit guidance on when not to use it or which sibling might be preferable (e.g., nx_list_features or nx_measure_body), so the guidance remains implicit.
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.
v0.1.0nx_chamfernx_create_circle_sketchnx_create_expressionnx_create_partnx_create_rectangle_sketchnx_create_simple_holenx_export_stepnx_extrudenx_filletnx_get_capabilitiesnx_get_session_statenx_healthnx_list_featuresnx_measure_bodynx_preflightnx_rectangular_patternnx_save_part_asnx_undonx_verify_resultScored across 19 tools
Each tool maps cleanly to a distinct resource or action: creation, feature application, inspection, state verification, save/export, or undo. Even the introspective tools (health, capabilities, session state, feature list) are clearly separated by their descriptions, so an agent should not misselect.
The set mostly follows the nx_verb_noun pattern: create_part, measure_body, list_features, export_step. A few names deviate slightly—nx_preflight, nx_health, and nx_rectangular_pattern are noun-first or verbless—but the shared nx_ prefix and overall consistency keep the convention readable.
Nineteen tools is slightly above the typical well-scoped range, but every tool represents a distinct CAD capability from part creation, sketching, and feature modeling through measurement, export, and undo. There are no redundant operations, and the count feels justified for an NX-oriented adapter.
The set covers a solid create, modify, measure, and export workflow, but it lacks explicit update/delete operations for expressions, sketches, features, or parts—undo is the only lifecycle escape hatch. Common CAD operations such as revolve, sweep, boolean, and trim are also absent, so broader modeling tasks would require workarounds.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Hosted MCP catalog with 30 tenant-isolated browser, RAG, AI, mail and media tools.
MCP facade over the Nebelus Construction API. ~48 tools give full agent build parity: create/update/probe agents, edit graphs, attach knowledge and vector stores, wire connectors, set governance policies and locked guardrails, enable grounding-trace, and read deployment wiring. Purpose-built for regulated industries: data residency is enforced per region (EU / GCC-KSA), with PII controls and an audit trail. Agents are created as drafts — no deploy tool is exposed over MCP by design; publishing happens in the Nebelus console.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
