Skip to main content
Glama
KD5RYN

b123d-print-mcp

by KD5RYN

download_part

Retrieves a remote part's script, exports, renders, and reference models as one signed-link zip or SSH pull, so its files land on your machine in the standard parts// layout.

Instructions

Bring a whole part home from a remote server, in the same layout a local install writes: parts//.py, parts//out/ (exports, renders, sections) and parts//ref/ (reference models). Over HTTP: ONE signed link (no token needed, expires) to a zip of all of it; run curl -fLo <name>.zip '<link>' and unzip it in the project folder, then check the files are there. Over SSH: the b123d-print pull command that writes the same files. Locally (stdio): says where the files already are. variant: only that variant's out/ files ('standard' = ''); formats: only those out/ files (step, stl, 3mf, png, glb, print, hardware, bom, bom_csv); the script and ref/ always come. Over HTTP it also gives the 3D view links of the views export wrote (in a browser, no token). embed=True also puts the zip (up to 8 MB) into the result (over HTTP and SSH), for clients whose shell has no network (Antigravity/agy) or that can neither fetch URLs nor read resources: unzip it from where the client saved it. Call it as the last step of remote work, before reporting: a part is not done until its files are on the user's machine. Remote server (HTTP/SSH): the files stay on the server, as a temporary working copy deleted when unused; bring the part home with download_part (one zip in the parts// layout). Never use ssh, scp or a shell on the server: there is none.

Input Schema

NameRequiredDescriptionDefault
nameYes
embedNo
formatsNo
variantNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.12

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: signed link expiration, no token required, embed zip capped at 8 MB, and the fact that server-side files are a temporary working copy that gets deleted when unused. It also discloses what is always included (script and ref/) regardless of filters, which is behavior an agent cannot get from the schema.

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 outcome and layout, and nearly every sentence carries operational information. It is dense and mixes transport mechanics (a literal curl invocation) with routing advice, and the closing 'bring the part home with download_part' restates the opening, costing some scannability.

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 4-parameter tool with no annotations and no output schema, the description covers return locations, filtering behavior, embed fallback, and the temporary-copy lifecycle. It stops short of covering failure modes (e.g., part not found, expired link mid-download), which an agent would want before a terminal 'last step' call.

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 0% and every parameter is compensated: variant is defined ('standard' = ''), formats is enumerated with actual values (step, stl, 3mf, png, glb, print, hardware, bom, bom_csv) even though the schema has no enum, and embed is explained with both its 8 MB limit and its audience (clients with no network or that cannot fetch URLs).

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?

Opens with a specific verb + resource ('bring a whole part home from a remote server') and immediately states the exact output layout (parts/<name>/<name>.py, out/, ref/). It is clearly distinguishable from siblings like read_part, write_part or export, which operate on data rather than delivering a full file package.

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 states when to use it ('call it as the last step of remote work, before reporting: a part is not done until its files are on the user's machine') and when not to ('Never use ssh, scp or a shell on the server: there is none'). It also names the transport-specific alternatives (curl over HTTP, b123d-print pull over SSH, local stdio) rather than leaving the agent to infer them.

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