abaqus-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ABAQUS_AGENT_CPUS | No | Number of CPUs to use for Abaqus jobs. | |
| ABAQUS_AGENT_COMMAND | No | Full path to the Abaqus launcher (e.g., abaqus.bat on Windows). Set this if the default lookup fails. | |
| ABAQUS_AGENT_RUNS_DIR | No | Directory where Abaqus job output should be written. Defaults to ./runs beside where the server was launched. | ./runs |
| ABAQUS_AGENT_JOB_TIMEOUT | No | Timeout for Abaqus jobs. |
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 |
|---|---|
| check_environmentA | Report whether Abaqus is available and where jobs will run. |
| greetingA | Return a friendly greeting to the user. |
| run_simulationA | Run a single Abaqus job from an .inp deck and return its status report. Args: inp_path: Path to the Abaqus keyword input deck (.inp). job_name: Optional job name (defaults to the deck's file stem). cpus: Number of CPUs for the solver. timeout_s: Wall-clock ceiling for the solver run. |
| autocorrect_simulationA | Run a job and autonomously fix failures (convergence, singularity, deck errors) by editing the deck from the .sta/.msg/.dat diagnostics, retrying up to max_iters times. Returns a full narrative of every attempt and fix. Args: inp_path: Path to the Abaqus keyword input deck (.inp). job_name: Optional job name (defaults to the deck's file stem). max_iters: Maximum run/fix iterations. cpus: Number of CPUs for the solver. timeout_s: Wall-clock ceiling per solver run. |
| get_job_statusA | Parse the current output files of a job and return a status summary. |
| read_job_fileA | Return the tail of a job's output file for inspection. Args: job_name: The job to inspect. extension: One of inp, sta, msg, dat, log (without the dot). max_lines: Maximum number of trailing lines to return. |
| get_spec_templateA | Return an example simulation spec (JSON) showing every field the model authoring pipeline accepts. Fill this in to describe a new simulation. |
| get_parametric_spec_templateA | Return an example spec that builds geometry parametrically (no CAD file). Also lists the supported shapes and their required params. |
| validate_simulation_specA | Check a simulation spec (JSON string) against the schema without running anything. Returns 'valid' or a list of problems to fix. |
| build_modelA | Build a meshed model from a simulation spec (JSON) and export an .inp deck, WITHOUT running it. Imports CAD (STEP/IGES), meshes, and applies materials/BCs/loads. Returns the deck path and mesh stats, or build errors. Args: spec_json: The simulation spec as a JSON string (see get_spec_template). job_name: Optional job name (defaults to the spec's model_name). |
| build_and_simulateA | Full pipeline: build a model from a spec (CAD import + mesh + physics), then autonomously run and error-correct it. Returns build stats plus the run narrative. Args: spec_json: The simulation spec as a JSON string (see get_spec_template). job_name: Optional job name (defaults to the spec's model_name). max_iters: Maximum run/fix iterations. |
| get_resultsA | Extract and report headline results (peak von Mises stress, peak displacement, plastic strain / yielding, net reaction force) from a finished job's .odb. |
| list_jobsA | List all jobs (run directories) known to the engine. |
| sweep_statusA | Summarise a parametric sweep: how many designs are valid, parked or abandoned, and where its results table lives. Args: sweep: The sweep name given when it was launched. |
| list_parked_failuresA | List the designs a sweep could not resolve on its own. These are waiting for judgement: each either failed to converge, or converged to something the physical-validity gate rejected. Use get_parked_failure to read the diagnostics for one. Args: sweep: The sweep name. |
| get_parked_failureA | Full diagnostics for one parked design, to reason about before fixing. Returns the solver status, the error-level diagnostics, the tail of the .sta and .msg, any input-processor errors, the validity verdict, the fixes already attempted, and the deck itself. Args: sweep: The sweep name. design_id: Which parked design to inspect. deck_chars: How much of the .inp to include (from the start). |
| apply_reasoned_fixA | Apply a reasoned deck edit to a parked design and re-run it. Edits are literal find/replace so the change is reviewable and lands in the fix log. Edits that remove output requests, or that delete most of the deck, are refused: a run is judged on its output, so deleting the output is not a fix. Args: sweep: The sweep name. design_id: The parked design to repair. edits_json: JSON list of {"find": ..., "replace": ...} applied in order. rationale: Why this edit should fix the diagnosed failure. Recorded. max_iters: Deterministic fix iterations allowed on the re-run. cpus: CPUs for the solver. |
| get_fix_logC | The record of every reasoned fix attempted in a sweep, successful or not. What failed, what was diagnosed, what changed, and whether it then converged. Args: sweep: The sweep name. |
| check_validityA | Judge whether a COMPLETED job is physically believable. A green solver status only means the analysis reached the end of the step. This reads the energy balance and reports whether the answer can be trusted: artificial (hourglass) energy carrying the load, kinetic energy dominating a quasi-static event, or total energy not being conserved. Args: job_name: The job to judge. quasi_static: True if the event is meant to be slow (a crush, a press). Kinetic energy is only a failure signal when it is. |
| inspect_deckA | Summarise what is actually in an Abaqus input deck. Reports the mesh, materials, sections, sets, steps, loads and boundary conditions a deck defines, plus any references pointing at names the deck never defines. Reads the file only: no solver, no licence token. Args: inp_path: Path to the .inp deck, or a job name under the runs directory. |
| start_sweepA | Run a parametric sweep, parking whatever needs judgement. Each design goes through the autocorrect loop and then the validity gate. Anything that fails, or that converges to something not believable, is parked with full diagnostics rather than dropped. Resumable: re-running the same sweep name skips designs that already finished. This blocks until the sweep completes, so keep the design count small from an interactive client. For a long unattended sweep, run the sweep module as a detached process instead. Args: sweep_name: Name for this sweep; also its results directory. designs_json: JSON list of {"design_id":..., "inp":..., "params":{...}}. max_iters: Deterministic fix iterations allowed per design. cpus: CPUs per solver run. quasi_static: Whether to judge the event as quasi-static. |
| whats_newA | What changed in this release, and in earlier ones. Args: version: A specific version such as "0.3.0". Omit for the current release, or pass "all" for the whole history. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 22 tools
Most tools target distinct resources and actions (deck, job, sweep, spec, results), but run_simulation, autocorrect_simulation, and build_and_simulate are overlapping entry points that could confuse an agent. The descriptions do clarify the differences, so the ambiguity is limited.
Tool names consistently use snake_case and mostly follow a verb_noun pattern, e.g. inspect_deck, run_simulation, build_model. Minor deviations like the noun-only 'greeting' and the informal 'whats_new' prevent a perfect score.
22 tools is in the heavy range for one MCP server, and several are meta/utility tools (greeting, whats_new, check_environment) or pipeline supersets. The Abaqus domain is complex enough to justify many of them, but the surface could be trimmed.
The core lifecycle is well covered: spec templates, validation, model building, running, autocorrection, sweeps, diagnostics, validity checks, and results extraction. Missing cleanup/stop operations and direct deck editing are workable gaps rather than dead ends.