Skip to main content
Glama

Turn marks into hints

marks_to_hints
Destructive

Converts Refine-page marks into facts, options, and a proposed YAML in a new folder without editing the mesh, so you can review and run topology optimization.

Instructions

Turn the marks of the Refine page into facts, options and a proposed YAML in a NEW folder. Edits no mesh.

A mark is a point of emphasis, not an absolute. The report gives, for each mark, the facts (position, radius, distance to the surface of final.stl, voxels touched, overlap with the design, fixed, load and keep-out regions, whether the region touches the material of final.stl) and the options for its type, and says which option the proposed YAML uses. The agent decides: read the report, change options and call again, edit the YAML, or run it with run_topopt. The tool writes only into the new folder. It refuses an out_dir that is a run folder or inside one, one that holds an input file of the run (the folder of the YAML or of a region STL), a symbolic link, and a folder with files that is not an earlier hints folder; the reply names the fact and the options. After it: check the report, then run_topopt with the proposed YAML and a new out_dir, then compare_runs. Reply keys: resource topopt://replies/marks_to_hints (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 ("Copy JSON" on the page) or the marks object. run_dir: the run the marks belong to. Default: the last run of this server. Needs run.json and the YAML it names. out_dir: the new folder. Default: -hints beside the run folder. It holds the proposed YAML (the YAML of the run, with the changes), the region STLs (the originals are copied, the hints are new) and hints.json (the full report; its paths are relative to the folder). detail: the full report in the reply (about 1.5 KB for each mark). Default: a short reply; hints.json has the full report. options: remove ("keep_out" or "skip"), add ("solid" or "skip"), radius_scale (default 1.0; 0.5 gives smaller regions), protect_regions (default true: fixed and load regions are cut out of a keep-out hint), clip_to_design (default true: a solid hint is cut to the design space), per_mark ({mark id: option}). overwrite: write again into a folder that holds an earlier hints.json. yaml_path: the YAML of the run, when run.json names a file that is not there (a moved run). The labels check in the report says if it fits the run. The input YAML, the run folder and the region STLs of the run stay as they are; the new region STLs touch the grid only inside the box of the input regions. Mapping in this version: remove -> a keep-out STL (sphere, or capsule chain for a stroke) of radius radius_mm x radius_scale; add -> a forced-solid region (a load region that no load case uses); smooth -> facts and options only, because the YAML has no key that smooths one place. mirror repeats the mark at y -> -y. normals, amount_mm, strength and note are not used. The marks are read in file order and the first mark wins an overlap: a later hint region is cut by the earlier ones (a mark inside an earlier one has status no_effect, with the reason).

Input Schema

NameRequiredDescriptionDefault
marksYes
detailNo
optionsNo
out_dirNo
run_dirNo
overwriteNo
yaml_pathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.7/5.0
Behavior5/5

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

The annotations already declare a non-idempotent, destructive write operation, and the description adds substantial context beyond that: it writes only into a new folder, refuses specific out_dir locations, copies original region STLs, leaves the input YAML/run/region STLs unchanged, and documents overwrite behavior. It also explains overlap handling, file-order precedence, and which mark fields are ignored.

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?

The description is front-loaded with the core action and scope, then proceeds through behavior, workflow, reply keys, parameters, and mapping in a logical order. It is long and dense, but most of the length is justified by seven undocumented parameters and complex refusal/default behavior. Some sentences could be tightened, but the structure is appropriate for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain return behavior, and it does: it identifies reply keys via `topopt://replies/marks_to_hints`, describes `detail` versus `hints.json`, and explains that invalid out_dir replies name the offending fact and options. Combined with the parameter semantics and safety constraints, an agent has enough context to call and interpret the tool correctly.

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?

With 0% schema description coverage, the description fully compensates by documenting all seven parameters: accepted forms for `marks`, run resolution for `run_dir`, default and contents of `out_dir`, `detail`, nested `options` keys and defaults, `overwrite`, and fallback behavior for `yaml_path`. This adds essential meaning that the bare schema does not provide.

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?

The description states a specific verb and resource: it turns Refine-page marks into facts, options, and a proposed YAML in a new folder. It also explicitly scopes the operation as editing no mesh and distinguishes the output folder from the run, which lets an agent separate it from siblings such as apply_marks and run_topopt.

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?

It gives clear workflow guidance: after the call, check the report, then run_topopt with the proposed YAML and compare_runs. It also explains the agent can read the report, change `options` and call again, or edit the YAML. It does not explicitly name when to use this instead of `apply_marks` or other mark-related siblings, so it falls short of full when/when-not/alternatives coverage.

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