Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ABAQUS_AGENT_CPUSNoNumber of CPUs to use for Abaqus jobs.
ABAQUS_AGENT_COMMANDNoFull path to the Abaqus launcher (e.g., abaqus.bat on Windows). Set this if the default lookup fails.
ABAQUS_AGENT_RUNS_DIRNoDirectory where Abaqus job output should be written. Defaults to ./runs beside where the server was launched../runs
ABAQUS_AGENT_JOB_TIMEOUTNoTimeout 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 22 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues