OpenPASO MCP Server

Tools OpenPASO exposes (25)

Listed by the server itself during our scan of commit fd19a85.

• knowledge

  Get knowledge about solvers, physics, materials, coupling, post-mortems, or input formats. START WITH THE INDEX when you want pitfalls and do not yet know what to ask for: `knowledge(topic='pitfalls', solver=..., index=True)` returns a one-screen map — how many entri

• discover

  Discover available solvers and their capabilities. Args: query: What to discover. Options: - "list" — list all solvers with status - "physics" — list all physics types per solver - "capabilities" — full capabilities matrix

• examples

  Find and retrieve example input files from solver test suites. IMPORTANT: Always call this before writing new input files to study real, validated configurations. Args: keyword: Search term (e.g. 'peridynamic', 'fsi', 'poisson', 'heat') solver: Backe

• submit_critic_review

  Put an independent critic's review of a setup ON RECORD, so a run of that setup can be verified. REQUIRED, and the most common mistake: pass EXACTLY ONE of `setup` or `coupling_args`. `setup` is the deck text for run_simulation / run_with_generator / verify_mesh_inde

• run_with_generator

  Run a generator script that creates an input file, then execute the solver. Use this for solvers that need a COMPILED binary or separate input files: - 4C: generator creates .4C.yaml + mesh, then 4C binary runs on them - deal.II: generator creates main.cpp, then cmake + make

• check_input

  Name the defects of an input deck or script BEFORE it runs: the setup checks the run tools apply, as a standalone gate for a code you run yourself (a coupling participant's own deck). For 4C every section name is judged by the INSTALLED binary's own grammar (`4C -p`) and the

• run_simulation

  Run a simulation directly with input content. Use this for Python-based solvers (FEniCS, NGSolve, scikit-fem, DUNE-fem) where the input IS a Python script. The tool routes through the correct Python environment automatically (e.g., conda env for FEniCS). For 4C/deal

• verify_pde_consistency

  Does your field actually satisfy the equation the task stated? The body is shared with couple(), which runs this same check on every converged level when it is handed the four arguments. Two wordings of the invitation to call this tool were measured and both failed -

• verify_interface_flux

  On a COUPLED task: is your interface flux the right sign, and do your two sides actually agree there? Runs on YOUR OWN files, with no reference solution. THIS EXISTED ONLY INSIDE AN INDEPENDENT CHECK UNTIL NOW, which is why it is here. The check below is the one that

• audit_results

  Check your OWN result files for the failures that most often sink a result set — BEFORE you hand it in. Uses only files you produced; no reference solution is involved, so a clean audit means self-consistent, not correct. What it catches, measured on 94 independently

• verify_mesh_independence

  Heuristic mesh-independence study for problems WITHOUT an exact solution: re-run the SAME problem at successively refined resolutions and accept it as converged only if ALL monitored quantities stop changing materially. MMS convergence tests need a manufactured exact

• coupled_solve

  LEGACY cross-solver coupling — FIXED toy geometries only. PREFER `couple`. DEPRECATED: this tool only handles a fixed enum of benchmark problems on a hardcoded unit-square split at x=0.5 (heat_dd/poisson_dd/one_way/tsi_dd/...). For ANY real or non-benchmark coupling use the

• couple

  GENERAL partitioned multi-code coupling — works for ANY physics/coupling. Have an independent critic review the setup before coupling; pass critic_approved=True only after that review (every simulation must be critic-reviewed first). Unlike coupled_solve (legacy, fi

• couple_levels

  EVERY PRESCRIBED MESH LEVEL IN ONE CALL -- the same partitioned coupling as `couple`, run once per level of a task's mesh sequence. Measured over three rounds of recorded runs: six couplings that were proven at level 1 (both codes ran, the iteration converged) never reached

• write_participant_contract

  Write the served participant CONTRACT for `solver` to `path`, solve elided. The file is byte-for-byte the text `knowledge(topic='coupling', solver=..., signal='participant[:<variant>]:part<k>')` serves in parts, concatenated: the contract with its handshake, its checks and i

• couple_precice

  GENERAL preCICE coupling of ARBITRARY codes/paradigms, end-to-end. Have an independent critic review the setup before coupling; pass critic_approved=True only after that review. The standard-library (preCICE) path for cross-code coupling — works for any number of pa

• visualize

  Post-process and visualize simulation results. Args: job_id: Job ID from run_simulation (or leave empty and set work_dir) work_dir: Direct path to results directory action: What to do. Options: - "summary" — field statistics + results_summ

• developer

  Developer tools: architecture, source files, capabilities matrix. Args: action: What to surface. Options: - "architecture" — extension points + source-tree layout for the requested solver - "files" — source-file listing filtered

• prepare_simulation

  Prepare everything needed to set up a simulation — in ONE call. Returns: knowledge + real test file examples + generated template. This eliminates 3 separate tool calls before every simulation. Supports fuzzy matching: e.g. 'magnetostatics' finds 'maxwell', 'thermal

• transfer_field

  Extract field values at an interface from a VTU file and format for transfer. Universal data connector for cross-solver coupling. Reads VTU output from any solver, extracts values at the interface plane, and formats them for the target solver's expected input shape.

• generate_mesh

  Generate a mesh using Gmsh for non-trivial geometries. THE SHAPE IS YOURS TO SET. Each geometry below has DIMENSIONS, and `params` sets them. Without it you get this server's defaults, which are one particular published configuration and almost certainly not the one

• reload_catalog

  Hot-reload the per-backend KNOWLEDGE dicts from disk. Closes a gap one of openPASO's own post-mortems recorded: the MCP server normally imports src/backends/<be>/generators/<physics>.py modules ONCE at startup and never refreshes them, so catalog edits made d

• rediscover_backends

  Probe the system for solver backends and report findings. Searches pip packages, conda environments, common build directories, and source roots. In developer mode, reports git branch and status. Args: confirm: If True, save the discovered config for future sessi

• setup_backend

  Guided backend setup: detect, plan, install, verify, persist. Helps a new user get any of the 8 FEM backends working on THIS machine — picking the fastest install route for the current OS (pip > conda > binary download > source build), executing it, running the backe

• session_insights

  Review knowledge discovered during this session or from saved journals on disk. Two flows are supported: * In-session flow: call ``review`` -> ``approve_all`` / ``reject_all`` during the live MCP session to surface candidates from the current journal and

At a glance

Stars

29

Forks

2

Language

Python

License

MIT

Created

Apr 2026

Last update

Oct 15, 2026

Type

MCP Server

Price

Free

Topics

Questions about OpenPASO

Guides

• How to Install an MCP Server in Claude, Cursor and VS Code
• MCP Server Security: How to Vet a Server Before You Use It
• MCP Tool Poisoning: Malicious Descriptions and Rug Pulls
• Glossary of MCP, skills and agent security terms
• More Learning Resources agents, MCP servers & skills