Skip to main content
Glama
chartergroup

topopt

by chartergroup
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get the run result

run_result
Idempotent

Retrieve final mass, stiffness, run time, final.stl path, and optional text/mesh preview once a topology optimization run finishes.

Instructions

Get the final metrics, the path of final.stl and a text preview when the run is done.

Tell the user the result: mass, stiffness, run time. Units: mm, N, MPa, g. A run that a request to stop ended has no result: the reply is done: false and stopped: true with the pass.

run_dir: the run folder. Default: the last run that this server started. preview: add mesh facts and ASCII silhouettes of final.stl (for clients that cannot open files). render_part gives real images of the part. Reply keys: resource topopt://replies/run_result (the meaning of each key). A note names a wall thinner than the voxel size. The thinnest wall (thinnest_wall_mm) is the lower end of the film, not a value to use. The setting settings.part_only_min_film_mm (the wall thickness to cut off, in mm; default off) cuts off that thin film; then part_only also has min_film_mm, film_removed_mm3 and, for each body, thin_area_mm2, cut_area_mm2, thin_area_after_mm2 and the thinnest wall that stays. To apply it to a run that has finished: write the YAML with the value as a NEW file in the folder of the old YAML (region paths start there), then run_topopt with that YAML, the run folder as out_dir, resume=true and allow_changed_inputs=true (the post step repeats; copy the run folder first to keep the old result). Read the three areas and change the value if the film is still there. For a run with a stress limit, "met" of metrics.stress.cases.<case>.relaxed is the relaxed measure of the optimizer, not the stress of the part. summary and independent_check of the case give the P2 p99.9 of verify_run and its ratio to the limit when verify has run on the folder (read again at each call), else the option to run it.

Input Schema

NameRequiredDescriptionDefault
previewNo
run_dirNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.3/5.0
Behavior4/5

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

Rich disclosure beyond the annotations: stopped runs return `done: false` and `stopped: true`, verify-derived fields are re-read on every call, and reply key meanings live at topopt://replies/run_result. It does not explain why annotations mark this a non-read-only-but-idempotent operation, so the side effect implied by readOnlyHint=false goes unaddressed.

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?

Core purpose and units are front-loaded, which is good, but the body drifts into a multi-step recipe for re-running run_topopt with settings.part_only_min_film_mm, which is workflow guidance rather than this tool's contract. The telegraphic run-on phrasing makes the thin-film and stress paragraphs hard to parse on a first read.

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?

With no output schema, the description carries the full burden and meets it: shapes for successful and stopped runs, units, the key-documentation resource, thin-wall field semantics, and the distinction between relaxed optimizer stress and verifier P2 p99.9. An agent has enough to interpret the reply correctly.

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 must carry both parameters, and it largely does: run_dir is the run folder defaulting to the last run this server started, and preview adds mesh facts plus ASCII silhouettes. The run_dir path format (absolute vs relative to the YAML) is still not spelled out.

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?

States a specific verb and a concrete payload: final metrics, path of final.stl, and a text preview, gated on the run being done. It also names the sibling that does something different (render_part for real images) so an agent can separate the two without opening schemas.

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 conditions: call when the run is done, preview=true only for clients that cannot open files, render_part for actual images, verify_run for the independent stress check. It never explicitly contrasts with run_status, so the boundary between 'status' and 'result' is left to inference.

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