Skip to main content
Glama
chartergroup

topopt

by chartergroup
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Check a problem YAML

check_problem
Read-onlyIdempotent

Loads and voxelizes a topology optimization YAML before the optimizer run, returning facts, estimates, and warnings to catch input and solver issues early.

Instructions

Load and voxelize a problem YAML (no optimizer run; with settings.solver auto it runs the short self-test of gpu-mg in a child process, at most 60 s: seconds the first time on a device and driver, then the cached pass). Returns facts, estimates and warnings.

Use it before run_topopt, also for your own YAML and STLs. Read the facts and tell the user the numbers that matter. Resource topopt://levers: the key for a symptom of these facts, and the price of a try. yaml_path: the problem YAML (relative paths start at the work folder). Another solver: settings.solver (auto, cholesky, pardiso, amg, gpu-mg) or --solver of topopt run and check, not of run_topopt. For gpu-mg, settings.gpu_device (auto, a number from topopt check, or a part of the name). Warnings are facts; a warning that starts with "settings.solver is" (the solver cannot run here) means run_topopt will stop with the same message. A warning that starts with "fact: settings.iterations" says that the passes end before the last stage of settings.beta_schedule (a grey design): it gives the options (iterations, or the schedule scaled to the passes) and the measured price. It does not block the run. On a wrong input: {"ok": false, "error": ...}. Reply keys: resource topopt://replies/check_problem (the meaning of each key). A settings.perimeter_max_mm2 below the smallest possible perimeter gives {"ok": false, "error": ...} with the options. The reply key lost_force has, for each load case, the total force, the force on nodes that are also fixed (the solver drops it) and the lost percent. Key fine_pass: the voxel that the part needs (voxel_mm, one value; recommend; limiting: the feature that sets it, its thickness and the voxels across now and needed; and with recommend the fact line). run_topopt with fine_pass=true or fine_from runs a fine pass.

Input Schema

NameRequiredDescriptionDefault
yaml_pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.2/5.0
Behavior4/5

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

Adds substantial context beyond the readOnly/idempotent annotations: the auto-solver path spawns a child process for a self-test bounded at 60 s (longer the first time per device/driver, then cached), and it distinguishes blocking warnings ('settings.solver is' → run_topopt will stop) from non-blocking ones ('fact: settings.iterations' → grey design, not blocking). Error shape on bad input is disclosed. The account of caching and child-process cost is slightly garbled, so not a clean 5.

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?

Front-loaded with the core action, which is good, but the body sprawls across loosely related topics (solver selection, warning prefixes, reply keys, fine_pass internals) with at least one malformed sentence ('seconds the first time on a device and driver'). Length is partly justified by the tool's complexity, but the structure does not help an agent scan it.

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?

No output schema, and the description does cover the return shape at a high level (facts, estimates, warnings; ok:false + error), plus specific keys it knows matter (lost_force, fine_pass). It delegates full reply-key meaning to topopt://replies/check_problem, which is a reasonable pointer but leaves the description alone insufficient for interpreting the payload.

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?

The single parameter has 0% schema description coverage, but the description supplies the semantics that matter: yaml_path is the problem YAML and relative paths resolve against the work folder. That is exactly the ambiguity an agent would otherwise hit. The surrounding solver/GPU settings discussed are YAML keys, not parameters, which adds a bit of noise.

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 chain and resource: 'Load and voxelize a problem YAML', and immediately scopes it with 'no optimizer run'. The sibling boundary with run_topopt is drawn explicitly ('Use it before run_topopt'), so an agent can pick between validating and running without opening a schema.

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 workflow placement: call it before run_topopt, and it is also valid for the user's own YAML and STLs. It clarifies that settings.solver is not a run_topopt parameter, which prevents a real misuse. No explicit 'do not use when' case is stated, keeping it below a 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