Skip to main content
Glama

step2gcode

generate_gcode

Start G-code generation for an uploaded file and wait for the result. Most jobs finish within the wait, so the answer usually already carries the part dimensions and hole diameters - no polling needed. Only if it says the job is still running, call get_job_status once after a few seconds. Free - only the download is charged.

BEFORE CALLING THIS, ask the user about the settings you cannot infer from the file. Two of them change the result substantially and are wrong by default more often than not:

  • material: drives spindle speed, feed rates and depth per pass. Aluminium cut with wood settings breaks cutters.

  • holding_tabs: without them a cut-out part comes loose on the last pass and can be thrown off the machine. Recommend them for any part cut all the way through. Also worth asking when the geometry suggests it: pockets and holes (STEP files carry that depth information), and whether the job is milling or laser work.

IMAGES (PNG, JPG, WebP ...) are always laser raster engraving. Ask for the engraving width in mm, photo or logo (image_mode), the controller (GRBL or Marlin) and its S maximum (laser_max_s), and tell the user to test power and speed on a scrap piece first.

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": {
      "file_id": "<file_id>"
    },
    "name": "generate_gcode"
  }
}

Input Schema

NameRequiredDescriptionDefault
depthNoCutting depth in mm; omit to take it from the model geometry (STEP)
holesNoDrill or mill the holes found in the geometry
laserNoLaser job instead of milling
file_idYesfile_id from check_upload or upload_file_content
pocketsNoMill pockets found in the geometry (STEP)
materialNoWorkpiece material. Sets spindle speed, feed rates and depth per pass. Ask the user - the default assumes softwood.
origin_zNoZ zero on the stock surface (top) or on the spoilboard. Default top.
feed_rateNoHorizontal feed in mm/min. Same rule: only for materials outside the presets.
origin_xyNoWorkpiece origin in XY. Default TL.
step_downNoDepth per pass in mm. Rule of thumb: up to 1x cutter diameter in softwood, far less in metal.
controllerNoLaser G-code dialect. GRBL (default) or Marlin (3D printers with a laser module, MPCNC/LowRider and other Marlin machines).
image_modeNoImages only. Line by line (raster): dither for photos (default), threshold for logos and text, grayscale for power per dot. Along lines (vector, much faster): outline traces the edges of dark areas, centerline follows the middle of strokes (line art, handwriting), edges turns a photo into a line drawing.
ramp_entryNoEnter the material on a ramp instead of plunging straight down
laser_max_sNoHighest S value of the machine: $30 on GRBL (usually 1000), 255 on most Marlin machines. Ask the user - a wrong value burns at the wrong power.
laser_powerNoLaser power in % (laser jobs). For images the default is 30 %.
laser_speedNoLaser speed in mm/min (laser jobs). For images the default is 2000.
plunge_rateNoPlunge feed in mm/min, for materials outside the presets.
bit_diameterNoCutter diameter in mm, e.g. 6. Leave it out and step2gcode picks the largest whole millimetre that still fits through the smallest hole in the part.
holding_tabsNoLeave small bridges so a part cut all the way through stays in the stock. Strongly recommended for through cuts.
spindle_speedNoSpindle speed in rpm. Only set this when the material is not covered by the presets - otherwise the preset value is used.
image_width_mmNoImages only: engraving width in mm; the height follows from the aspect ratio. Default 100.
inner_contoursNoCut inner contours and cut-outs

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say it is a non-readonly, non-idempotent job starter; the description adds the crucial traits: the call blocks and usually returns finished results with part dimensions and hole diameters, it is free with only downloads charged, and correct settings materially affect physical outcomes (broken cutters, thrown parts). That is substantial context an agent could not get from 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.

Conciseness4/5

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

Front-loaded with purpose and the polling rule before the longer pre-call guidance, and every section maps to a real decision. It is long and multi-paragraph, which is defensible for 22 parameters but slightly more than strictly needed.

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?

With 22 parameters and no output schema, the description still tells the agent what the response typically contains (dimensions and hole diameters) and what to do when it does not. Nothing needed to call it correctly — file_id provenance, blocking behavior, per-material questions — is 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?

Schema coverage is 100%, so the baseline is 3, but the description goes further by ranking which parameters actually change the result (material and holding_tabs), warning that defaults are wrong more often than not, and scoping image-only parameters (image_width_mm, image_mode, laser_max_s) to a file type. It does not add syntax beyond the schema for most other fields, so not a 5.

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 resource ('Start G-code generation for an uploaded file') plus the synchronous behavior ('wait for the result'), which immediately distinguishes it from the async sibling get_job_status.

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?

Explicitly says when not to poll ('Only if it says the job is still running, call get_job_status once after a few seconds') and gives a pre-call checklist of what to ask the user, including which defaults are commonly wrong (material, holding_tabs). It also branches by input type, treating images as always laser raster engraving with their own question set.

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.

Resources