Skip to main content
Glama
loumalouomega

Kratos MCP Server

by loumalouomega
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

run_simulation

Start a Kratos simulation as a background job and return its job_id, with optional wait, analysis type/class, MPI ranks, and OMP threads.

Instructions

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 cases, checkpoints or studies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
isolateNo
case_dirYes
mpi_ranksNo
omp_threadsNo
wait_secondsNo
analysis_typeNo
analysis_classNo
external_inputsNo
parameters_fileNoProjectParameters.json

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.7.0
    • addedInput schema / properties / mpi_ranks
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Mpi Ranks"
+}
    • addedInput schema / properties / omp_threads
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Omp Threads"
+}
  2. Changed2 schema fields changedv0.5.0
    • addedInput schema / properties / external_inputs
      Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "External Inputs"
+}
    • addedInput schema / properties / isolate
      Added value: +{
+  "default": false,
+  "title": "Isolate",
+  "type": "boolean"
+}
  3. First observedv0.3.1

TDQS

A4.3/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 burden and does so well: it discloses asynchronous background-job semantics, the MPI precondition (parallel_type must be 'MPI', build must have MPI support) and the failure mode (fails before any job is created), per-rank log locations, and environment-variable side effects for omp_threads.

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?

Front-loaded with the purpose and job_id return, then organized into a paragraph on analysis class resolution and one on parallelism. Dense but every sentence carries information; minor tightening would still help.

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?

For a complex async launcher with an output schema covering return values, the description covers lifecycle, preconditions, and parallelism limits. The remaining gap is a handful of unexplained parameters (isolate, external_inputs, parameters_file) that an agent must guess at.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 9 params, so the description must compensate. It explains analysis_type, analysis_class, wait_seconds, mpi_ranks, and omp_threads meaningfully, but leaves isolate, external_inputs, and parameters_file completely undocumented, and 'isolate' in particular is 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?

States a specific verb and resource ('Start a Kratos simulation as a background job') plus the return value (job_id). This distinguishes it cleanly from siblings like job_rerun, job_resume, and study_start, which also launch work but in different contexts.

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 explicit follow-up routing ('Track progress with job_status/job_logs') and a clear exclusion set: 'Not supported for multi-stage cases, checkpoints or studies.' It stops short of naming which tool to use instead for those excluded cases, so the routing is one-directional.

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