Loading ToolBench
MCP server for Abaqus/Standard FEA: builds models, runs jobs, and autonomously diagnoses and fixes solver failures
abaqus-mcp demonstrates solid naming conventions (verb-first: run_, get_, build_, list_) and comprehensive parameter schemas with types and descriptions. However, tool descriptions vary significantly in quality, some are excellent (run_simulation, autocorrect_simulation), while others are minimal (greeting, check_environment). Output schemas are not explicitly documented in the visible code, and error handling guidance is absent. The server targets a specialized domain (FEA simulation) with domain-appropriate tool composition, but lacks LLM-friendly error recovery patterns and result formatting guidance.
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.
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.
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.
Report whether Abaqus is available and where jobs will run.
Parse the current output files of a job and return a status summary.
Return an example spec that builds geometry parametrically (no CAD file). Also lists the supported shapes and their required params.
Output schemas not documented. Tools return text summaries (e.g., run_simulation returns report.summary() + results block), but LLMs cannot plan downstream calls without knowing the structure of returned data. Documented return types are required for tool chaining.
Error handling lacks recovery guidance. Tools like run_simulation and build_model can fail (convergence, singularity, deck errors) but return only text summaries without actionable next steps. LLMs need explicit guidance: 'Retry with different parameters', 'Call validate_simulation_spec first', or 'Check the .msg file with read_job_file'.
Minimal descriptions on utility tools. 'greeting' (30 chars) and 'check_environment' (50 chars) lack context for LLM selection. Expand to explain when to call them: 'greeting' is not a simulation tool; 'check_environment' should be called first to verify Abaqus availability.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Extract and report headline results (peak von Mises stress, peak displacement, plastic strain / yielding, net reaction force) from a finished job's .odb.
Return an example simulation spec (JSON) showing every field the model authoring pipeline accepts. Fill this in to describe a new simulation.
Return a friendly greeting to the user.
List all jobs under the runs directory.
Return the tail of a job's output file for inspection.
Run a single Abaqus job from an .inp deck and return its status report.
Check a simulation spec (JSON string) against the schema without running anything. Returns 'valid' or a list of problems to fix.
Show release notes for this version or a specific version ('all' for full history).
Tool composition: 'build_and_simulate' combines two responsibilities (build + run + error-correct). While domain-appropriate for convenience, it prevents agents from building without running or running without rebuilding. Consider offering both the combined and split variants.
No pagination or result limits documented. Tools like list_jobs and read_job_file (max_lines=200) have implicit limits, but no documentation of total result count, next_cursor, or guidance on handling large result sets. LLMs cannot plan for truncation.