Skip to main content
Glama
gchen19

AnkusDrive

by gchen19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

CNC Time Estimate

cnc_time_estimate
Read-only

Estimate CNC machining time from a solid model by calculating roughing and finishing minutes via material-removal-rate, setups, and tolerance, returning detailed time breakdown.

Instructions

Machining time for a live solid from a material-removal-rate model — the honest cnc machine time cost_estimate's flat volume table cannot give.

stock         = bbox grown by stock_allowance_mm per side
roughing_min  = (stock − part volume) / MRR(material)
finishing_min = machined face area / finish area-rate(material)
total         = (roughing + finishing)/utilisation · tolerance factor
                + setups · setup_min

MRR is per material class (aluminium 60, steel 12, stainless 6, titanium 2.5 cm³/min …) — ratios that track the standard machinability ratings amplified by the depth-of-cut headroom a soft alloy allows on the same spindle. Stock-envelope faces are excluded from the finishing area: facing a billet is not finishing a pocket. setups defaults to the count cnc_machinability_check derives from the same solid, so the two tiers agree. tolerance_class ('IT7', 7, …) scales the cutting time through the shared tolerance-cost corpus, so a tolerance costs the same here as in tolerance_cost_check.

fidelity='correlation', band_pct=50 — the RSS of MRR scatter (±40 %) and cut-time utilisation scatter (±25 %), against the flat table's ±100 %; supply a measured mrr_cm3_min and it tightens to 30. Feed machine_time_hr into cost_estimate(machine_time_hr=…) to replace the table there too.

Returns {machine_time_min, machine_time_hr, roughing_min, finishing_min, cutting_min, setup_min_total, removed_volume_mm3, stock_volume_mm3, removal_fraction, machined_area_mm2, setups, setups_basis, material_class, material_basis, mrr_cm3_min, finish_cm2_min, utilisation, tolerance, bbox_mm, part_volume_mm3, fidelity, band_pct, basis, warnings, next}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYes
setupsNo
materialYes
setup_minNo
mrr_cm3_minNo
utilisationNo
finish_cm2_minNo
tolerance_classNo
stock_allowance_mmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Read-only annotations are present)Skip the description adds substantial detail: the full formula, MRR defaults per material class, stock allowance logic, exclusion of stock-envelope faces from finishing area, tolerance scaling, fidelity and band_pct estimates, and the exact output fields. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with a formula and explanation of the output fields. It is front-loaded with the core purpose and the distinction from the sibling tool. Some sentences are dense, but each contributes useful context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description lists all return fields and explains the calculation pipeline, including accuracy/band_pct behavior and how to feed results into `cost_estimate`. It is missing explicit definition of `model`, but the overall context is sufficiently complete for a read-only estimation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It explains `stock_allowance_mm`, `setups` (defaulting to `cnc_machinability_check`), `material`, `mrr_cm3_min`, `utilisation`, `setup_min`, and `tolerance_class`. However, `model` and `finish_cm2_min` are less explicitly defined, though `finish_cm2_min` is implied by 'finish area-rate(material)'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific purpose: computing machining time from a material-removal-rate model, and explicitly contrasts itself with `cost_estimate`'s flat volume table. This clearly distinguishes it from siblings like `cost_estimate` and `cnc_machinability_check`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description names alternative tools (`cost_estimate`, `cnc_machinability_check`) and explains how they relate (defaults from `cnc_machinability_check`, and feeding `machine_time_hr` back into `cost_estimate`). It does not give an explicit 'when to use vs when not to use' statement, but the intended context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools