Skip to main content
Glama
gchen19

AnkusDrive

by gchen19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

cnc_time_estimate

Estimate CNC machining time from a 3D model and material using removal-rate modeling, delivering roughing, finishing, and setup breakdowns for cost estimation.

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.3/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does so well: it explains the MRR model, stock envelope, exclusion of stock faces from finishing area, setups defaulting to cnc_machinability_check, tolerance scaling, fidelity band, and output fields. It still does not state whether the operation is strictly read-only, what permissions are needed, or what failure modes occur beyond 'warnings'.

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 front-loads the purpose and then uses a compact formula block and focused paragraphs. For a 9-parameter estimation tool with no annotations and no output schema, most of the detail earns its place, though the material and fidelity exposition is richer than strictly needed for tool selection.

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

Completeness4/5

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

Given the tool's complexity, 9 parameters, no annotations, and no output schema, the description is largely complete. It enumerates return fields such as machine_time_min, roughing_min, removal_fraction, and warnings, and documents dependencies on cost_estimate and cnc_machinability_check. Minor gaps remain around permissions and exact input formats.

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% for 9 parameters, so the description must compensate; it substantially does. It explains stock_allowance_mm, material, setups, mrr_cm3_min, utilisation, setup_min, and tolerance_class, and treats model as a live solid. It leaves finish_cm2_min only implicitly defined through the finishing formula and does not explain all defaults, keeping it short of perfect.

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 verb and resource: estimating machining time for a live solid from a material-removal-rate model. It directly distinguishes itself from cost_estimate's flat volume table, so an agent can tell why this tool exists and when it differs from a sibling.

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?

It gives clear context by contrasting this tool with cost_estimate's flat table and by referencing cnc_machinability_check for setups and tolerance_cost_check for tolerance scaling. It also says to feed machine_time_hr into cost_estimate, which is actionable usage guidance. However, it never states an explicit 'do not use this when' condition or a clean if/then alternative selection rule.

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