Skip to main content
Glama

Cost Estimate

cost_estimate
Read-only

Compute per-unit manufacturing cost from part volume, material, and process, including material, machine, tooling amortization, and optional tolerance.

Instructions

Per-unit cost rollup (Design for Cost). material_cost = volume·density·price ·(1+scrap) from the Materials DB (process: cnc | fdm | casting | injection). process_cost = amortized setup + per-process machine time; tooling amortized over quantity, so unit_cost falls as quantity rises. The machine-time table is order-of-magnitude (fidelity='correlation', band_pct=100) — trust the ratios between processes/quantities, not the absolute dollars; material_cost alone is exact given its inputs.

material may be any Materials-DB card name (material_list / material_get), or anything at all if you price it yourself: price_usd_kg and density_kg_m3 override the DB lookup and are flagged in breakdown.price_basis / density_basis as 'explicit' instead of 'material'. A generic word like 'aluminum' is a CATEGORY, not a card — it carries a density but no price, so it needs price_usd_kg or a real card name (AL6061-T6, …); the error says which.

Two optional inputs sharpen it. tolerance_class ('IT7', '9', …) scales the TABLE machine time by the tolerance-cost curve (see tolerance_cost_check): holding tighter than the process's natural capability roughly doubles cost every 1.5 IT grades. machine_time_hr REPLACES the table with a time a real model computed (cnc_time_estimate) and drops band_pct from 100 to that model's band (50 by default, or machine_time_band_pct); the tolerance factor is then not applied again, because cnc_time_estimate already applied the same curve. Both default to None, reproducing the pre-existing behaviour exactly.

Returns {material_cost, process_cost, tooling_amortized, unit_cost, mass_kg, fidelity, band_pct, breakdown:{…, density_kg_m3, price_usd_kg, density_basis, price_basis, machine_time_hr, machine_time_basis, base_machine_time_hr, tolerance_class, tolerance_factor, tolerance_applied, tolerance_basis}}. Errors on a material with no usable density/price and no override, an unknown process/tolerance class, or a non-positive volume/quantity/machine time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
processNocnc
materialYes
quantityNo
setup_minNo
volume_mm3Yes
tooling_usdNo
price_usd_kgNo
density_kg_m3No
scrap_fractionNo
machine_time_hrNo
tolerance_classNo
machine_rate_usd_hrNo
machine_time_band_pctNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description goes far beyond the readOnlyHint=true annotation, disclosing the fidelity assumptions of the machine-time table (fidelity='correlation', band_pct=100), the exact behavior of overrides, the fact that defaults reproduce pre-existing behavior, and the error conditions when material data is unusable. It also explains how machine_time_hr replaces table-based time and how the tolerance factor interacts with it. No statement contradicts the annotations.

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

Conciseness5/5

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

The description is long, but every sentence earns its place: the core formula comes first, then material semantics, then optional sharpening inputs, then the return shape and error conditions. Formatting with inline code and grouping keeps the density navigable. For a 13-parameter tool with zero schema coverage, this length is justified rather than bloated.

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

Completeness5/5

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

Because there is no output schema, the description compensates by explicitly listing the complete return object, including the nested breakdown fields, plus error conditions. It also covers defaults, override behavior, fidelity/band semantics, and interaction with sibling tools. Nothing critical needed for an agent to invoke cost_estimate correctly appears to be missing.

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?

With schema description coverage at 0%, the description carries the full burden of documenting parameters, and it covers most of them well: volume, material, process, quantity, price/density overrides, scrap, tolerance_class, machine_time_hr, and machine_time_band_pct are all explained or formula-bound. The main gap is that machine_rate_usd_hr and setup_min are only implied by 'per-process machine time' and 'amortized setup' rather than named and defined. Given the schema provides no descriptions, this is a strong but not perfect compensation.

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 opens with a specific verb and resource: 'Per-unit cost rollup (Design for Cost)' and immediately defines the calculation. It goes beyond the title by giving the exact formula and the scope (materials DB, processes, quantity amortization), so there is no ambiguity about what the tool computes. It also implicitly differentiates itself from related tools by naming material_list/material_get, tolerance_cost_check, and cnc_time_estimate as complementary rather than competing operations.

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 gives clear context about when the tool is appropriate: for cost rollups, with material lookups from the Materials DB, or with explicit price/density overrides. It names related tools such as tolerance_cost_check and cnc_time_estimate as sources for optional sharpening inputs, and explains when those are relevant. It stops short of explicitly stating 'use this instead of X' for a direct cost-estimation sibling, but among the listed siblings no direct alternative exists, so the guidance is adequate.

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