Skip to main content
Glama

step2gcode

check_upload

Read-onlyIdempotent

Check whether the user finished the browser upload. Returns the file_id once ready. 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": {
      "upload_id": "<upload_id>"
    },
    "name": "check_upload"
  }
}

Input Schema

NameRequiredDescriptionDefault
upload_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already establish that this is a read-only, idempotent, non-destructive check. The description adds useful behavior beyond annotations by saying it returns the file_id once ready and that the call is free. It does not explain the pending or failure response, but the core behavioral trait is disclosed.

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

Conciseness2/5

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

The first two sentences are concise and front-loaded, but the large 'NEXT STEP' block is mostly irrelevant to check_upload and belongs with a generation or material-selection tool. Those three numbered questions dominate the definition without helping the agent invoke this specific tool correctly.

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?

For a simple read-only polling tool with one parameter and annotations covering safety, the definition says enough to understand the basic contract. However, it omits the meaning of upload_id and the expected state when the upload is not yet complete. The lengthy next-step workflow text is not relevant to completing this tool call.

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 schema has one required upload_id with 0% description coverage, so the description should compensate. It never mentions upload_id or explains where the identifier comes from, only referring generically to the browser upload. This leaves the sole parameter semantically underspecified.

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?

The first two sentences clearly state a specific verb and resource: check whether the user finished the browser upload and return a file_id when ready. This distinguishes it from siblings like create_upload_link and generate_gcode. The remaining workflow text dilutes the purpose but does not obscure the core operation.

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 definition implies usage after a browser upload and explicitly says 'do not generate yet', which gives some routing context against generate_gcode. However, it does not say when to poll this tool, how often to retry, or how it relates to upload_file_content or get_job_status. The numbered 'NEXT STEP' items concern downstream material and cutter decisions, not when to invoke check_upload.

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