Skip to main content
Glama

CutOptim Engine

Optimize 1D bars

optimize_1d

Metered: one Engine API call. Cut lengths from bars, tubes, profiles or rolls and get the cutting pattern per bar. 1D / linear optimization (bars, profiles, tube). Cut parts of a given length from stock bars. Returns the rods used, the position of every part along each rod, the leftover length and the yield metrics.

Input Schema

NameRequiredDescriptionDefault
partsYes
stockYes
engineNo`max` is not offered here: it is a 2D (and, separately, nesting) tier, and `engine: "max"` on this path is a **400** before a call is charged. In 1D `balanced` resolves to the same packer as `heuristic` — the linear packer is already a best-of-multiple-strategies search, so there is no separate balanced mode. The value is accepted and echoed back so a single client can send one engine id for both endpoints.heuristic
includeNoThree kinds of token. NARROWING (`cutPlan`, `offcuts`): omit the field entirely to get both; a present array keeps only the narrowing tokens it lists (an empty array drops both). ADDITIVE EXPORT (`svg`, `csv`, `dxf`): each adds an inline export STRING to the response (`svg` a standalone 2D layout — 2D only, a warning is returned for 1D/wood; `dxf` an R12/AC1009 drawing; `csv` a cut list, RFC 4180 quoted (a part name with a comma or a quote stays one field) and formula-injection-guarded (a name beginning with `=`, `+`, `-`, `@`, TAB or CR is prefixed with an apostrophe so a spreadsheet reads it as text, not a formula — CWE-1236). 2D DATA (`labels`, `planHash`, `pdf`, `labelsPdf`): `labels` adds per-piece label data (`labels[]`, see `Label2D`), `planHash` a 64-hex fingerprint of the plan (the same plan always gives the same hash), `pdf` the cutting-plan PDF and `labelsPdf` the label PDF, both base64-encoded and drawn by the same code as the CutOptim app. These four are 2D only: a 1D or wood request returns a `warnings` entry instead. `pdf` renders at most 500 parts (total quantity); a larger 2D request with `pdf` is a 413 `too_large` with `details.path: "include"`. Export and data tokens do not affect narrowing, so `["svg"]` adds svg and — listing no narrowing token — drops cutPlan/offcuts; use `["cutPlan","offcuts","svg"]` to keep everything.
optionsNoThe 1D option set is deliberately smaller: there is no `firstCut`, `maxCutStages` or `minimizeRotations`, because none of them means anything on a bar.

Output Schema

NameRequiredDescriptionDefault
csvNo
dxfNo
rodsYes
engineYes
timingYes
cutPlanNo
metricsYes
unplacedYes
warningsYes
materialsNo
deterministicYes
engineVersionYes
contractVersionYes
unmatchedMaterialsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • addedInput schema / properties / options / properties / mitrePairing
      Added value: +{
      +  "default": false,
      +  "description": "Pair parts of one section whose facing ends (`parts[].ends`) can share ONE saw cut. Off by default: a request without it is solved exactly as before. On, a plan with pairs is returned only when it ranks strictly better than the unpaired plan by the packer's own ranking (parts placed first, then material — or price with `minimizeCost`); otherwise the unpaired plan comes back. Pairs only, no chains of three or more.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / parts / items / properties / depth
      Added value: +{
      +  "description": "Mitre pairing only: the side of the bar the `angle` of `ends` is seen on. Required with `ends` (a 1D part has no cross-section to take it from). Unit-agnostic: pick one unit (mm, inch, …) for every length in the request and every length in the response is in that same unit. Nothing is converted server-side.",
      +  "exclusiveMinimum": 0,
      +  "type": "number"
      +}
    • addedInput schema / properties / parts / items / properties / ends
      Added value: +{
      +  "description": "The angled ends of a part, read only with `options.mitrePairing`. Two parts of one section whose facing ends lie in one plane (after a turn `flip` allows) can be cut with ONE saw cut between them: the triangle between the long and the short point is not wasted. Without `mitrePairing` the ends are not used (a warning says so) and the part packs as its `length`.",
      +  "properties": {
      +    "end": {
      +      "description": "One end cut of a part, in degrees from square (0 = a square end), signed. The part is measured long point to long point (`length` is its overall length). A part whose two end cuts would cross inside its section (shorter than its leads) cannot be made: a 400 `invalid_request` naming `parts[i].ends` says how long it must at least be.",
      +      "properties": {
      +        "angle": {
      +          "description": "The face angle: the mitre or plumb cut as seen on the `depth` side (wood: on `sh` as entered).",
      +          "exclusiveMaximum": 90,
      +          "exclusiveMinimum": -90,
      +          "type": "number"
      +        },
      +        "bevel": {
      +          "default": 0,
      +          "description": "The edge angle: the bevel as seen on the `thickness` side (wood: on `sw` as entered). A compound cut has both.",
      +          "exclusiveMaximum": 90,
      +          "exclusiveMinimum": -90,
      +          "type": "number"
      +        }
      +      },
      +      "required": [
      +        "angle"
      +      ],
      +      "type": "object"
      +    },
      +    "start": {
      +      "description": "One end cut of a part, in degrees from square (0 = a square end), signed. The part is measured long point to long point (`length` is its overall length). A part whose two end cuts would cross inside its section (shorter than its leads) cannot be made: a 400 `invalid_request` naming `parts[i].ends` says how long it must at least be.",
      +      "properties": {
      +        "angle": {
      +          "description": "The face angle: the mitre or plumb cut as seen on the `depth` side (wood: on `sh` as entered).",
      +          "exclusiveMaximum": 90,
      +          "exclusiveMinimum": -90,
      +          "type": "number"
      +        },
      +        "bevel": {
      +          "default": 0,
      +          "description": "The edge angle: the bevel as seen on the `thickness` side (wood: on `sw` as entered). A compound cut has both.",
      +          "exclusiveMaximum": 90,
      +          "exclusiveMinimum": -90,
      +          "type": "number"
      +        }
      +      },
      +      "required": [
      +        "angle"
      +      ],
      +      "type": "object"
      +    }
      +  },
      +  "type": "object"
      +}
    • addedInput schema / properties / parts / items / properties / flip
      Added value: +{
      +  "default": "none",
      +  "description": "Mitre pairing only: which 180° turns of the part on the bar are allowed, so its angled end can meet a neighbour's. `none` (default — a profiled moulding or one-sided stock), `face` (end for end, the crown or top edge stays up — roof members), `edge` (end for end over the edge — flat stock, frames), `any`.",
      +  "enum": [
      +    "none",
      +    "face",
      +    "edge",
      +    "any"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / parts / items / properties / thickness
      Added value: +{
      +  "description": "Mitre pairing only: the other side, the one the `bevel` is seen on. Required with `ends`. Unit-agnostic: pick one unit (mm, inch, …) for every length in the request and every length in the response is in that same unit. Nothing is converted server-side.",
      +  "exclusiveMinimum": 0,
      +  "type": "number"
      +}
    • addedOutput schema / properties / cutPlan / items / properties / angle
      Added value: +{
      +  "type": "number"
      +}
    • addedOutput schema / properties / cutPlan / items / properties / bevel
      Added value: +{
      +  "type": "number"
      +}
    • addedOutput schema / properties / metrics / properties / sharedCuts
      Added value: +{
      +  "type": "integer"
      +}
    • addedOutput schema / properties / rods / items / properties / parts / items / properties / flipped
      Added value: +{
      +  "enum": [
      +    "face",
      +    "edge",
      +    "roll"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / rods / items / properties / parts / items / properties / sharedCut
      Added value: +{
      +  "properties": {
      +    "angle": {
      +      "type": "number"
      +    },
      +    "bevel": {
      +      "type": "number"
      +    },
      +    "kerfAlongAxis": {
      +      "type": "number"
      +    },
      +    "lead": {
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "angle",
      +    "bevel",
      +    "kerfAlongAxis",
      +    "lead"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

B3.3/5.0
Behavior4/5

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

Annotations only declare readOnly/destructive/idempotent/openWorld flags; the description adds the billing trait ('Metered: one Engine API call'), which an agent cannot infer from the schema, and summarizes the returned plan content. It does not cover failure behaviour (e.g. the 400 on engine 'max' or the 2000-qty cap) or any cost/rate nuance beyond 'one call'.

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

Conciseness3/5

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

Front-loaded with the metering note, which is good, but three of the four sentences restate the same idea: cut lengths from bars/tubes/profiles, 1D linear optimization, cut parts from stock bars. The redundant middle sentences crowd out the parameter and routing information that is actually missing.

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

Completeness3/5

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

An output schema exists, so the return-value sentence is somewhat redundant (positions, leftovers, yield are presumably in the schema), yet the description omits things this complex a tool needs: units are not converted server-side, the engine enum's 1D caveat, and the include-token behaviour. For a metered, 5-parameter, deeply nested tool it is adequate but thin.

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

Parameters2/5

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

The description names no parameter at all — not parts, stock, engine, include or options — even though schema description coverage is only 60% and the schema is heavily nested. An agent must read the schema to learn about material partitioning, unit-agnosticism, kerf/trim, mitrePairing and the narrowing-vs-additive include tokens; the prose contributes nothing here.

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

Purpose4/5

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

States a specific verb and resource: cut parts of given lengths from stock bars, tubes, profiles or rolls, returning the cutting pattern per bar. The '1D / linear optimization' framing clearly separates it from panel/nesting work, though it never names optimize_2d, optimize_nest or optimize_wood explicitly.

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

Usage Guidelines3/5

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

The opening 'Metered: one Engine API call' is genuinely useful usage context (calls cost money, so be deliberate), and 'Cut parts of a given length from stock bars' implies the domain. But there is no explicit when-to-use/when-not, no mention of validate_1d as the free pre-check, and no routing guidance among the eight sibling optimize/validate tools.

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.