Skip to main content
Glama
loumalouomega

Kratos MCP Server

mesh_remesh

Adaptively remesh .mdpa meshes with MMG via level-set, Hessian, or uniform sizing, then write a new .mdpa while preserving boundaries and reporting field transfer error.

Instructions

Adaptively remesh a .mdpa with MMG (MeshingApplication) and write a new .mdpa; returns before/after mesh summaries, a boundary preservation check and the field transfer error. Needs KratosMeshingApplication built with MMG (see kratos_install). Strategies: 'levelset' refines around a signed distance given as 'region' ({"type": "sphere", "center": [x, y], "radius": r} or {"type": "box", "min": [...], "max": [...]}; "mode": "inside" (default, the whole region gets min_size) or "surface") or as 'distance_expression' in x, y, z; 'hessian' adapts to the second derivatives of the analytic nodal field field_expression stored in the Kratos scalar variable field_variable; 'uniform' remeshes to the single element size min_size. Sizes default to max_size = mean input element size, min_size = max_size/4; the size grows from min_size to max_size over transition_distance (default 3max_size). preserve_sub_model_parts (default: every part with conditions) are checked to keep their conditions and node bounding box; freeze_sub_model_parts additionally forbids MMG from touching their nodes. check_fields ([{"variable": "TEMPERATURE", "expression": "x + 2y"}]) assigns analytic nodal values before remeshing and reports how well the interpolation reproduces them on the new nodes. Elements must be linear simplices (triangles or tetrahedra, not mixed; quads, hexes and quadratic cells are refused up front - convert with mdpa_convert_cells first). The result reports mesh_kind: planar2d (the verified path), volume3d (tetrahedra) or surface3d (triangles spanning z); the 3D kinds are wired to MmgProcess3D / MmgProcess3DSurfaces but not verified against reference numbers, which a warnings entry says. For 'hessian', interpolation_error (default 0.04) is the target P1 interpolation error - smaller means finer. A metric computed on a coarse mesh under-resolves a sharp feature: passes=3 repeats remeshing on the previous result (the analytic field is re-evaluated on every new mesh), which on the worked example halves the interpolation error at the same element count. Instead of field_expression, 'hessian' can adapt to a SOLVED field: field_results is a result-index.json (a job's results index; pick the record with field_time or field_step, default the last one) or a single ASCII .vtk/.vtu file whose point data holds field_variable on exactly this mesh's nodes (matched by coordinates). The transferred field is written to the output .mdpa as a 'Begin NodalData' block and carried between passes. Existing output is only replaced with overwrite=true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
passesNo
regionNo
timeoutNo
max_sizeNo
min_sizeNo
strategyNolevelset
overwriteNo
field_stepNo
field_timeNo
input_mdpaYes
output_mdpaYes
applicationsNo
check_fieldsNo
field_seriesNo
field_resultsNo
field_variableNo
field_expressionNo
distance_expressionNo
interpolation_errorNo
transition_distanceNo
freeze_sub_model_partsNo
preserve_sub_model_partsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full disclosure burden and does so thoroughly: it states the external dependency (KratosMeshingApplication built with MMG, see kratos_install), the overwrite semantics ('existing output is only replaced with overwrite=true'), the write-back behavior (NodalData block carried between passes), element-type refusals, and an explicit warning that 3D paths are wired but not verified against reference numbers.

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 core action is front-loaded and virtually every sentence carries functional information rather than filler, which justifies the length for a 22-parameter tool. However it is delivered as one undifferentiated block with no grouping or bullets, making the dense strategy/size/field material harder to scan than it needs to be.

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?

Given the tool's complexity, absent annotations, and 0% schema coverage, the description covers the safety profile, prerequisites, strategy selection, result content, and warning surface. An output schema exists, yet the description still usefully flags the reported fields and warnings, so an agent has everything needed to call it 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?

With 0% schema description coverage, the description must supply all parameter meaning, and it defines most of them richly (region object shape with mode, distance_expression, field_expression/field_variable, size defaults and transition_distance, preserve/freeze sub-model parts, check_fields, passes, interpolation_error, field_results selection). It leaves a few parameters unaddressed, notably timeout, applications, and field_series, which remain opaque.

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 first sentence names a specific verb+resource ('Adaptively remesh a .mdpa with MMG') and states the output ('write a new .mdpa') plus what is returned (before/after summaries, boundary check, transfer error). This is clearly distinguishable from siblings like mesh_generate_gmsh (creation) or mdpa_convert_cells (conversion).

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 strong in-context guidance: element-type prerequisites with an explicit alternative ('convert with mdpa_convert_cells first'), and the conditions under which each strategy applies (levelset for signed distance, hessian for field curvature, uniform for a single size). It does not directly contrast itself with other mesh-producing siblings such as mesh_generate_gmsh or add_remeshing_process.

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