Kratos MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KRATOS_ROOT | No | Path to a compiled Kratos Multiphysics checkout |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| kratos_check_installationA | Check that Kratos Multiphysics is available and report version, paths, thread count and the list of compiled applications. |
| kratos_installA | Install Kratos Multiphysics via pip into this server's own Python environment -- a local compiled build (KRATOS_ROOT) is not required. Installs the 'KratosMultiphysics' core plus any named applications (e.g. ["StructuralMechanicsApplication", "ConvectionDiffusionApplication", "LinearSolversApplication"]); pass all=true instead for the 'KratosMultiphysics-all' omnibus package covering essentially every application. Official wheels are only published for Linux and Windows x86_64 -- there is no Kratos wheel for macOS, where a local KRATOS_ROOT build is still required. This can take several minutes and download hundreds of MB (KratosMultiphysics-all is the largest); prefer naming only the applications you need. Once it returns ok, Kratos is importable immediately -- no server restart needed. |
| kratos_list_applicationsA | List all Kratos applications found in the source tree, flagging which ones are compiled (importable) in the current build. |
| kratos_list_elementsA | List element type names registered in Kratos (parsed from KRATOS_REGISTER_ELEMENT macros in the C++ sources). Optionally filter by application name (e.g. 'StructuralMechanicsApplication') or by a substring of the element name (e.g. 'SmallDisplacement'). |
| kratos_list_conditionsA | List condition type names registered in Kratos (surface/line/point conditions used for loads and boundary terms), with optional filters as in kratos_list_elements. |
| kratos_list_constitutive_lawsA | List constitutive law names registered in Kratos (material models such as LinearElastic3DLaw or Newtonian2DLaw), with optional filters as in kratos_list_elements. |
| kratos_list_variablesA | List Kratos variables (DISPLACEMENT, TEMPERATURE, ...) grouped by type (double, array_1d_3, bool, ...), introspected from the live build. type_filter selects one group; name_filter is a substring. |
| kratos_get_variable_infoA | Look up specific Kratos variables by name in the live build: whether each exists and its type (double, array_1d_3, bool, int, vector, matrix, string, flags ...). Vector components such as DISPLACEMENT_X resolve to their array variable ('component_of'). Use it to check names before putting them in ProjectParameters (variable_name, output variables, nodal_solution_step_data_variables). |
| kratos_list_solversA | List the known solver_type values per analysis type (structural, thermal, fluid, potential_flow) together with the Python solver module implementing each, plus all *_solver.py modules found in the application source tree. |
| kratos_list_processesA | List Python process modules (boundary conditions, loads, output, utilities) discoverable in the Kratos source tree. These are the values usable as 'python_module' in ProjectParameters process lists. With with_defaults=true, each entry also carries the process' default_settings and param_types parsed from its source (best effort; modules whose defaults cannot be parsed are still listed without them). Use kratos_get_process_defaults for a single module's full schema. |
| kratos_get_process_defaultsA | Return a Kratos process' default settings -- parameter names, default values, coarse types (bool/number/string/array/json/null) and which parameters are model-part references -- parsed from its Python source' ValidateAndAssignDefaults block. This is the schema you need to author a process block in a ProjectParameters process list. python_module is a value from kratos_list_processes (e.g. 'assign_scalar_variable_process', 'vtk_output_process'). Returns {"error": ...} when the Kratos source is unavailable, the module is not found, or its defaults use a non-standard declaration. |
| kratos_get_solver_defaultsA | Return the complete default solver_settings parameters for a solver, as reported by its GetDefaultParameters(). analysis_type is one of structural/thermal/fluid/potential_flow; solver_type one of the values from kratos_list_solvers (e.g. 'Static', 'transient', 'Monolithic'). |
| list_templatesA | List the available case templates (structural_static, thermal_transient, fluid_transient, ...) with their descriptions, required applications and placeholder defaults. |
| create_project_parametersA | Generate a ProjectParameters.json from a template (see list_templates). overrides replaces placeholder defaults, e.g. {"end_time": 2.0, "fix_model_part": "Structure.left"}. When output_file is given the JSON is written there; the content is always returned. |
| list_material_presetsA | List the curated material presets usable as 'preset' in create_materials. Each carries a constitutive_law name and default Variables for a physical material model (linear elastic, Von Mises plasticity, isotropic damage, Newtonian fluid). Cross-check law names with kratos_list_constitutive_laws for your compiled build. |
| list_linear_solver_presetsA | List curated linear_solver_settings presets (serial: sparse_lu, skyline_lu, amgcl, cg, bicgstab; MPI/Trilinos: amgcl_mpi, amesos, aztec, ml). Each 'settings' block is a drop-in for solver_settings.linear_solver_settings in a ProjectParameters. |
| create_materialsA | Write a Kratos Materials.json. Each entry needs 'model_part_name' (e.g. 'Structure.domain'). Provide either a 'preset' (a name from list_material_presets, which fills constitutive_law + default variables) or an explicit 'constitutive_law' (e.g. 'LinearElasticPlaneStrain2DLaw') plus 'variables' (e.g. {"YOUNG_MODULUS": 2.1e11}). With a preset, any 'variables' you pass override the preset's defaults; 'constitutive_law' is optional (thermal problems have none). |
| create_projectA | Scaffold a complete Kratos case directory from a template: ProjectParameters.json + Materials.json (+ optionally a small demo rectangle mesh wired to the template defaults, so the case runs out of the box). Returns the created file paths and next steps. |
| create_multistage_projectA | Scaffold a Kratos multi-stage (orchestrated) case that chains several analyses in sequence, e.g. a continuation run or a coupled workflow where a later physics reads fields the earlier one wrote on the same mesh. Each element of 'stages' is {"name": "<stage_id>", "template": "", "overrides": {...}} (overrides optional). Stages are composed via Kratos' SequentialOrchestrator (orchestrator + stages + execution_list) and run with run_simulation like any case. Mesh sharing: the first stage imports its mesh (mdpa); a later stage whose solver model_part_name matches an earlier stage's REUSES that already-populated model part (input_type 'use_input_model_part'), which is how state flows between stages. A later stage with a distinct model_part_name imports its own mesh instead. |
| create_cosim_projectA | Scaffold a CoSimulation (coupled-solver) case: several solvers exchanging interface data inside every time step, run with run_simulation like any case (the runner drives it through CoSimulationAnalysis). Needs KratosCoSimulationApplication. 'solvers' is a list of {"name", "type", "data", "parameters"?, "input_file"?}. 'type' is a CoSimulation wrapper module ('solver_wrappers.kratos.structural_mechanics_wrapper', ...) or the shorthands 'sdof' / 'sdof_static' (Python-only single-degree-of-freedom solvers: no mesh, ideal for learning/testing couplings). 'data' maps an interface-data name to {"model_part_name", "variable_name", "location"?} ('sdof' data gets "location": "model_part" automatically). Give 'parameters' to have the solver's own parameter file written to .json, or 'input_file' to reference one already in the directory. 'couplings' is a list of {"from_solver", "from_data", "to_solver", "to_data", "operator"='copy', "options"=[]} (options e.g. 'swap_sign'). 'order' is the coupling sequence (default: solver order); a coupling whose producer comes first is exchanged right after the producer solves, otherwise right before the consumer solves (previous iteration's value). 'coupled_solver' is 'gauss_seidel_weak' (one pass per step) or a strong variant ('gauss_seidel_strong', 'jacobi_strong') that iterates until every entry of 'convergence_criteria' (e.g. {"type": "relative_norm_initial_residual", "solver": s, "data_name": d, "abs_tolerance": 1e-10, "rel_tolerance": 1e-8}) holds, optionally accelerated by 'convergence_accelerators' (e.g. {"type": "aitken", "solver": s, "data_name": d}). The result is statically validated. |
| create_fsi_projectA | Scaffold a partitioned fluid-structure interaction (FSI) case with Kratos' FSIApplication: a 2D channel [0,length]x[0,fluid_height] whose floor is an elastic block [0,length]x[-wall_thickness,0]. The fluid (monolithic Navier-Stokes, inlet velocity ramped over 'ramp_time', outlet pressure 0) loads the wall through the shared 'Interface'; the deformed wall moves the fluid mesh (ALE, mesh_solver_structural_similarity). Fluid and wall meshes are generated with DIFFERENT interface discretizations ('fluid_divisions' [nx, ny] triangles, 'wall_divisions' [nx, ny] quads), so the interface mapper does real work. Dirichlet- Neumann coupling is iterated each step until 'coupling_tolerance' using the convergence 'accelerator' (MVQN_recursive, MVQN, Relaxation = Aitken, constant_relaxation, ...). Writes ProjectParameters.json, fluid.mdpa, structure.mdpa, MaterialsFluid.json, MaterialsStructure.json and runs with run_simulation like any case. Needs FSIApplication, FluidDynamicsApplication, StructuralMechanicsApplication, MeshMovingApplication and MappingApplication. The defaults are a verified Stokes-like regime; the wall must be stiff enough relative to the fluid's added damping (roughly wall_thicknessviscositylength^2/(Efluid_height^3time_step) << 1) or the Dirichlet-Neumann iteration diverges. The result is statically validated. |
| add_boundary_conditionA | Insert a boundary condition / load process block into an existing ProjectParameters.json. kind is one of: fix_displacement, prescribed_displacement, fix_velocity, inlet_velocity, outlet_pressure, fix_temperature, point_load, line_load, surface_load, pressure_load, surface_heat_flux, volume_heat_source, self_weight, or the generic fix_scalar / assign_scalar / fix_vector / assign_vector (which need 'variable', e.g. DISTANCE). fix_* constrain the DOFs, assign_* only set the values. Loads with modulus+direction (point/line/surface_load, self_weight) apply along a direction vector; the others take 'value' (vector or scalar). 'variable' overrides the kind's default variable. For multi-stage (orchestrator) files pass 'stage'. Use project_add_process for any other Kratos process. |
| add_output_processA | Add an output process to a ProjectParameters.json. format: 'vtk' (ParaView files, needs output_path), 'json' (time series of variables to a JSON file, needs output_file), or 'point' (probe variables at a coordinate, needs position and output_file). variables defaults to the ones already used elsewhere in the file or ["DISPLACEMENT"]. |
| add_remeshing_processA | Add an MMG remeshing process (MeshingApplication's mmg_process) to a ProjectParameters.json so the mesh is adapted while the case runs. strategy 'hessian' adapts to the second derivatives of the nodal scalar solution variable 'variable' (e.g. TEMPERATURE); 'levelset' refines around the zero of the signed-distance variable 'variable' (its GRADIENT variable must exist in the model part, e.g. via the solver's auxiliary_variables_list). Without min_size/max_size the sizes are derived from the current mesh. The mesh is remeshed ONCE at setup, before the solver initializes (initial_remeshing); the field driving the metric must already be on the nodes then (an mdpa NodalData block): processes that assign values run later. Remeshing inside the solution loop crashes standard Kratos solvers and is not offered. Remeshing renumbers nodes and elements, so such cases are refused by studies, checkpoints/resume, MPI launch and interactive sessions. Use mesh_remesh to refine an .mdpa offline instead - same result, inspectable mesh. |
| validate_project_parametersA | Validate a ProjectParameters.json: JSON syntax, required keys, referenced files (mesh, materials) exist, model part names match the mesh submodelparts, and (deep=true, needs Kratos) the solver_settings against the solver's GetDefaultParameters(). |
| mdpa_inspectA | Inspect a Kratos .mdpa mesh file: node/element/condition counts by type, bounding box, property ids and the SubModelPart tree with entity counts. |
| mdpa_validateA | Validate a .mdpa file: dangling node/element/condition references and empty submodelparts (pure-Python lint). With deep=true the file is additionally round-tripped through the real Kratos ModelPartIO. |
| mdpa_create_structured_meshA | Generate a structured mesh and write it as .mdpa. kind: 'line' (size=[L], divisions=[n], submodelparts start/end), 'rectangle' (size=[W,H], divisions=[nx,ny], edge parts left/right/bottom/top, quads or triangles), or 'box' (size=[Lx,Ly,Lz], divisions=[nx,ny,nz], hexahedra, face parts xmin/xmax/ymin/ymax/zmin/zmax). All variants include a 'domain' submodelpart with every node and element; boundary parts carry conditions of condition_name for applying surface loads. Defaults: rectangle SmallDisplacementElement2D4N + LineLoadCondition2D2N, box SmallDisplacementElement3D8N + SurfaceLoadCondition3D4N. |
| mesh_remeshA | 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. |
| mdpa_get_nodesA | Return node ids and coordinates from a .mdpa file, optionally restricted to one submodelpart (dotted path like 'domain' or 'outer.inner') or an explicit id list. At most 'limit' nodes are returned (with a truncation flag). |
| mdpa_get_entitiesA | List elements, conditions or geometries of a .mdpa with their type, property id and node connectivity. kind: 'element' (default), 'condition' or 'geometry'. Filter by explicit ids, by entity_type (e.g. 'LineLoadCondition2D2N') and/or by sub_model_part (dotted path). At most 'limit' rows are returned, with the total count and a truncation flag. |
| mdpa_select_nodesA | Find nodes by geometry without changing anything. selector keys (combined as an intersection): ids, part (dotted SubModelPart), box {min:[x,y,z], max:[x,y,z]}, sphere {center, radius}, plane {point, normal} (nodes within 'tolerance' of the plane), expression (nodes where an expression in x, y, z is <= 0, e.g. 'xx + yy - 1.0' for a unit disc), tolerance (default 1e-9 x bounding-box diagonal), all=true. Returns the count, the first 'limit' ids and the bounding box of the selection. Pair with mdpa_create_sub_model_part to name the selection. |
| mdpa_add_nodesA | Add nodes ([x, y] or [x, y, z] each) to a .mdpa. Ids default to the next free ids; pass 'ids' to choose them. Optionally add them to an existing sub_model_part (dotted path). Edits in place unless 'output' is given. |
| mdpa_move_nodesA | Move nodes: either set absolute 'coordinates' (one [x, y, z] per node, in the order of node_ids) or shift every chosen node by 'offset'. Choose the nodes with node_ids or a selector (see mdpa_select_nodes). Elements keep their connectivity, so check the result with mdpa_quality. |
| mdpa_delete_nodesA | Delete nodes (by id list or selector). Nodes still used by elements, conditions or geometries are refused unless cascade=true, which deletes those entities too. They are removed from every sub model part and from nodal data. |
| mdpa_add_entitiesA | Add elements, conditions or geometries of one type. kind: 'element', 'condition' or 'geometry'. entity_type is the Kratos name (e.g. 'SmallDisplacementElement2D4N', 'LineLoadCondition2D2N', 'Line2D2'); its 2D3N/3D8N-style suffix fixes the node count. Each item of 'entities' is {"nodes": [ids...], "id": optional, "property_id": optional (default 1, not for geometries)}. With sub_model_part the new entities and their nodes join that part (and its ancestors). |
| mdpa_delete_entitiesB | Delete elements, conditions or geometries by id (kind: 'element', 'condition', 'geometry'), or every one that belongs to sub_model_part. They are removed from all sub model parts; nodes are kept. |
| mdpa_set_entity_propertiesB | Change the property id (which Materials.json entry applies) and/or the Kratos type name of elements or conditions (kind 'element'/'condition'; the new type must have the same node count). Choose entities by ids or by sub_model_part membership. |
| mdpa_create_sub_model_partA | Create a sub model part (dotted name such as 'Structure_left' or 'domain.fixed' for a child; the parent must exist) from node ids or a selector (see mdpa_select_nodes) plus optional explicit element / condition / geometry ids. include lists entity kinds ('element', 'condition', 'geometry') whose members lying entirely on the part's nodes are added automatically -- use ['condition'] for a load surface. Nodes of added entities join too, and ancestors receive everything. exist_ok=true extends an existing part instead of failing. |
| mdpa_edit_sub_model_partA | Edit an existing sub model part (dotted path). action: 'add' members (nodes via node_ids/selector, elements, conditions, geometries; ancestors receive them too), 'remove' members (also from descendants), 'rename' (needs new_name, a single word) or 'delete' (the whole part, its children included; the entities themselves stay in the mesh). |
| mdpa_transformA | Transform node coordinates (all nodes unless node_ids/selector is given). operation: 'translate' (vector), 'rotate' (angle in degrees about axis, default z, through origin), 'scale' (factors: one number or per axis, about origin) or 'mirror' (across the plane through point with normal). Mirror and negative scaling re-order the connectivity (including quadratic mid-edge and face nodes) so cells keep a positive measure. |
| mdpa_mergeA | Append the mesh in 'other' to the one in 'path' and write 'output' (the inputs are untouched). Ids of 'other' are shifted past the first mesh's; sub model parts with the same name are united (their data, table and property references too). Tables, elemental/conditional data and all nodal data are carried over (colliding table ids are shifted). With merge_tolerance, coincident nodes (e.g. along a shared interface) are merged afterwards, so two blocks transformed into place become one conforming mesh. Inputs with blocks the editor cannot represent (Constraints, ...) are still refused: inspect skipped_blocks first. |
| mdpa_renumberA | Renumber nodes, elements, conditions and geometries consecutively from 'start' (references in sub model parts and nodal data follow). Useful after deleting entities or merging meshes. |
| mdpa_extractB | Write the contents of one sub model part (dotted path) as a new .mdpa: its entities, the nodes they use, its children, and the part itself as the root part. The input is untouched. |
| mdpa_extrudeA | Extrude a planar (xy) mesh along z into a 3D mesh written to 'output'. heights are the layer thicknesses, e.g. [0.1] * 10 (z0 is the starting level). Triangles become prisms (3D6N), quads hexahedra (3D8N) and 2-node conditions surface quads (3D4N). Type names map '2DnN' -> '3DmN' unless overridden: element_names / condition_names map old -> new name (e.g. {"LineLoadCondition2D2N": "SurfaceLoadCondition3D4N"}). cap_condition_names maps the cap face node count ("3" or "4") to a condition type to create conditions on the new 'zmin' / 'zmax' sub model parts (which always hold the cap nodes). Existing parts are carried over with all layers. |
| mdpa_convert_cellsA | Convert cell kinds. mode 'quad_to_tri' splits every quadrilateral element into 2 triangles (e.g. SmallDisplacementElement2D4N -> ...2D3N); 'hex_to_tet' splits hexahedra into 6 tetrahedra (Kuhn split, conforming for structured meshes with consistent node ordering) and the boundary quads into triangles matching the tet faces; 'quadratic_to_linear' drops the mid-edge/face nodes of quadratic cells (tri6->tri, quad8/9->quad, tet10->tet, hex20/27->hex, wedge15->prism, line3->line; ids and sub model parts unchanged, mid nodes kept as unused nodes). Sub model parts follow. element_name / condition_name override the derived new type names. Other cell kinds are left alone. Needed e.g. for the convection-diffusion solver, which requires simplices. |
| mdpa_extract_boundaryA | Create conditions on the free (unshared) faces of the elements -- the way to get load/flux surfaces on a mesh that has none -- and put them in sub_model_part (created if needed). condition_name is a Kratos type (e.g. 'LineLoadCondition2D2N', 'SurfaceLoadCondition3D4N') or a map {"2": ..., "3": ..., "4": ...} by face node count (needed for prisms, mixed meshes and quadratic cells: quadratic edges have 3 nodes, tet10 / wedge tri faces 6, hex20 / wedge quad faces 8, hex27 faces 9). element_part restricts to one part's elements; selector (see mdpa_select_nodes, e.g. a plane) keeps only faces whose nodes are all selected, giving e.g. just the x=0 face. Faces are oriented outward for positively oriented elements (domain on the left of 2D edges). NOTE: with that orientation a positive POSITIVE_FACE_PRESSURE load acts along the outward normal (a tension); use a negative value for a compressive pressure. Supports linear and quadratic line, triangle, quad, tet, prism and hex cells (measures use the corners). |
| mdpa_set_propertiesA | Edit the mesh-embedded 'Begin Properties' block of one property id (values {"DENSITY": 7850.0} are added/replaced, 'remove' deletes names; lists are written space separated) and/or the 'ModelPartData' header. Most cases keep material data in Materials.json instead -- see materials_set_property. |
| mdpa_set_nodal_dataB | Write a 'Begin NodalData ' block value (an initial condition stored in the mesh, e.g. TEMPERATURE) on the chosen nodes (node_ids or selector). A float writes a scalar row, a string such as "[3](1.0, 0.0, 0.0)" a vector row (kept verbatim); fixed=true marks the rows fixed (constrained). |
| mdpa_get_data_blocksA | List the data carried by a .mdpa besides the mesh itself: top-level Tables (id, variables, row count), 'Begin ElementalData' / 'Begin ConditionalData' variables with row counts, vector and flag 'Begin NodalData' blocks, and per-SubModelPart data/table/property references. All of these round-trip through every editing tool. |
| mdpa_set_elemental_dataA | Upsert 'Begin ElementalData ' (kind 'elemental') or 'Begin ConditionalData ' (kind 'conditional') rows: values maps element/condition ids to numbers, lists (written space separated) or raw strings such as "[3](0.0, 1.0, 0.0)" for vectors (kept verbatim). remove_ids deletes rows. Ids must exist; rows follow renumber/merge/delete automatically. |
| mdpa_set_tableB | Create or replace a top-level 'Begin Table <x_variable> <y_variable>' block (piecewise-linear time series, e.g. TIME vs VELOCITY); rows are [x, y] pairs. |
| mdpa_delete_tableB | Delete a top-level 'Begin Table' block. Refused while a SubModelPart references the table. |
| mdpa_set_sub_model_part_dataB | Replace a SubModelPart's data references wholesale (each None leaves that reference unchanged): data is the 'Begin SubModelPartData' key-value pairs, tables the 'Begin SubModelPartTables' table ids (must exist as top-level Tables), properties the 'Begin SubModelPartProperties' property ids. |
| mdpa_qualityB | Mesh quality report, per element/condition type: count, measure (length/area/volume, from the corner nodes for quadratic cells) min/mean/max/total, aspect ratio (longest/shortest edge) with the ids of the worst cells, corner-angle extremes in degrees (angle_degrees: min, max and the ids with the smallest angle) for triangles and quads, and the ids of inverted or degenerate cells (non-positive signed measure -- these crash or poison a Kratos run). Linear, quadratic and cubic line, triangle, quad, tet, prism, pyramid and hex cells. |
| mdpa_create_geometry_meshA | Generate a mesh of a parametric shape and write it as .mdpa (no gmsh needed). Every mesh gets a 'domain' part plus named boundary parts with conditions of condition_name (default LineLoadCondition2D2N in 2D, SurfaceLoadCondition3D4N in 3D). kind and its params: 'annulus' {r_inner, r_outer, n_radial, n_theta, angle=360, triangles=false} quads (or triangles); parts inner, outer (+ start, end for angle<360) 'disc' {radius, n_radial, n_theta} triangles; part boundary 'cylinder' {radius, height, n_radial, n_theta, n_z, inner_radius=None} prisms (solid) or hexahedra (hollow); parts lateral, zmin, zmax 'sphere' {radius, divisions} hexahedra, radially mapped cube; part surface 'polygon' {vertices: [[x, y], ...], refinements=0, holes=None, target_size=None} triangles by ear clipping + midpoint subdivision; parts side_0, side_1, ... plus hole_ per hole loop; holes is a list of vertex loops strictly inside the polygon; target_size adds subdivision rounds until no edge is longer than it (at most 6 rounds total, best effort). Graded sizes without gmsh: size_field is an expression of x, y (e.g. "0.1 + 0.3sqrt(xx + y*y)") and/or size_sources a list of {"point": [x, y]} or {"segment": [[x0, y0], [x1, y1]]} with "size" (edge length at the source) and "growth" (default 0.3, length gained per unit distance); the minimum of all wins. The mesh is refined by conforming longest-edge bisection until every triangle's longest edge fits the local size (max_elements=200000 guards runaway sizes), smooth_iterations=0..100 then Laplacian-smooths interior nodes. element_name overrides the element type (default: SmallDisplacement elements of matching node count). For CAD input or quality-driven meshes use mesh_generate_gmsh. |
| mesh_importA | Convert a mesh file of another format (gmsh .msh, VTK .vtk/.vtu, MED, Abaqus .inp, Nastran, XDMF, ... anything meshio reads) into a Kratos .mdpa. The highest-dimension cells become elements, the next lower dimension conditions; named physical groups / cell sets become sub model parts (a 'domain' part with everything is added). Linear and quadratic line, triangle, quad, tetra, hexahedron, wedge and pyramid cells are converted, plus the cubic line4 / triangle10 / quad16 (other cubic and higher Lagrange cells are rejected). 15-node wedges and 13-node pyramids cannot be represented by meshio itself and are refused on export (see mesh_export linearize_unsupported). element_name / condition_name set the Kratos types (defaults are generic Element2D3N ... SurfaceCondition3D4N, fine for thermal or fluid solvers that replace elements; give e.g. SmallDisplacementElement2D3N for structural cases). file_format forces meshio's reader when the extension is ambiguous. |
| mesh_exportA | Export a .mdpa to another mesh format chosen by the output extension (.vtk, .vtu, .msh, .med, .inp, .xdmf, ...) or file_format. Elements come first, then conditions; cell data carries kratos:id, kratos:property_id and kratos:entity (0 element / 1 condition), sub model parts become cell sets (format permitting) and scalar nodal data point data. Cubic triangle10 / quad16 / line4 cells only export to formats that have them (gmsh .msh, not VTK). meshio has no 15-node wedge or 13-node pyramid: they are refused unless linearize_unsupported=true, which writes their corner nodes only (the result carries a warnings entry). |
| mesh_generate_gmshA | Mesh arbitrary geometry with gmsh (optional extra: uv sync --extra gmsh) and write it as .mdpa. kind: 'polygon' -- vertices [[x, y], ...] (counter-clockwise) with optional holes (list of vertex loops); physical groups become sub model parts: domain, side_ (outer edge i), hole_; quads=true recombines into quadrilaterals. 'shape' -- 3D tetrahedra of shape 'box' (shape_params {size_xyz: [lx, ly, lz], origin}), 'cylinder' ({radius, height}) or 'sphere' ({radius}); parts domain, boundary. 'file' -- mesh a CAD/geometry file (cad_file: .step, .brep, .geo, .iges...) in dimension dim; its physical groups are kept, else domain/boundary are created. size is the target element size (size_min the lower bound, default size/10). element_name / condition_name set the Kratos types (defaults Element2D3N / LineCondition2D2N / Element3D4N / SurfaceCondition3D3N). gmsh runs in a subprocess, never inside the server. Returns the mesh summary and the gmsh physical groups. |
| project_get_settingA | Read any part of a ProjectParameters.json by JSON Pointer, e.g. '/solver_settings/time_stepping/time_step' or '/processes/loads_process_list/0' ('' = the whole file or stage). For multi-stage (orchestrator) files pass stage; the pointer is then relative to that stage's stage_settings. |
| project_set_settingA | Set (or add) any value in a ProjectParameters.json by JSON Pointer, e.g. pointer '/solver_settings/time_stepping/time_step' value 0.05, or '/processes/loads_process_list/-' to append a whole process block to a list. Missing intermediate objects are created when create=true. Returns the previous value. For multi-stage files pass stage (pointer relative to its stage_settings). The file is rewritten atomically. |
| project_delete_settingB | Delete a key (or list item by index) from a ProjectParameters.json by JSON Pointer. Returns the removed value. |
| project_list_processesA | List every process block of a ProjectParameters.json (all lists of 'processes' and 'output_processes') with its section, list name, index, python_module, model_part_name, variable_name and interval. The (list, index) pair addresses a block in project_update_process / project_remove_process. |
| project_add_processA | Add ANY Kratos process to a ProjectParameters.json -- the generic counterpart of add_boundary_condition / add_output_process. python_module is a module name from kratos_list_processes (e.g. 'assign_scalar_variable_process', 'apply_constraint_vector_process', 'compute_...'); 'parameters' are its Parameters (see kratos_get_process_defaults for the schema). With merge_defaults (default) the process' real default settings fill every key you omit (needs the Kratos source tree). kratos_module is inferred ('KratosMultiphysics' for core, 'KratosMultiphysics.' for application processes; pass it explicitly if a warning says it was guessed). The block goes into process_list of 'section' ('processes' by default, 'output_processes' for vtk/gid output modules), created if missing, at 'position' (default: end). Warnings flag model parts missing from the mesh and, with a Kratos build, unknown variable names. |
| project_update_processA | Change the Parameters of one existing process block. Address it by process_list + index (from project_list_processes) or by matching python_module / model_part_name / variable_name (must match exactly one block). 'parameters' is deep-merged into the block's Parameters (nested objects merge, everything else replaces); replace=true swaps the whole Parameters object instead. |
| project_remove_processB | Remove process blocks, addressed by process_list + index or by matching python_module / model_part_name / variable_name. More than one match is refused unless all_matches=true. Returns the removed blocks. |
| project_update_solverA | Update solver_settings / problem_data of a ProjectParameters.json. 'settings' is deep-merged into solver_settings (e.g. {"solver_type": "Dynamic", "analysis_type": "non_linear", "residual_relative_tolerance": 1e-6}). linear_solver_preset applies a block from list_linear_solver_presets (sparse_lu, amgcl, cg, ...), or pass an explicit linear_solver_settings. time_step sets solver_settings.time_stepping.time_step; start_time / end_time live in problem_data. domain_size sets solver_settings.domain_size. mesh_file points model_import_settings at an .mdpa (input_type 'mdpa', file name without extension, relative to the case directory) and materials_file sets material_import_settings.materials_filename. Returns what changed. Run validate_project_parameters(deep) afterwards to check the solver accepts it. |
| materials_getB | Read a Materials.json: one summary row per properties entry (model_part_name, properties_id, constitutive law, variable names) plus the raw document. |
| materials_set_propertyA | Add or update ONE entry of a Materials.json (created if the file does not exist), keyed by model_part_name (e.g. 'Structure.domain'). New entries get the next free properties_id unless given. 'preset' (see list_material_presets) fills the constitutive law and default variables; 'constitutive_law' and 'variables' then override. On an existing entry, variables/tables are merged into the current ones; replace=true rebuilds the entry from scratch. This is the incremental counterpart of create_materials, which rewrites the whole file. |
| materials_remove_propertyC | Remove entries from a Materials.json matching model_part_name and/or properties_id (all given criteria must match). |
| materials_checkA | Cross-check a case's Materials.json against its mesh: every entry's model_part_name must be the root model part or one of the mesh's sub model parts, every properties_id used by an element needs an entry, and (with a Kratos build) every constitutive law must exist -- pass the application names that register them (e.g. ["StructuralMechanicsApplication"]) so they are imported first. Single-stage cases only. |
| run_simulationA | Start a Kratos simulation as a background job and return its job_id. The analysis class is taken from the 'analysis_stage' key in the parameters, or inferred from solver_type; override with analysis_type (structural/fluid/thermal/potential_flow) or analysis_class ('module.path:ClassName'). If wait_seconds > 0, poll up to that long and return the final status if the job finishes in time. Track progress with job_status/job_logs. mpi_ranks launches the case under an MPI launcher (mpiexec/mpirun, or KRATOS_MPI_LAUNCHER) with that many ranks; the case must set problem_data.parallel_type to "MPI" and the build must have MPI support, otherwise the call fails before any job is created. Rank 0 logs to the job log; other ranks to job_logs(rank=N). omp_threads sets OMP_NUM_THREADS/MKL_NUM_THREADS. Not supported for multi-stage or CoSimulation or FSI cases, checkpoints or studies. Multi-stage (orchestrator + stages), CoSimulation (coupled solver in solver_settings, see create_cosim_project) and partitioned FSI (solver_type 'partitioned', see create_fsi_project) cases are detected automatically; CoSimulation needs KratosCoSimulationApplication and FSI needs KratosFSIApplication (plus fluid, structural, mesh-moving and mapping applications). |
| validate_caseA | Dry-run check of a case directory without running the time loop: JSON validity, required keys, mesh and materials files exist and parse, model part references match the mesh, and the solver settings validate against Kratos defaults. |
| job_statusA | Get the state of a simulation job (queued/running/succeeded/ failed/cancelled), elapsed time, and current step/time parsed from its log. |
| job_listA | List all known simulation jobs, optionally filtered by state (queued, running, succeeded, failed, cancelled). |
| job_logsA | Return the last 'tail' lines of a job's simulation log, optionally only lines containing the 'grep' substring (case-insensitive). For MPI jobs, 'rank' selects another rank's log (job_status lists rank_logs); rank 0 / unset is the main log. |
| job_cancelA | Cancel a running simulation job (SIGTERM, escalating to SIGKILL after a grace period). Signals the whole process group, so every MPI rank is stopped. |
| job_rerunC | Rerun a job from its preserved isolated input snapshot. |
| configure_checkpointsB | Configure serial single-stage checkpoint output before starting an isolated job. |
| job_checkpointsB | List completed managed checkpoints, including retained/deleted availability. |
| job_resumeC | Resume a terminal isolated job from an explicit job_checkpoints path into a new job. |
| results_listA | Discover result artifacts in a case directory (recursively): VTK/VTU files, GiD post files, HDF5, JSON results and point-output .dat/.csv files, sorted lexically by name (not physical time). |
| results_summaryA | Summarise a VTK/VTU result file: number of points/cells, the variables present, and per-variable statistics (min/max/mean, or magnitude stats for vector fields). Optionally restrict to one variable. |
| results_probeA | Read the value of a variable at one location of a VTK/VTU result: either the mesh point nearest to 'point' [x, y, z], or the point at 0-based index 'node_index'. Returns the value and the actual coordinates used. |
| results_convergenceA | Extract convergence information from a simulation log (by job_id or explicit log file path): per-step nonlinear (or CoSimulation coupling) iteration counts, residual ratios, and which steps converged. |
| results_time_historyB | Probe a physical-time series from an index path or explicit file/time records; optionally export CSV. |
| results_compareC | Compare histories or matching-mesh fields at matching physical times without interpolation. |
| results_renderA | Render a VTK/VTU result file to a PNG screenshot, returned inline (requires the optional pyvista 'viz' extra). Colors the mesh by 'variable' (point or cell data; vector fields default to magnitude, or pick component 'x'/'y'/'z'), optionally warps the geometry by a vector field such as DISPLACEMENT scaled by warp_factor. Camera presets: xy, xz, yz, iso. crop_bounds clips to a region of interest before framing the camera -- [xmin,xmax,ymin,ymax] or [xmin,xmax,ymin,ymax,zmin,zmax] -- essential for e.g. a small body in a huge far-field CFD domain, otherwise invisible at full-domain zoom. The PNG is saved next to the input file unless image_path is given. |
| results_animateA | Render a time series of VTK/VTU results into an animated GIF (requires the optional pyvista 'viz' extra). 'files' is a directory (e.g. the case's vtk_output/) or a glob; frames are ordered by the numbers in their names. Coloring/warping/crop_bounds options as in results_render, with one color range, crop and camera across all frames. Small GIFs are returned inline; the file path is always returned. |
| explain_project_parametersA | Parse an existing ProjectParameters.json and return a structured summary of what it configures: analysis type, solver + linear solver, mesh and material import, and the flattened boundary-condition / load / output process lists (with the model parts each targets). Multi-stage (orchestrator/stages) cases are summarized per stage. Use this to understand a case you did not scaffold before editing or running it. |
| export_case_to_flowgraphA | Convert a ProjectParameters.json into a Flowgraph (litegraph) graph.json that can be opened in the Kratos FlowGraph visual node editor. Returns the graph; when output_file is given it is also written there. Round-trips with import_flowgraph_to_case. |
| import_flowgraph_to_caseA | Convert a Flowgraph (litegraph) graph.json -- as saved by the Kratos FlowGraph editor -- back into a ProjectParameters.json. Returns the parameters; when output_file is given it is also written there. Round-trips with export_case_to_flowgraph. |
| study_startA | Prepare all isolated variants, then start a detached bounded study. specification: {kind:'parameter', axes:[{file:'Materials.json', pointer:'/properties/0/Material/Variables/YOUNG_MODULUS', values:[1e11,2e11]}], combination:'product'|'zip'} or {kind:'mesh', mesh:{kind:'rectangle', size:[1,0.2]}, divisions:[[4,1],[8,2],[16,4]]}. Optional atol/rtol/time_atol control mesh-response comparisons. Responses: [{name:'tip', variable:'DISPLACEMENT', point:[1,0,0], component:1, reduction:'final'}]. Optional response association: point/cell, series, max_distance; component may be 'magnitude'; reduction may be final/min/max. Serial single-stage POSIX jobs only. Progress survives server exit. |
| study_statusB | Return durable study progress, child jobs, provenance, and response errors. |
| study_listC | List studies, optionally filtering by their study-level state. |
| study_cancelC | Stop pending launches and cancel active process groups; preserve results. |
| study_resumeC | Verify and resume an interrupted coordinator, adopting existing child jobs. |
| study_resultsC | Get partial/complete probe histories, scalar responses and mesh differences. Optional CSV uses exclusive creation and never overwrites an existing file. |
| session_startA | Open an interactive Kratos session: load the case, build the AnalysisStage and run Initialize(), then return a session_id and the initial state (time 0, node/element counts, model parts). Nothing is solved until session_advance. Unlike run_simulation this keeps the live model in memory so you can step, inspect and modify it. Single-stage, serial/OpenMP cases only (multi-stage, CoSimulation, FSI and MPI cases are rejected: use run_simulation). isolate=True works on a private copy of the case so the original files and outputs stay untouched. Sessions do not survive a server restart; close them with session_close. At most KRATOS_MCP_MAX_SESSIONS (default 4) can be open at once. |
| session_listA | List interactive sessions (newest first), optionally filtered by state: starting/ready/closed/dead/lost. 'lost' means the session belonged to a previous server process. |
| session_statusA | State of a session: ready/closed/dead/lost, whether the worker is busy with a request, recorded step count, and (for dead sessions) why it died with the log tail. Set log_tail > 0 to include the last N lines of the session's solver log. Use session_model_info for the live simulation time/step. |
| session_get_parametersB | Read the live ProjectParameters of a session (after defaults were applied). path is an optional JSON Pointer such as '/solver_settings/time_stepping' or '/processes/loads_process_list/0'; empty returns everything. |
| session_advanceA | Advance the simulation by Returns the new time, whether the run is finished, why it stopped
(steps_completed / until_time_reached / end_time_reached) and a
per-step history (step, time, converged, wall_seconds). If the call
exceeds |
| session_model_infoA | Live model structure: node/element/condition counts for a model part
(default: the solver's main model part) and its sub model parts down to
|
| session_field_summaryB | Summarise a field at the CURRENT time: min/max/mean (vectors by magnitude, with component-wise min/max), and the node/element where the maximum and minimum occur (with coordinates for nodes). location='nodes' reads nodal solution-step variables (DISPLACEMENT, REACTION, VELOCITY, PRESSURE, TEMPERATURE, ...). location='elements' evaluates an element result at the integration points and reports the worst Gauss point per element (e.g. VON_MISES_STRESS, TEMPERATURE gradients, CAUCHY_STRESS_VECTOR). |
| session_inspect_nodeB | Inspect one node: current and initial coordinates, the values of
|
| session_inspect_elementB | Inspect one element: its node ids, properties id, active flag, and
the integration-point values of |
| session_set_nodal_valuesA | Assign a nodal solution-step value (a number, or [x, y, z] for vector variables such as DISPLACEMENT or VELOCITY) to node_ids, or to every node of model_part when node_ids is omitted. fix=True/False fixes/frees the DOF (a list of 3 booleans sets each vector component); omit it to leave fixity unchanged. Takes effect from the next session_advance, so you can add a support, pin a temperature or perturb the state mid-run. Writes into the live model only: files on disk are unchanged. |
| session_exec_pythonA | Run Python inside the session's Kratos process for anything the
typed tools do not cover. The namespace holds KM (KratosMultiphysics),
model, stage (the AnalysisStage), session, parameters; assign a
JSON-serialisable value to DISABLED unless the MCP server was started with KRATOS_MCP_ALLOW_EXEC=1, because it executes arbitrary code as the server's user. |
| session_closeA | Close a session. With finalize=True (default) the AnalysisStage's Finalize() runs first so output processes flush (VTK/GiD files, restart files); then the worker process group is terminated. Safe to call on an already closed or dead session. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| setup_structural_analysis | Guided workflow to set up and run a structural analysis. |
| setup_thermal_analysis | Guided workflow to set up and run a heat-conduction analysis. |
| setup_fluid_analysis | Guided workflow to set up and run an incompressible flow analysis. |
| debug_failed_simulation | Diagnose why a simulation job failed. |
| postprocess_results | Summarise the results of a finished simulation. |
| interactive_session | Guided workflow to drive a case step by step in a live session. |
| build_mesh_from_geometry | Guided workflow to build a mesh for an arbitrary geometry and name its boundaries, then turn it into a runnable case. |
| edit_existing_case | Guided workflow to modify an existing case (mesh, processes, solver, materials) safely. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| mdpa_format_doc | Guide to the Kratos MDPA mesh file format. |
| mesh_editing_doc | Guide to building and editing meshes with the mdpa_* / mesh_* tools. |
| project_parameters_doc | Guide to the ProjectParameters.json configuration format. |
| materials_doc | Guide to the Materials.json format and common constitutive laws. |
| cantilever_example | Complete structural static example: cantilever plate under edge load. Copied verbatim from real files on disk (examples/cantilever/) -- not rendered from the templates at request time, so it works identically even if the templates change later. |
| thermal_bar_example | Complete thermal example: bar with fixed end temperatures. |
| naca_airfoil_example | Worked example: NACA0012 airfoil, incompressible viscous flow. Unlike cantilever_example(), the ~21k-node mesh is too large to embed verbatim -- a mdpa_inspect-style summary is given instead of the raw mesh.mdpa text. |
| lid_driven_cavity_example | Complete incompressible-flow example: lid-driven cavity (Re=100, monolithic Navier-Stokes). Real files on disk, with a verified recirculation result. The classic CFD benchmark. |
| plasticity_cube_example | Complete nonlinear structural example: a single hexahedral element under von Mises plasticity (material preset), showing the elastic -> plastic transition. Real files on disk with a verified result. |
| multistage_load_steps_example | Complete multi-stage (orchestrated) example: a cantilever solved in two sequential load steps sharing one mesh via the SequentialOrchestrator. Real files on disk with a verified per-stage result. |
| load_stepping_cantilever_example | Complete interactive-session example: a cantilever with a time-ramped tip load (modulus '1.0e6*t'), meant to be stepped with the session_* tools (session_start/session_advance/session_inspect_node/...). Real files on disk with a verified step-by-step result. |
| channel_flow_example | Incompressible channel flow via the fractional-step solver (cheaper per step than monolithic for large meshes). Rendered from the fluid_fractional_step template plus a mesh recipe. |
| modal_box_example | Modal (eigenvalue) analysis of a 3D block: natural frequencies and mode shapes. Rendered from the structural_modal template plus a mesh recipe. |
| dynamic_cantilever_example | Transient (implicit dynamic) structural analysis: a cantilever under a time-varying tip load, integrated with the Newmark scheme. Rendered from the structural_dynamic template plus a mesh recipe. |
| potential_flow_example | Runnable NACA0012 potential-flow benchmark with reference values. |
| coupled_sdof_example | Complete CoSimulation (coupled-solver) example: two Python-only single-degree-of-freedom oscillators coupled as a mass-spring chain with strong Gauss-Seidel iteration and an Aitken accelerator. Real files on disk with a verified interface data exchange; no mesh needed. |
| coupled_blocks_example | Complete mesh-based CoSimulation example: two Kratos structural blocks with non-matching interfaces coupled by Dirichlet-Neumann iteration through kratos_mapping, with verified force conservation and indexed sub-solver output. Real files on disk. |
| fsi_flexible_flap_example | Complete partitioned fluid-structure interaction example: the Mok flexible-flap benchmark (FSIApplication, Dirichlet-Neumann coupling, ALE mesh motion) with a verified comparison against the upstream reference history. Real files on disk; the large meshes are summarized instead of embedded. |
| adaptive_remeshing_example | Worked adaptive-remeshing example (MeshingApplication/MMG): a hessian-adapted mesh (mesh_remesh, 3 passes) that is twice as accurate as a uniform mesh with the same element count, and a thermal case remeshed at setup by an mmg_process (add_remeshing_process). Real files on disk with verified counts. |
TDQS
Scored across 110 tools
The tool set is large but well-organized into clearly separated namespaces (mdpa_*, session_*, job_*, project_*, materials_*, results_*, kratos_*, study_*), and descriptions carefully delineate boundaries (e.g. mdpa_add_entities vs mdpa_create_sub_model_part). A few overlaps remain—mdpa_create_structured_mesh vs mdpa_create_geometry_mesh vs mesh_generate_gmsh all generate meshes—but param formats and descriptions make the intended use distinguishable.
The vast majority of tools follow a consistent prefix_verb_noun pattern (mdpa_inspect, session_advance, project_set_setting, results_probe, job_status). A handful deviate slightly (mdpa_quality, mdpa_transform, mdpa_renumber, kratos_install, validate_case), but never in a way that obscures meaning or mixes camelCase with snake_case.
110 tools is far beyond the typical 3–15 well-scoped range and beyond even the 25+ threshold for 'too many'. While each tool is individually non-trivial and the domain (Kratos Multiphysics simulation lifecycle) is genuinely broad, the surface is heavy enough that discovery and selection overhead is substantial.
Coverage is exceptionally thorough across the full simulation lifecycle: project scaffolding, parameter/material editing, mesh import/generation/manipulation, solver discovery, job/study execution, interactive sessions, results inspection/rendering, and Flowgraph round-tripping. Obvious gaps are hard to identify—even checkpoints, MPI, CoSimulation, and FSI are addressed.