MOACUT 2D Nesting

Calculate a sheet cutting layout

calculate_nesting

Read-onlyIdempotent

Lay out rectangular parts on rectangular sheets and return how many sheets are needed, the scrap percentage, the largest reusable offcut, each part's position on each sheet, and a link that opens the job in MOACUT. Sizes in millimetres. Free limit: 10 part types and 30 pieces in total. Sheet counts are correct only for the whole job in one call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sheetWidth": "<sheetWidth>",
      "sheetHeight": "<sheetHeight>",
      "parts": "<parts>"
    },
    "name": "calculate_nesting"
  }
}

Input Schema

Name	Required	Description
`kerf`	No	Cut width between parts in mm (default 3)
`parts`	Yes	Part types to cut
`language`	No	Language of the MOACUT page the link opens (default en)
`edgeMargin`	No	Clear margin around each sheet in mm (default 10)
`sheetWidth`	Yes	Sheet width in mm, e.g. 2440
`sheetHeight`	Yes	Sheet height in mm, e.g. 1220
`allowRotation`	No	Allow parts to turn 90 degrees. Set false when the grain direction matters (default true)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the free-tier quota, the unit convention, the single-call accuracy constraint, and the fact that a MOACUT link is returned. It does not mention rate limits or what happens when the quota is exceeded, which keeps it short of 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?

Three sentences, front-loaded with the core action and its return values, then units, quota, and the accuracy caveat. Every sentence carries information, though the output enumeration is dense and slightly list-like rather than structured.

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 seven-parameter calculation tool with no output schema, the description is complete: it tells the agent what the tool computes, what it returns, the unit system, the quota, and the single-call constraint that affects correctness. Nothing an agent needs in order to call this correctly is missing.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline would be 3, but the description still adds meaning the schema lacks: it fixes the unit as millimetres for all sizes and explains the practical consequence of submitting a job in pieces. It also frames the output fields (scrap percentage, reusable offcut) that the parameters drive, going beyond restating parameter names.

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 names a specific verb and resource (lay out rectangular parts on rectangular sheets) and enumerates the concrete outputs: sheet count, scrap percentage, largest reusable offcut, per-part positions, and a MOACUT link. That is far more specific than the title, and an agent immediately knows what it gets back.

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 operating context: sizes are in millimetres, the free tier caps at 10 part types and 30 pieces, and crucially it warns that sheet counts are correct only when the whole job is submitted in one call. There are no sibling tools to differentiate from, so explicit when-not-to-use guidance is not applicable, but the one-call constraint functions as an important usage rule.

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

All MOACUT 2D Nesting tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?