Skip to main content
Glama
chartergroup

topopt

by chartergroup
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Save user preferences

save_preferences
DestructiveIdempotent

Stores user answers for print bed, material, filaments, quality, and outputs in topopt-preferences.yaml so later topopt runs reuse the same setup.

Instructions

Keep the answers of the user (print bed, material, filaments, quality, outputs) for the next runs, in topopt-preferences.yaml in the work folder. It writes only that file.

Use it once, after the user answered. environment shows the file in preferences. The server reads the file at each call. A preference does not change a run by itself: run_topopt and check_problem fill nothing. build_regions takes a material, print or settings.voxel_size that the spec does not have at all, writes it into the YAML and says so in preferences_facts; a block that the spec gives, also a part of one, stays as it is. check_problem names a difference in preferences_facts. Sections (each optional; checked like the problem YAML):

  • print: printer_model (a name or id from find_printer; it gives the bed and type unless the YAML does), printer_type (fdm, sla, lpbf, sls), bed_mm (one number or [x, y] in mm), build_direction (+x to -z, or 3 numbers), self_supporting_angle_deg. A print limit (min_wall_mm) belongs to one part: it is refused.

  • material: E (MPa), nu, density (g/cm3), filament (from find_material; gives E and density), name (free text, for example "PETG").

  • filaments: available (names or ids of the filaments the user has).

  • quality: voxel_size (mm).

  • outputs: renders (render_part), step (export_step), verify (verify_run). The STL and the part card are made in every run. [] is none of the three. A section you do not give stays; one you give is merged key by key: a key with null is removed, and {} removes the section (outputs too). An unknown key stays in the file. With no section it makes an empty file if none exists (the user kept the defaults). Returns: ok, path, values, changed, created, kept_not_used, problems, note. A wrong name, key or value gives {"ok": false, "error": ...} with the key, the value and the rule; nothing is written. It refuses a file that is not valid YAML and a folder that cannot be written. There is no CLI command: edit the file.

Input Schema

NameRequiredDescriptionDefault
printNo
outputsNo
qualityNo
materialNo
filamentsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.4/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: key-by-key merge semantics, null removes a key, {} removes a section (outputs too), unknown keys persist, and calling with no section creates an empty file. It also discloses error behavior (wrong name/key/value returns ok:false and writes nothing; invalid YAML or unwritable folder is refused) and the return field list, which is consistent with destructiveHint=true.

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 the write-scope warning are front-loaded, and the length is justified by 0% schema coverage and five sections. Some lines are heavily telegraphic ('`run_topopt` and `check_problem` fill nothing'), which costs clarity at the margins.

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?

Covers inputs, merge/removal semantics, error cases, refusals and the return keys for a tool with no output schema and no parameter documentation. Minor gap: return fields such as kept_not_used and note are listed but not explained.

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 an untyped additionalProperties object, so the description carries the entire burden and does: it enumerates print (printer_model, printer_type, bed_mm, build_direction, self_supporting_angle_deg), material (E, nu, density, filament, name), filaments.available, quality.voxel_size, and outputs.renders/step/verify, including units and the rule that min_wall_mm is refused in print.

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: it keeps the user's answers (print bed, material, filaments, quality, outputs) in `topopt-preferences.yaml` in the work folder, and pins the scope with 'It writes only that file.' An agent can distinguish it from mutating siblings like save_printer/save_material by the fact that it persists per-user run defaults, though it never names those siblings explicitly.

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?

Gives clear timing ('Use it once, after the user answered') and a strong non-obvious caveat: a preference does not change a run by itself, since run_topopt/check_problem fill nothing and build_regions only takes a value the spec lacks. It also directs the agent to `environment` to inspect the file and notes there is no CLI equivalent. It stops short of explicitly naming the alternative save tools, so not a full 5.

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

Deploy Server

Other Tools