Skip to main content
Glama
KD5RYN

b123d-print-mcp

by KD5RYN

trace_outline

Trace a flat object from a scan or photo into a 2D outline in mm, including holes and scaling, for a part script. Use the confirmation image to verify the result before exporting.

Instructions

Trace a flat object in a scan or photo (parts//ref/, from upload_reference) into a 2D outline in mm for a part script: the largest object's outline and its holes, simplified to tolerance mm (few points: dense polylines build slowly), or with smooth=True through-points for a periodic spline. Scale, one of: dpi (a flatbed scan; omit everything to read it from the file), grid (cell size in mm of a grid or cutting mat under the object), reference ('card' = a credit card 85.60 x 53.98 mm beside the object, or 'L,S' mm of another rectangle), or points ('x1,y1,x2,y2' pixels, origin top left) with distance (mm between them). pick: 'x,y' pixel inside the object to trace when it is not the largest. threshold (0..1) and invert (object lighter than the background) override the automatic threshold. Writes out/docs/_outline.json (the points), out/docs/_outline.py (a snippet with OUTLINE, OUTLINE_HOLES and a face function) and out/images/_trace.png (the outline on the image: show it to the user to confirm). A scan is accurate to about a pixel; a photo only as far as it is square-on, flat and undistorted: check a known dimension before trusting it. 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
dpiNo
fileYes
gridNo
partYes
pickNo
inlineNo
invertNo
pointsNo
smoothNo
distanceNo
referenceNo
thresholdNo
toleranceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.12

TDQS

A4.7/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: it names the three written artefacts (json, py snippet, png), discloses accuracy limits (about a pixel for scans, photo only if square-on/flat), and explains remote-server behavior (temporary working copy deleted when unused, use download_part, no ssh/scp/shell). That is behavior beyond anything structured.

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?

Purpose and output are front-loaded, then scale modes, then outputs, then remote caveats. Dense but nearly every sentence carries information; the middle section is a long run-on that packs several parameters per clause, which slows parsing.

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 13-parameter tool with no annotations and no output schema, the description covers inputs, generated files, accuracy caveats and remote file handling. The main gap is the unexplained `inline` flag (default true), which likely governs whether the result is returned to the agent, and no statement of the immediate return value.

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 0%, and the description compensates by defining most parameters: dpi, grid (cell size mm), reference formats, points syntax and origin, distance, pick 'x,y', threshold range 0..1, invert direction, tolerance in mm, smooth. Only `inline` (and to a lesser degree `part`/`file` beyond path shape) is left unexplained, so it falls just short of complete.

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+output: tracing a flat object in a scan/photo into a 2D outline in mm for a part script, with the source path pattern parts/<part>/ref/<file>. This clearly separates it from siblings such as measure, render_preview or upload_reference.

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 conditional selection rules: omit everything for dpi from file, use grid for a mat, reference 'card' or 'L,S', points+distance for pixel calibration, pick when the object is not the largest, threshold/invert to override automatic threshold. Also states the precondition (from upload_reference) and a verification step (check a known dimension before trusting).

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