This server provides MCP tools to inspect, modify, simulate, and post-process Mastercam CAM data, with read-only inspection and confirmed write operations.
Inspect current Mastercam status and server capabilities
Retrieve active part, selection, geometry summary, stock, WCS, and machine groups
List and get details of operations, operation parameters, tools, toolpath status, and post processors
Capture graphical views and estimate cycle times
Compare toolpaths
Modify operations by setting feed/speed, changing tools, creating, duplicating, regenerating, updating stock, and setting work offsets
Run simulations and detect collisions
Post NC programs
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., "@mastercam-mcp list the toolpaths in the current Mastercam part"
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.
Mastercam MCP connects an MCP client with a local Mastercam session through a protected Windows named pipe. It gives an assistant a careful workflow for inspection, planning, confirmation, verification, and recovery.
The project includes a safe fixture backend so contributors can run the complete workflow without Mastercam or a license. The live adapter reports only capabilities that are actually mapped and verified. It never pretends that an unimplemented Mastercam action succeeded.
Install Node.js 22 or newer. From this repository run the following commands.
pnpm install
pnpm run build
$env:MASTERCAM_MCP_BACKEND = "mock"
pnpm run mock
pnpm test
node work\feature-smoke.mjsThe fixture supports active part inspection, operation search, operation explanation, risk reporting, machine context, feed and speed previews, confirmation gates, reread verification, rollback, regeneration, simulation, collision reporting, visual context, audit history, and diagnostics.
Related MCP server: vred-mcp
The published package can be started by any local MCP client.
npx -y mastercam-mcp@latest serveOn Windows the installer detects supported Mastercam folders and copies the add in into the selected chooks folder. Administrator approval is required because Program Files is protected.
npx -y mastercam-mcp@latest install -ConfigureClientsThe installer makes a backup before changing client configuration. It supports installation listing, repair through a repeat install, and uninstall through the PowerShell script.
Start with discover_capabilities and mastercam_doctor. Inspect the active part and operations. Search for the intended operation. Explain it and review its risks. Preview any change. Request explicit confirmation. Apply the change. Regenerate only the affected operations. Reread the result and keep the receipt.
The default server profile is read only. Writes require a write enabled profile and explicit confirmation. Posting, controller communication, DNC, FTP, cycle start, and arbitrary code execution are not provided.
Read only inspection includes the active part, geometry, selection, machine groups, operations, tools, stock, WCS, post processor, toolpath state, and cycle estimate.
Planning includes operation targeting, plain language explanations, risk reports, feed and speed previews, change verification, audit history, and fixture replay.
Advanced workflows include regeneration progress, simulation results, collision result models, visual context, and machine context. Fixture results are clearly marked as synthetic and cannot prove live machine safety.
Live use requires a legitimate Windows Mastercam installation, its matching NET Hook assemblies, the .NET SDK, and an enabled add in. Run the installer from an Administrator PowerShell window if automatic elevation is not available.
.\install.ps1 -ListInstallations
.\install.ps1 -MastercamRoot "C:\Program Files\Mastercam 2026" -ConfigureClientsAfter starting Mastercam run the diagnostic command.
npx -y mastercam-mcp@latest doctorLive operation mappings depend on the installed Mastercam release and its available API. The compatibility report shows what the add in can prove. A fixture pass is not a substitute for licensed live acceptance testing.
Install Node.js 22 or newer and pnpm. Open Terminal in the project folder and run the following commands.
pnpm install
pnpm run build
pnpm test
npx -y mastercam-mcp@latest servemacOS starts in portable fixture mode by default. You can set MASTERCAM_MCP_BACKEND=mock explicitly when using a client configuration. Live Mastercam NET Hook access is not available on macOS.
Install Node.js 22 or newer and pnpm. Open a shell in the project folder and run the following commands.
pnpm install
pnpm run build
pnpm test
npx -y mastercam-mcp@latest serveLinux starts in portable fixture mode by default. The setup sheet, JSON comparison, NC comparison, machine validation, fixture replay, stdio transport, and local HTTP transport work without a Windows dependency.
Install Node.js 22 or newer and pnpm. Open PowerShell in the project folder and run the following commands.
pnpm install
pnpm run build
$env:MASTERCAM_MCP_BACKEND = "mock"
pnpm test
npx -y mastercam-mcp@latest serveUse this mode when developing without a license. It uses the same MCP contract as the live server and clearly marks synthetic results.
pnpm install --frozen-lockfile
pnpm run build
pnpm test
pnpm pack --dry-runUse MASTERCAM_MCP_FIXTURE to load a JSON fixture containing a feed value and an operations array. Use MASTERCAM_MCP_AUDIT_PATH to select a local audit file.
Installation guidance is in docs/INSTALLATION.md. Environment settings are in docs/ENVIRONMENT.md. Capability details are in docs/CAPABILITIES.md. API evidence and the boundary around proprietary SDK files are in docs/API-EVIDENCE.md.
The server can generate a setup sheet from inspection data, compare tool database snapshots, compare NC text files, and validate an operation against a declared machine profile. These workflows are portable and can run with the fixture backend on Windows, macOS, and Linux.
MASTERCAM_MCP_BACKEND=mock pnpm testOn PowerShell use $env:MASTERCAM_MCP_BACKEND = "mock" before starting the server. The generated setup sheet is a review document and requires approval. NC comparison is read only. Machine validation reports warnings when controller or holder information is missing.
The live Windows installer checks the selected Mastercam root and its chooks folder. Exa verified the standard installation family under C:\Program Files and the shared data family under C:\Users\Public\Documents. Custom paths are supported through MastercamRoot. macOS and Linux use fixture and file workflows because the native Mastercam add in is Windows only.
Apache License 2.0
Mastercam capture view
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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 disclosing behavior, but it discloses nothing. It does not indicate whether the tool is read-only, whether it writes files, whether it modifies the Mastercam session, or whether it requires confirmation or produces side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. No information is front-loaded because there is essentially no information at all; every sentence or phrase should earn its place, and this one fails to deliver meaningful content.
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 nine parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain what the tool does, what the parameters mean, what the return value is, or how it relates to the surrounding Mastercam workflow.
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 description does not explain any of the nine parameters such as feed, speed, outputPath, operationIds, or confirmed. An agent cannot infer the meaning or purpose of these fields from the text.
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 'Mastercam capture view' is essentially a restatement of the tool name and does not specify what action is performed, what resource is affected, or what output is produced. It provides no differentiation from the many sibling tools and leaves the agent guessing whether this captures an image, a view state, or something else.
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 or when to prefer an alternative. The description provides no context, prerequisites, or exclusions, so an agent has no basis for selecting this tool over any sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam change tool
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior, but it only says 'change tool' with zero context about what happens to the tool, whether changes are destructive, require confirmation, or persist. The dryRun and confirmed parameters hint at side effects, yet the description does not explain them.
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 very short, which is concise, but it is under-specified rather than efficiently informative. It conveys no actionable content beyond the name, so brevity is not an asset here.
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 nine parameters, no output schema, and no annotations, the description is radically incomplete. An agent has no way to know what the tool does, how to set parameters, what a dryRun means, or what results to expect.
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 description adds no meaning to any of the nine parameters. Parameter names like feed, speed, toolId, operationId, and dryRun carry some self-evident meaning, but the description provides no linkage between these parameters and the change operation.
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 'Mastercam change tool' merely restates the tool name and adds the product context, so it is essentially tautological. It does not specify what changing a tool entails—whether it replaces the active tool, edits tool parameters, or affects operations—and it offers no differentiation from siblings like set_feed_speed or create_operation.
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 guidance is provided on when to invoke change_tool versus alternatives such as set_feed_speed, update_stock, or create_operation. The description does not mention prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam compare toolpaths
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure, but it provides none beyond the bare action. It does not mention whether the comparison is read-only, whether it requires existing toolpaths, what side effects occur, or whether it modifies state.
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 short but this is under-specification rather than conciseness. Every word merely repeats the tool name and product context, contributing no independent information or useful structure.
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 9 parameters, no required fields, no output schema, no annotations, and no parameter documentation, a three-word description is completely inadequate. There is no way for an agent to know what inputs matter, what the comparison returns, or what 'compare' means operationally.
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 there are 9 parameters, but the description adds no meaning to any of them. An agent receives no help understanding feed, speed, dryRun, operationIds, or confirmed, making correct invocation essentially guesswork.
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 'Mastercam compare toolpaths' essentially restates the tool name 'compare_toolpaths' without specifying what comparing entails, what dimensions are compared, or what result is produced. It identifies the resource and action but is too tautological to distinguish from siblings like get_toolpath_status or run_simulation.
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 scenarios, and no exclusion criteria. The description merely names the action, leaving an agent to guess whether this is the right tool for comparing feeds, speeds, geometry, or toolpath validity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam create operation
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
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, but it only repeats the action 'create'. It does not disclose side effects such as modifying the Mastercam document, whether confirmation or dryRun affects behavior, or what happens to existing operations, toolpaths, or output files.
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 only a three-word fragment rather than a structured, informative sentence. This is under-specification rather than conciseness, and it does not earn its place given the tool's complexity.
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?
This is a mutation tool with nine undocumented parameters, no annotations, and no output schema, yet the description offers no context about what creating an operation involves. An agent has no information about required inputs, workflow ordering, side effects, or expected 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?
There are nine parameters with 0% schema description coverage, and the description provides no meaning for any of them. Fields like feed, speed, dryRun, confirmed, operationId, operationIds, and outputPath remain completely unexplained, leaving the agent unable to construct a valid call with confidence.
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 'Mastercam create operation' essentially restates the tool name with only the product prefix added. It identifies a create action and an operation resource, but it is a fragment rather than an informative statement and does not explain what an operation means in this 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?
There is no guidance about when to use this tool versus any alternative. The description does not mention prerequisites, related tools, or situations where another operation-manipulation sibling would be more appropriate, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam detect collisions
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and the description discloses no behavioral traits. It is unclear whether this is a read-only analysis, whether it runs a simulation or generates geometry, or whether it modifies the Mastercam document state. The single noun phrase provides no safety or side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification, not effective conciseness. It earns no information because it only restates the tool name, and the lack of front-loaded details such as intended use or parameters makes the brevity a liability.
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 9 unannotated parameters, no output schema, and 26 sibling tools, the description provides none of the necessary context. It does not specify what inputs are used, what results are returned, how collisions are evaluated, or how this tool differs from adjacent operations, making it impossible for an agent 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?
The input schema has 9 parameters with zero documentation, and schema description coverage is 0%. The description offers no hints about the meaning of feed, speed, toolId, operationIds, outputPath, or the other fields, so the agent has no way to infer what parameters control the collision detection 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 'Mastercam detect collisions' merely prefixes the tool name with 'Mastercam' and restates the verb phrase from the name. It does not specify what action is performed, what inputs are required, or what output is produced, making it a tautology that fails to distinguish the tool from any other Mastercam operation.
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 guidance is given on when to use this tool instead of related siblings such as run_simulation, compare_toolpaths, or get_toolpath_status. The description does not mention conditions, alternatives, or the workflow context in which collision detection is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam duplicate operation
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses no behavior: no side effects, no mutation semantics, no result or error conditions. It is a noun phrase with no behavioral content.
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 definition is extremely brief, but this is under-specification rather than effective conciseness. It contains no information that helps an agent call the tool correctly.
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 nine undocumented parameters and no output schema or annotations, this description is completely inadequate. An agent cannot determine what inputs to provide, what happens on execution, or what response to expect.
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 description provides no explanation for any of the nine parameters. The tool name only hints at operationId/operationIds, but nothing clarifies feed, speed, dryRun, confirmed, outputPath, or toolId roles.
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 'Mastercam duplicate operation' merely restates the tool name and adds the product context. It lacks an explicit verb or action, so an agent cannot tell whether this duplicates an operation, checks duplication status, or removes duplicates.
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 siblings like create_operation, get_operation, or regenerate_toolpath. The description provides no context for selecting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam estimate cycle time
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits on its own. It only says 'estimate cycle time' and does not mention whether the operation is read-only, whether it writes output, whether it requires a confirmed state, or what side effects may occur. Given parameters like confirmed, dryRun, and outputPath, this lack of behavioral disclosure 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?
The description is extremely short, but it is under-specified rather than appropriately concise. It is a fragment that provides minimal value beyond the tool name and does not structure useful information for the agent.
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 9 optional parameters, no output schema, and no annotations, the description is far too sparse to be contextually complete. It fails to explain what inputs mean, what the tool returns, how to specify operations, or how to interpret the 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?
The input schema has 9 parameters with no descriptions, and schema description coverage is 0%. The description provides no explanation for feed, speed, dryRun, toolId, confirmed, outputPath, operationId, or operationIds, so the agent has no semantic grounding for any parameter.
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 'Mastercam estimate cycle time' identifies the action (estimate) and the resource (cycle time), making the basic purpose clear. However, it is a fragment rather than a full sentence, and it does not distinguish this tool from siblings like run_simulation or get_toolpath_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 alternatives such as run_simulation, compare_toolpaths, or regenerate_toolpath. The description gives no context about what scenarios call for estimating cycle time or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam get active part
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral detail such as whether the operation is read-only, whether it can fail, what conditions affect it, or what side effects might occur.
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 short, but this is under-specification rather than effective conciseness. It is a fragment that contains no new information beyond the tool name.
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 9 undocumented parameters, no output schema, and no annotations, the description is wholly inadequate. An agent cannot determine the purpose, parameters, return value, or safe usage from this definition.
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 description adds no meaning to any of the 9 parameters. The presence of irrelevant-looking parameters like feed, speed, dryRun, confirmed, outputPath, and operationIds is completely unexplained, leaving the agent unable to know how to invoke the tool 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 'Mastercam get active part' simply restates the tool name and gives no information about what an active part is, what data is returned, or how it differs from related read tools like get_geometry_summary, get_selection, get_stock, and get_wcs.
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 any of the sibling tools. The description does not mention context, prerequisites, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam get geometry summary
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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 disclosing behavior, but it discloses nothing beyond the word 'get.' It does not state whether the operation is read-only, what inputs affect the result, what output format to expect, or whether any session state changes.
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 short, but this is under-specification rather than effective conciseness. No sentence earns its place because there is no substantive content; the only text merely repeats the tool name.
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 9 undocumented parameters, no output schema, no annotations, and no description of the geometry source or summary contents, the definition is far from complete. An agent has essentially no basis for correctly invoking this tool or interpreting its result.
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 9 parameters with 0% description coverage, and the tool description mentions none of them. The presence of unrelated-looking parameters such as feed, speed, dryRun, confirmed, outputPath, and operationIds is not explained, making it impossible to know their relevance to geometry summarization.
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 'Mastercam get geometry summary' is a near-verbatim restatement of the tool name and provides no concrete information about what geometry is being summarized or what the summary contains. It functions as a tautology rather than an explanation, and it does not distinguish the tool from similar siblings like get_selection or get_stock.
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 offers no guidance on when to use this tool versus any of the 25 sibling tools. There is no stated context, prerequisite, or alternative, leaving the agent to guess whether geometry summary is intended for selected geometry, active part geometry, or stock geometry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam get operation
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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 the operation is read-only, what side effects might occur, what input state is required, whether it runs a dry run, or what output shape to expect. This is a critical gap for a tool with such an ambiguous name.
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 very short, but this is under-specification rather than concise effectiveness. It contains no structural information, no front-loaded distinctions, and no useful content that helps an agent decide to invoke the 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?
Given the tool has 9 parameters, no output schema, no annotations, and multiple closely related sibling tools, the description is wholly inadequate. An agent cannot determine the tool's purpose, inputs, outputs, or relationship to alternatives from the provided 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%, and the description does not explain any of the 9 parameters. The parameter names like feed, speed, dryRun, toolId, confirmed, outputPath, operationId, and operationIds may hint at meaning, but their roles, relationships, and whether they are filters, settings, or outputs are entirely undocumented.
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 'Mastercam get operation' is essentially a tautology of the tool name 'get_operation'. It states a generic get action on an operation resource but provides no detail on what the operation represents, what is returned, or how this differs from siblings like list_operations or get_operation_parameters.
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 many alternative operation-related tools such as list_operations, get_operation_parameters, or get_selection. No context, prerequisites, or selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam get operation parameters
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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 disclosing behavior. It implies a read-only 'get' operation, but does not state whether the operation is safe, whether it requires an existing operation, what the response contains, or how the many input fields are interpreted.
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 short but this is under-specification rather than effective conciseness. It contains no structured explanation and provides almost no actionable content for the agent.
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?
This is a 9-parameter tool with no annotations, no output schema, and no usage context. The description is far too minimal to support correct invocation or interpretation of results, especially in the presence of many similar sibling tools.
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 description adds no meaning to any of the 9 parameters. An agent cannot tell whether fields like feed, speed, name, outputPath, or confirmed are filters, output selections, or configuration options.
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 'Mastercam get operation parameters' merely restates the tool name and adds no detail beyond it. It does not specify what parameters are returned, for which operation, or how it differs from siblings like get_operation or list_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?
No guidance is provided about when to use this tool versus alternatives such as get_operation, list_operations, or set_feed_speed. The description gives no context for selecting this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam get post processor
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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 of disclosing behavioral traits. It provides none: no mention of side effects, return values, required state, configuration requirements, or whether this is a read-only operation. The word 'get' implies retrieval, but nothing about actual behavior is disclosed.
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 short but not effectively concise because it adds no information beyond the tool name. It is under-specified rather than tightly written, and the few words do not earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 undocumented parameters, no output schema, no annotations, and a large set of sibling tools, this description is severely incomplete. It fails to explain the tool's role, expected inputs, output, or relationship to related operations, making correct invocation nearly impossible for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 9 parameters with 0% description coverage, and the tool description does not explain any of them. Parameters like feed, speed, dryRun, operationIds, and outputPath are left entirely undefined, so an agent cannot determine what values to supply or why they matter.
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 'Mastercam get post processor' essentially restates the tool name and adds no meaningful detail about what the tool does, what a post processor is in this context, or what the result represents. It uses the same verb and resource as the name, making it a tautology rather than a clarifying purpose statement.
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 about when to use this tool versus sibling tools such as post_program, get_toolpath_status, or list_operations. The description gives no context, prerequisites, or alternative recommendations, leaving the agent without any decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam get selection
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden of behavioral disclosure. It only restates the tool name and does not state whether this is read-only, what it returns, whether it requires an active part, or whether parameters such as dryRun or confirmed change behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than conciseness. The single phrase 'Mastercam get selection' does not earn its place because it adds no information beyond the tool name and leaves every operational aspect undefined.
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, nine undocumented parameters, and a terse description, the tool definition is incomplete even for a simple retrieval call. An agent would be guessing at the meaning of the parameters and the result shape.
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 description gives no meaning to any of the nine parameters. An agent cannot infer what feed, speed, dryRun, toolId, confirmed, outputPath, operationId(s), or name are for or how to set 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 'Mastercam get selection' at least contains a verb and a resource, so it conveys that this tool retrieves a selection in Mastercam. However, it is essentially a restatement of the tool name with the product prefix, and gives no indication of what a selection is, what entities it covers, or how it differs from the many sibling getters such as get_operation or get_geometry_summary.
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 call this tool or when to prefer a sibling. It does not mention context, prerequisites, or alternatives despite the availability of get_operation, get_geometry_summary, list_operations, and get_active_part, which are likely competing retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam get stock
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only repeats the tool name. It does not state whether the operation is read-only, what side effects may occur, what the response contains, or any error or state-related behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than effective conciseness. It has no structural elements such as scoping, caveats, or examples, and it fails to earn its place by adding any useful 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?
Given the tool has 9 parameters, no output schema, and no annotations, a complete description is especially important. This definition provides almost no usable context and is grossly inadequate for an agent to select or invoke the tool 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?
There are 9 parameters with 0% schema description coverage, and the description provides no meaning for any of them. Fields like feed, speed, dryRun, operationIds, and outputPath are entirely unexplained, leaving an agent unable to determine their roles.
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 'Mastercam get stock' is essentially a restatement of the tool name and adds no clarifying detail about what 'stock' means or what the tool returns. It does not distinguish get_stock from siblings like update_stock or get_geometry_summary.
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 guidance is provided about when to use this tool versus alternatives. The description gives no context on prerequisites, selection criteria, or cases where another sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam get toolpath status
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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 of behavioral disclosure. It only repeats the word 'get' from the tool name and offers no information about side effects, read-only behavior, required permissions, or what the status response contains.
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 short, but this is under-specification rather than useful conciseness. The single phrase contains no operational detail and does not earn its place beyond restating the tool name.
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 a 9-parameter schema, no output schema, and no annotations, this one-line description is grossly incomplete. An agent cannot know what parameters to supply, what values are expected, or what the returned 'status' 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% across 9 parameters, and the description mentions none of them. The agent cannot determine whether fields like feed, speed, outputPath, operationId, or operationIds are inputs, filters, or settings, nor how they relate to retrieving status.
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 'Mastercam get toolpath status' is essentially a tautology of the tool name with a product prefix. It does not define what 'status' means, such as regeneration state, validity, or postability, and it does not distinguish this tool from siblings like mastercam_status or compare_toolpaths.
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 about when to use this tool versus alternatives like get_operation, compare_toolpaths, or regenerate_toolpath. The description provides no conditions, prerequisites, or decision criteria, so the agent must guess at the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam get wcs
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description discloses zero behavior beyond the name. It does not state whether this is safe to call, what data it returns, whether it reads from the active part or machine group, or whether it has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. A useful description could be one or two sentences that define the operation and key parameters; 'Mastercam get wcs' earns no credit for brevity because it adds no 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, 9 undocumented parameters, and low structural clarity, the description leaves almost everything unknown. For a simple getter the description could at least state what is returned and which input is primary, but it provides none of that.
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 none of the nine properties (feed, speed, dryRun, toolId, confirmed, outputPath, operationId, operationIds) are explained. The description mentions no parameters, so agents cannot know which inputs are relevant to retrieving a WCS.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description is 'Mastercam get wcs', which restates the tool name without defining WCS or what the function returns. It does not distinguish this tool from siblings such as set_work_offset or get_operation, so an agent cannot infer whether this queries work coordinates or some other resource.
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 guidance about when to call this tool or when to prefer alternatives is provided. The only signal is the word 'get' in the name, implying read-only, but no context such as 'use to retrieve the active work coordinate system before posting' appears.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam list machine groups
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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. 'List' implies a read-only operation, but the description does not state side effects, output behavior, scoping, or any operational traits beyond the bare 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?
The description is short and front-loaded, but it is under-specified rather than concise. Four words cannot earn their place when the tool has 9 parameters and no other documentation.
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?
This tool has 9 parameters, no output schema, no annotations, and no behavioral or usage details. The description is far too incomplete for an agent to select and invoke this tool 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 description coverage is 0% across 9 parameters, and the description does not explain feed, speed, name, dryRun, outputPath, operationIds, or any other parameter. The description provides zero compensation for the completely undocumented input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mastercam list machine groups' essentially restates the tool name with a product prefix. It names a verb and resource but adds no detail beyond the name itself, making it a tautology rather than a clarifying statement.
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 about when to use this tool versus sibling tools like list_operations or list_tools. No context, preconditions, or exclusion criteria are provided, so the agent must rely solely on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam list operations
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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. 'List' implies a read-only operation, but it does not disclose whether it returns all operations, filters by active part, requires a selected part, or has side effects. No behavioral detail beyond the verb is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. There is no front-loaded useful content beyond the tool name itself, so the brevity provides no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 undocumented parameters, no annotations, and no output schema, this description is severely inadequate. It gives an agent almost no basis for selecting, invoking, or interpreting the results of this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 9 parameters with 0% description coverage, and the description mentions none of them. The agent receives no guidance on what feed, speed, dryRun, toolId, confirmed, outputPath, operationId, or operationIds mean semantically or how they affect the listing.
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 'Mastercam list operations' is a tautology that restates the tool name 'list_operations'. It communicates the basic verb and resource but adds no distinguishing detail, so it does not help an agent differentiate this from sibling tools like get_operation or list_machine_groups.
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 such as get_operation, get_operation_parameters, or list_machine_groups. No context is provided about typical scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam list tools
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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 only gives the verb 'list', implying a read operation, but provides no detail on side effects, scope, output behavior, or whether this calls into Mastercam state. This is insufficient for an agent to predict the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which avoids verbosity, but this is under-specification rather than efficient communication. It fails to earn its place by clarifying the tool's real purpose or parameters.
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 9 undocumented parameters, no output schema, and no annotations, the description is far too minimal. An agent cannot determine valid input combinations, return format, or edge cases from this definition.
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 description adds no parameter-level meaning. There are 9 parameters, including ambiguous ones like toolId, operationIds, and confirmed, but the description provides no hints about which parameters are needed or how they affect the listing.
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 'Mastercam list tools' nearly restates the tool name and adds only the context 'Mastercam'. It lacks any detail about what is being listed, what a 'tool' refers to in this context, or how it differs from sibling tools like list_operations or list_machine_groups.
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. The description does not mention scenarios, prerequisites, or why an agent should pick list_tools over list_operations or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam mastercam capabilities
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided and the description discloses no behavioral traits whatsoever. An agent cannot determine whether this tool reads state, mutates data, runs simulations, or has side effects.
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 text is extremely short, but this is under-specification rather than useful conciseness. It contains no front-loaded meaning and no sentence earns its place because none provides 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?
Given 9 undocumented parameters, no output schema, no annotations, and a complex CAM domain, this description is completely inadequate for an agent to select or invoke the tool correctly. It explains neither what the tool does nor what the parameters control.
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 description does nothing to explain any of the 9 parameters such as feed, speed, dryRun, operationIds, or outputPath. The agent has no semantic grounding for any input.
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 'Mastercam mastercam capabilities' is a tautology that restates the tool name and gives no verb, resource, or concrete action. It does not distinguish this tool from any of the 25 siblings.
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 or when to prefer an alternative. The description provides zero context about use cases, prerequisites, or relationships to sibling operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam mastercam status
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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 of disclosing side effects, read-only behavior, or required context. The description discloses nothing beyond the word 'status', giving no indication of whether this tool mutates state, reads state, requires confirmation, or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It repeats 'Mastercam' and adds no informative content, so every word fails to earn 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 nine parameters, no annotations, no output schema, and many sibling tools, this description is completely inadequate. An agent has no way to understand the tool's purpose, behavior, or parameters, making correct invocation impossible.
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 description does not explain any of the nine parameters. Parameters like feed, speed, dryRun, operationIds, and outputPath are entirely unexplained, so an agent cannot know what values to provide or what they control.
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 'Mastercam mastercam status' is a near-tautology that restates the tool name without adding a verb or resource. It does not distinguish this tool from siblings such as get_toolpath_status or list_operations, so an agent cannot tell what operation this performs.
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 about when to use this tool versus alternatives. The description provides no context, conditions, or exclusions, leaving the agent to guess whether this is for checking status, setting status, or something else entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam post program
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
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, but it says nothing about side effects, output file creation, permissions, reversibility, or error behavior. For what is likely a write/output operation, this is a critical omission.
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 text is very short and free of fluff, but it is under-specified rather than concise. A 9-parameter tool needs far more structured guidance than a four-word phrase.
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 has 9 parameters, no annotations, no output schema, and no parameter documentation. The description is not sufficient for an agent to understand what the tool does, what inputs to supply, what outputs to expect, or what risks are involved.
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 several parameters such as toolId, operationId, and operationIds have empty schemas. The description names no parameters and provides no hints about which parameters are required, how operationId relates to operationIds, or what dryRun and confirmed control.
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 'Mastercam post program' is a noun-phrase restatement of the tool name and contains no verb or action. It does not specify whether the tool generates, modifies, uploads, or simulates a program, nor does it distinguish itself from siblings like get_post_processor or run_simulation.
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 indication of when to use this tool versus alternatives. There is no context about prerequisites, target scenarios, or exclusions, though the text is not actively misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam regenerate toolpath
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it is completely silent. It does not state whether the tool modifies the document, requires confirmation, supports a dry run, or what side effects may occur, leaving the agent to guess from parameter names.
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 short sentence, but this is underspecification rather than effective conciseness. It lacks structure and omits essential information that should be front-loaded, such as what the tool does, when to use it, and what parameters affect.
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 nine parameters, no schema descriptions, no annotations, no output schema, and a vague one-line description, an agent has virtually no basis to call this tool correctly or interpret its behavior. The description is grossly inadequate.
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 description adds no parameter information whatsoever. The nine properties (feed, speed, dryRun, confirmed, etc.) are entirely unexplained, so the agent cannot determine their meaning, relationships, or expected 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 'Mastercam regenerate toolpath' merely restates the tool name in nearly identical words and adds only the product name. It gives no detail on what regenerating entails and fails to distinguish this tool from siblings like get_toolpath_status or run_simulation.
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 regenerate_toolpath versus any of the sibling tools. The description does not mention prerequisites, typical scenarios, or alternative tools such as set_feed_speed, post_program, or run_simulation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam run simulation
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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 of behavioral disclosure. It says nothing about side effects, prerequisites, whether the simulation modifies state, whether confirmation is needed, or what happens after execution.
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 short but under-specified. It is not concise in a useful way because it communicates no operational information and does not earn 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?
This is a complex 9-parameter tool with no output schema, no annotations, and no meaningful description. The definition is completely inadequate for an agent to select or invoke this tool 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 description coverage is 0%, and the description adds zero meaning to any of the 9 parameters such as feed, speed, dryRun, confirmed, or outputPath. An agent has no way to infer what these parameters do or how to set them.
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 'Mastercam run simulation' simply restates the tool name and adds no concrete verb-resource behavior. It does not explain what running a simulation does, what it acts on, or how it differs from siblings like detect_collisions or post_program.
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 any of the many sibling tools, nor any exclusion criteria or context. This is merely an absence of guidance rather than misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam set feed speed
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist and the description adds no behavioral context beyond the name. It does not disclose that the tool may mutate a program, the role of dryRun or confirmed, file output behavior, or any side effects.
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 short, but this is under-specification rather than effective conciseness. It provides no structural benefit because it contains no substantive content beyond the tool name.
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 nine unannotated parameters, no output schema, and no usage guidance, the description is far from complete. An agent cannot determine what is required, what will change, or how to verify the result.
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?
With nine parameters and 0% schema description coverage, the description needed to explain key parameters but mentions none. It does not clarify feed, speed, operationIds, toolId, dryRun, confirmed, or outputPath 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?
The description "Mastercam set feed speed" essentially restates the tool name without adding detail about what is being modified or in what context. It conveys the broad action but offers no distinction from other operation-level 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?
There is no guidance on when to call this tool instead of alternatives, which operations or geometry it applies to, or whether a prerequisite selection is needed. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam set work offset
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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 of behavioral disclosure. It does not mention whether the operation mutates the part file, requires confirmation, performs a dry run, or affects specific operations. The schema hints at side-effecting parameters (confirmed, dryRun, outputPath), but the description says nothing about them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, consisting of only a fragment. While it wastes no words, it is under-specified to the point of omitting essential information and fails to structure any guidance for the agent.
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 9 parameters, no annotations, no output schema, and no parameter descriptions, the description is completely inadequate. An agent cannot determine required inputs, expected behavior, or return values, making the tool effectively uncallable without external knowledge.
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 description does not explain any of the 9 parameters. Properties like feed, speed, toolId, operationId, and confirmed are not tied to the concept of setting a work offset, leaving an agent with no semantic understanding of how to populate them.
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 ('set') and resource ('work offset'), which is enough to identify the core operation. It distinguishes itself from sibling tools like set_feed_speed and change_tool, which target different resources. However, it lacks any detail on what aspect of the work offset is being set or how it relates to the provided parameters.
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 provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. An agent must infer usage solely from the tool name, which is insufficient given many sibling tools that operate on similar resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mastercam update stock
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | ||
| name | No | ||
| speed | No | ||
| dryRun | No | ||
| toolId | No | ||
| confirmed | No | ||
| outputPath | No | ||
| operationId | No | ||
| operationIds | 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 of disclosing behavior. The description only names the tool; it does not state whether the operation is destructive, whether it modifies the active part, whether it requires user confirmation, or what side effects it has on the stock model.
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 short, but this is under-specification rather than conciseness. Every word only restates the tool name and product, so the brevity earns no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With nine unannotated parameters, no output schema, no required fields, and zero explanation, the tool is not safely callable by an agent. Critical context about what 'stock' means, what parameters are needed, and what happens on execution is entirely missing.
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 description adds zero information about the nine parameters. Parameters such as dryRun, confirmed, operationIds, and toolId are completely unexplained, leaving the agent without enough meaning to choose correct 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 'Mastercam update stock' is a tautology that restates the tool name without a specific verb or resource beyond 'stock.' It does not say what updating the stock does, what state it affects, or how it differs from cousins like get_stock, set_feed_speed, or change_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?
There is no guidance on when to use this tool versus the many sibling tools, no mention of prerequisites, and no indication of when a dryRun or confirmed flow is appropriate. The agent is left to guess the intended context.
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.0capture_viewchange_toolcompare_toolpathscreate_operationdetect_collisionsduplicate_operationestimate_cycle_timeget_active_partget_geometry_summaryget_operationget_operation_parametersget_post_processorget_selectionget_stockget_toolpath_statusget_wcslist_machine_groupslist_operationslist_toolsmastercam_capabilitiesmastercam_statuspost_programregenerate_toolpathrun_simulationset_feed_speedset_work_offsetupdate_stockScored across 27 tools
Most tools are clearly separated by resource and action, such as list_operations, get_operation, and create_operation. The main minor ambiguity is between generic status tools like mastercam_status and get_toolpath_status, but their scope is still distinguishable.
The majority follow a consistent verb_noun pattern like list_operations, get_stock, set_work_offset, and create_operation. Two tools use the mastercam_ prefix instead of a verb, which is a small deviation from an otherwise predictable naming scheme.
At 27 tools, this is slightly beyond the typical well-scoped range, but Mastercam is a complex CAM platform and the tools cover distinct capabilities across geometry, operations, tools, simulation, and post-processing. The count feels heavy but not bloated.
The toolset covers the main CAM workflow well: inspecting the part, managing operations, setting stock and WCS, modifying tools and speeds, simulating, checking collisions, and posting. Minor gaps include no delete operation and no general operation parameter editor beyond feed speed and tool changes.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
2,000+ MCP servers read at source level. Know what one does before you connect. Free, no key.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Read-only MCP server exposing a user ORANO library to their own AI agent.
