Skip to main content
Glama

Optimize Lot Size

optimize_lot_size
Read-onlyIdempotent

Find the lot size with the lowest total cost for a calculation: production cost plus holding cost (capital tie-up and storage), capped at one year of demand. Use it to answer how many parts to make per batch. Returns the optimal lot, the yearly saving of moving there, the cost-versus-quantity curve, an Andler/EOQ cross-check and at most two directions (change the lot size, cut setup time). To price one other lot size exactly, use preview_cost. Read-only and free.

Input Schema

NameRequiredDescriptionDefault
calculation_idYesId of a calculation, as upload_and_quote, quote_part or list_calculations return it.

Output Schema

NameRequiredDescriptionDefault
curveNoCompact curve points: {quantity, unit_cost, direct_unit_cost (before overhead, setup amortised over that lot), offer_price (the per-unit figure a quote shows), setup_time_s, unit_time_s} — cost AND time vs quantity in one read, when present; money in currency. Exact at exact_at_quantity, indicative elsewhere (see accuracy).
statusYes
accuracyNoHow far a curve point may sit from a real run at that quantity, as the API publishes it: {basis, max_deviation_pct, note}. Null on older calculations.
currencyNoCurrency every money figure on this result is stated in (the calculation's), the optimum and the curve alike.
guidanceYes
scenarioNoThe scenario recommended_lot_size states — buyer_stock: the buyer orders in lots and holds the stock. Absent on older calculations.
scenariosNoEvery lot-size scenario's answer on the same curve: buyer_stock, supplier_stock (the supplier produces ahead of a steady call-off and holds the stock, economic production quantity), make_to_order (shipped complete, consumed on delivery — only the supplier's work in progress is held), joint (a frame contract with call-offs, both parties' costs minimised together: the call-off and the supplier's production lot) and consignment (the frame contract with supplier-owned stock at the buyer's site until use — capital at the supplier's production cost on every unit, storage where it sits). Pick the one that is your situation. Empty on older calculations.
annual_volumeNoAnnual demand the optimum weighs holding against.
calculation_idYes
andler_lot_sizeNoClassic Andler/EOQ closed-form cross-check quantity.
recommendationsNoAt most two solid optimization directions; empty when nothing material or the calculation predates the optimum.
valuation_basisNoHow the scenarios value a piece. purchase_price: the buyer pays and holds at the purchase price after the supplier's customer and cash discounts; the supplier holds at production cost including material and production overheads. offer_price: a calculation made before that basis — the buyer at the offer price, the supplier's stock at manufacturing cost; recalculate to restate it. Absent on older calculations.
current_lot_sizeNo
current_unit_costNoProduction cost per piece at the ordered lot, in currency.
exact_at_quantityNoThe lot this calculation was run for: the curve reproduces its price exactly here and is indicative at every other quantity. Null on older calculations.
net_annual_savingNoNet saving per year of moving to the recommended lot, production plus inventory holding, in currency.
single_lot_demandNoTrue when one lot already covers the whole annual demand (annual_volume ≤ current_lot_size). There is then no lot-size trade-off to optimise: the recommendation equals the current lot by construction, not because the lot is economically optimal. annual_volume defaults to 1 when a request omits it — pass the real annual demand to get a recommendation.
recommended_lot_sizeNoTotal-cost optimal lot (≤ one year of demand).
recommended_unit_costNoProduction cost per piece at the recommended lot, in currency.
ordering_cost_per_orderNoThe buyer's fixed cost per order or delivery (order handling and inbound freight) the buyer-side scenarios weigh against the price breaks (0 where the environment states none), in currency.
inputs_changed_since_runNoNull when this price reflects every input on its part revision. Otherwise {roles, corrections, latest_at}: files attached and corrections applied to the part after the run read its inputs, which a new calculation reads and this one did not.
production_rate_per_yearNoPieces the route can make in a year of its machines' run hours — the finite production rate behind the supplier and joint scenarios. Absent where no machine states annual hours.
current_effective_unit_costNoThe buyer's effective cost per piece at the ordered lot (buyer_stock): the price per piece on the basis valuation_basis names, plus the per-piece ordering and inventory holding cost, in currency.
environment_changed_since_runNoNull when this price was computed on its costing environment as it stands. Otherwise {latest_at}: the environment was edited after the run read it, and a new calculation prices with the current setup while this result does not.
recommended_effective_unit_costNoThe buyer's effective cost per piece at the recommended lot (buyer_stock), on the same basis as current_effective_unit_cost, in currency.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / calculation_id / format
      Added value: +"uuid"
  2. Changed1 schema field changed
    • addedInput schema / properties / calculation_id / description
      Added value: +"Id of a calculation, as upload_and_quote, quote_part or list_calculations return it."
  3. Added

TDQS

A4.4/5.0
Behavior4/5

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

Openness is largely covered by the readOnly/idempotent/non-destructive annotations, but the description still adds real context: the one-year-of-demand cap on the search space, and that it returns at most two recommendations. 'Read-only and free' is mild repetition of the annotations, keeping it from a 5.

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?

Front-loaded with purpose, then usage, then the return payload in one dense paragraph with zero filler sentences. The return-value enumeration is slightly redundant given an output schema exists, but it is compact and useful for triage.

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?

For a one-parameter, read-only analytical tool with an output schema and full annotations, the description supplies everything needed: the cost model, the search constraint, when to call it versus preview_cost, and what the answer contains.

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

Parameters3/5

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

The single parameter has full schema coverage and the schema already explains where calculation_id comes from, so the description is correctly not spending words on it. It adds domain framing (the optimization is scoped to the calculation) but no parameter-level detail beyond the schema.

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?

States a specific verb and objective ('find the lot size with the lowest total cost') plus the exact cost model (production + holding/capital tie-up + storage) and the cap of one year of demand. It also names the sibling preview_cost as the different tool, so an agent can distinguish them without reading schemas.

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

Usage Guidelines5/5

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

Gives a concrete use case ('answer how many parts to make per batch') and an explicit routing rule: 'To price one other lot size exactly, use preview_cost.' The boundary between optimizing and previewing is unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.