Kratos MCP Server

Overview Schema Source Related Servers Discussions Admin

mdpa_create_geometry_mesh

Generate a mesh for parametric shapes (annulus, disc, cylinder, sphere, polygon) and write it as .mdpa without gmsh for Kratos simulations.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	Yes
`path`	Yes
`params`	Yes
`overwrite`	No
`element_name`	No
`condition_name`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.9.0Oct 16, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does substantial work: it discloses that a 'domain' part plus named boundary parts with conditions are created, the default condition/element types per dimensionality, the refinement/Laplacian-smoothing behavior, and the max_elements=200000 guard against runaway sizes. It does not explain what the overwrite flag does or what happens when the target path already exists, which is the main remaining gap for a file-writing tool.

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?

Purpose is front-loaded in the first sentence, but the body is an extremely dense run-on block of kind/param text that is hard to scan. Much of the length is justified by 0% schema coverage, yet tighter formatting (per-kind lines, shorter clauses) would preserve the content with less parsing effort.

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?

An output schema exists, so return values need not be described, and the description is thorough about mesh generation semantics for a 6-param nested tool. It is nearly complete; only the overwrite behavior and path expectations are left unaddressed.

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 compensate, and it does for most parameters: kind's five values are enumerated with their full params (r_inner, n_theta, vertices, holes, size_field, size_sources, etc.), and element_name/condition_name defaults are stated. 'overwrite' and 'path' are never explained, so the coverage is strong but not exhaustive.

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?

Specific verb + resource: generates a mesh for a parametric shape and writes it as a .mdpa file, with the parenthetical '(no gmsh needed)' clarifying the mechanism. It explicitly distinguishes itself from the sibling mesh_generate_gmsh, so an agent can route between them without opening either 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?

Provides a clear alternative and selection condition: 'For CAD input or quality-driven meshes use mesh_generate_gmsh,' and the '(no gmsh needed)' clause implies when this tool is preferred. It stops short of naming when-not conditions against other siblings (e.g. mdpa_create_structured_mesh) or stating prerequisites like a valid workspace path.

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

Deploy Server