Skip to main content
Glama

step2gcode

upload_file_content

Upload a CAD file by writing its content out yourself. Use this only when a direct curl upload to /api/upload is not possible - that route costs you no output at all. If you must use this tool, ALWAYS compress first and pass the output as content: (xz -9e -c model.step 2>/dev/null || gzip -9c model.step) | base64 | tr -d '\n' xz writes about a quarter less than gzip; the command falls back to gzip where xz is missing (macOS). xz, bzip2 and gzip are recognised by themselves - no extra argument.

Do not paste the raw file. You have to write out every character you pass here, and a typical STEP solid takes you three minutes raw against twenty seconds compressed - the user watches that happen. Compression shrinks it about fivefold, which brings files up to roughly 80 KB within reach.

NO SHELL AVAILABLE? Then do not use this tool for anything above about 10 KB - you would have to type the whole file out and the user waits minutes for it. Call create_upload_link instead: the user drops the file in a browser and it is done in five seconds. Same if the file is still too large after compressing. Free.

NEXT STEP - do not generate yet. Ask the user:

  1. Which material? Offer the presets (wood, hardwood, plywood, acrylic, aluminum, steel, brass). If theirs is not among them, pick the closest preset AND set spindle_speed, feed_rate, plunge_rate and step_down yourself from known cutting data for that material and cutter.

  2. Which cutter diameters do they actually own? Recommend one from that list: it must fit the smallest inner radius of the part, and a smaller cutter means longer machining time. If you cannot judge the geometry yet, say so and suggest generating once to see the dimensions.

  3. Is the part cut all the way through? Then recommend holding_tabs so it does not come loose on the last pass.

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": {
      "filename": "<filename>",
      "content": "<content>"
    },
    "name": "upload_file_content"
  }
}

Input Schema

NameRequiredDescriptionDefault
contentYesOutput of: (xz -9e -c model.step 2>/dev/null || gzip -9c model.step) | base64 | tr -d '\n' - the compressed file, base64 encoded (xz, bzip2 or gzip, detected by itself).
filenameYesFile name including extension, e.g. bracket.step

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already establish that this is a non-read-only, non-idempotent upload. The description adds substantial operational context beyond them: token/output cost, the need to compress and base64-encode, supported codecs, size ceilings, and fallback alternatives. It does not describe the upload response or whether files can be overwritten, but the main behavioral burden is covered.

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?

The upload guidance is front-loaded and well-organized, but the description then appends unrelated downstream workflow instructions about choosing material, cutter diameters, and holding tabs. The cost explanation is also repeated in several forms, making the definition longer than necessary for this tool.

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

Completeness4/5

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

For a two-parameter upload tool with annotations and full schema coverage, the definition is largely complete: it covers cost, compression, size limits, and alternatives. It could better explain what upload returns or how failures are reported, and the next-step generation questions dilute the scope.

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 schema already documents both filename and content. The description still adds useful meaning: content must be compressed and base64-encoded, xz/bzip2/gzip are auto-detected, and raw pasting is discouraged for cost reasons.

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 action and resource: "Upload a CAD file by writing its content out yourself." It clearly distinguishes this from a direct curl upload to /api/upload and from create_upload_link, so an agent can tell the three routes apart.

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 explicit when-to-use and when-not-to-use guidance: only when direct curl upload is impossible, and not for files above roughly 10 KB when no shell is available. It names the alternative create_upload_link and the condition that selects it.

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