Skip to main content
Glama

step2gcode

get_step_download_link

Idempotent

Return the download link for a STEP file built by convert_mesh_to_step. THIS is the billed step: one credit per model not paid for yet. The DXF contour that comes with a 2.5D part belongs to the same part and costs nothing extra.

Called without confirm, this tool charges nothing and only reports what the download would cost. Show that to the user, wait for their answer, and only then call again with confirm=true. Never set confirm=true on your own initiative - it spends the user's money.

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": {
      "step_id": "<step_id>"
    },
    "name": "get_step_download_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
confirmNoSet to true only after the user has explicitly agreed to spend the credit.
step_idYesstep_id from convert_mesh_to_step

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false, idempotentHint=true, destructiveHint=false; the description adds the material behavior the annotations cannot express: one credit per model not yet paid for, the accompanying DXF contour is free, and a confirm-less call is a zero-cost quote. It does not cover link lifetime or whether re-calling after payment is charged again, so it is strong but not exhaustive.

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 the billing fact, then the procedural rule, then the caution — a sensible order for a paid tool. There is mild redundancy: the confirm warning is repeated in the closing sentence and again in the schema description, and the capitalized 'THIS' is stylistic noise.

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, no-output-schema tool that spends money, the definition covers cost model, dry-run semantics, user-consent requirement, and the free companion artifact. Remaining gaps are modest: the shape of the returned link (expiry, re-use) is left implicit and idempotency is only conveyed via annotations.

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 both parameters are already documented and the baseline is 3. The description still earns credit by explaining what confirm actually changes operationally (charge vs. dry-run quote) and by tying step_id to its source tool, which is more than the schema states.

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 (return the download link for a STEP file) and ties it to the producing tool, convert_mesh_to_step, so the agent knows exactly which artifact this addresses. It also immediately flags that this is the billed step, which is the distinguishing property versus the free sibling download link.

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 an explicit two-phase protocol: call without confirm to get a price report, show it to the user, wait for the answer, then call again with confirm=true. It also states a hard prohibition (never set confirm=true on your own initiative) and explains the consequence, which is exactly the when/when-not guidance an agent needs for a paid operation.

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