Skip to main content
Glama

Edit the part at marks

apply_marks
Destructive

Apply remove, smooth, and add edits to a finished STL at Refine-page marks, writing an edited mesh and report to a new folder without rerunning finite-element analysis.

Instructions

Edit the finished part at the marks of the Refine page, in a NEW folder: facts and options, no verdict.

The run folder and final.stl stay as they are. No FE run is made: the stiffness and stress of the edited part are not known. Order: remove, then smooth, then add. A step that gives a part that is not closed, or that splits it, is rolled back, and the reply says why. The fixed, load and keep-out regions are frozen: an edit within frozen_keep_mm of them is clipped, and the clip is a fact. Reply keys: resource topopt://replies/apply_marks (the meaning of each key). marks: the path of marks.json (the Refine page exports it: version 1, mm, the frame of final.stl), its JSON text, or the marks object. radius_mm, amount_mm (the neck offset of add), strength (smooth) and mirror are used; a value that the page does not record is the pipeline value, named in defaults_used. A mark may carry smooth_mode or remove_mode (cleanup_list writes them); the order is per_mark, the mark, then the call option. run_dir: the run the marks belong to. Default: the last run of this server. Needs run.json, labels.bin and result/final.stl. out_dir: the new folder. Default: -marks beside the run folder. It gets edited.stl and apply_marks.json (the full report). Refused: a run folder or a folder inside one, a folder that holds an input file of the run, a symbolic link, a folder with files that is not an earlier apply_marks folder. allow_stale: apply the marks when source_sha256 of the marks file is not the hash of final.stl. Default: the reply states the fact (marks_match_final_stl false) and nothing changes. options: radius_scale (1.0), pitch_mm (node spacing of the crop box; default voxel size / 4, between 0.2 and 0.5), max_crop_voxels (8 million, a guard: above it the reply gives the facts and the options, e.g. pitch_mm). overwrite: write again into an earlier apply_marks folder. detail: the full report in the reply. Default: a short reply; apply_marks.json has the full report. yaml_path: the YAML of the run when run.json names a file that is not there; used for the exact frozen-region check. CONTRACTS.md section 29. Each mark is one local edit of result/final.stl on a signed distance field in a crop box around the mark, with the method of the pipeline stage s7_cleanup: remove = a cut that protects the parent (then the parent check), add = a closing with a ball (a neck offset when the closing adds little), smooth = an isotropic fairing for a point and a web fairing for a stroke (smooth_mode tube rebuilds a whole strut: it does not use radius_mm, and the reply gives its planned volume and reach). The new surface is spliced into the mesh in a zone around the edit; the triangles outside the zones stay bit for bit. More keys of options: max_total_voxels, frozen_keep_mm (3), frozen_full_mm (6), close_mm (3), neck_min_mm3, parent_tol_mm (0.2), parent_check ("report" or "enforce"), smooth_mode ("auto", "tube", "iso", "fair"), remove_mode ("cut" or "shave"), mirror_plane ({axis, at_mm}; else the plane of the mark or of run.json, else y = 0), skip ([mark ids]), per_mark ({id: {radius_mm, amount_mm, strength, mirror, smooth_mode, remove_mode, skip}}), check_frozen_exact, loose_body_mm3, max_odd_rays.

Input Schema

NameRequiredDescriptionDefault
marksYes
detailNo
optionsNo
out_dirNo
run_dirNo
overwriteNo
yaml_pathNo
allow_staleNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false; the description then adds substantial behavior beyond that: invalid steps are rolled back with a stated reason, edits inside frozen_keep_mm are clipped and the clip is reported as a fact, splicing leaves triangles outside the edit zones bit-for-bit unchanged, allow_stale defaults to a no-op that only reports marks_match_final_stl false, and overwrite is required to reuse an earlier output folder. It also states that final.stl and the run folder are untouched, which is exactly the safety context the agent needs.

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 first sentence front-loads the essential constraint (edit at marks, new folder, no verdict) and the reply-resource pointer is a useful shortcut. However, the body is a dense ~450-word block that interleaves parameter documentation with s7_cleanup method internals (closing balls, isotropic fairing, web fairing, tube rebuilds) in long parenthetical chains, making it hard for an agent to scan for the fields it needs. Every idea is relevant, but the packing and ordering cost readability.

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?

With no output schema, the description must convey return behavior, and it does: it names the artifacts written (edited.stl, apply_marks.json), what the short vs detail reply contains, the reply resource topopt://replies/apply_marks for key meanings, and specific reply facts such as defaults_used, marks_match_final_stl, clip facts, and rollback reasons. It does not fully describe the shape of a successful short reply or the planned-volume/reach fields for tube smoothing, so a 4.

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%, so the description carries the entire burden, and it does document all 8 parameters: marks (path, JSON text, or object; version 1, mm, frame of final.stl), run_dir defaulting to the last run with its required files, out_dir default and its refusal cases, overwrite, detail, allow_stale, yaml_path. The options object is expanded with defaults (radius_scale 1.0, pitch_mm bounds, max_crop_voxels, frozen_keep_mm 3, parent_check modes, smooth_mode/remove_mode enums, per_mark precedence). Several option keys (max_total_voxels, close_mm, neck_min_mm3, parent_tol_mm, loose_body_mm3, max_odd_rays) are listed without meaning, which keeps this from a 5.

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?

States a specific verb and resource: edit the finished part at the marks of the Refine page, into a NEW folder. It also draws a boundary against FE-oriented siblings ("No FE run is made") and names cleanup_list as the producer of marks, so the agent can place it in the workflow. It stops short of naming the sibling to use instead of this one, so not a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"No FE run is made: the stiffness and stress of the edited part are not known" tells the agent when this tool is and is not appropriate (i.e. it is not a substitute for run_topopt). It gives the step order (remove, then smooth, then add) and the refusal conditions for out_dir, which is usable guidance. There is no explicit "use this when X, use sibling Y instead" routing sentence, so a 4 rather than a 5.

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