Prototype · Preview: every server in the official registry, synced every 30 minutes. Reviews and accounts come in a later step.
PopNx MCPMCP servers for people who use AI · explained in plain words

Ottosim — Simulation MCP Server

by ottonicversion 0.3.0i★ –iRuns on your computer
Registry nameio.github.ottonic/simulation-mcp-server

Install

Overview

Description from the maker (original English)

Thermal, structural, modal, DC, and laminar-flow studies from STEP via Gmsh and Elmer.

PopNx MCP’s three pillars

These three are never merged into one score: opinions, measurements and popularity are different things.

What you can do with it

We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.

  • Connection: Runs on your computer
  • Transport: stdio
  • Category: Other

Install

Pick the AI app you use, then copy the settings.

Before you install

  • Basic checks: 1 of 1 passed
  • Runs on your computer with your user’s permissions (files, network, apps).
  • The registry lists no key to fill in.

You need

  • npmNode.js installed (for the npx command)

Which app do you use?

Pick your app above. We remember it, so next time the button says “Install in …”.

Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json

{
  "mcpServers": {
    "simulation": {
      "command": "npx",
      "args": [
        "-y",
        "simulation-mcp-server"
      ]
    }
  }
}

Run this in your terminal

claude mcp add simulation -- npx -y simulation-mcp-server

Open in Cursor

Or copy the settings yourself

Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json

{
  "mcpServers": {
    "simulation": {
      "command": "npx",
      "args": [
        "-y",
        "simulation-mcp-server"
      ]
    }
  }
}

Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.

Open in VS Code

Or copy the settings yourself

Paste into .vscode/mcp.json in your project

{
  "servers": {
    "simulation": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "simulation-mcp-server"
      ]
    }
  }
}

Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.

This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.

Your choice stays on this device in a cookie; no account needed.

These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.

What it can do

Runs on your computer; the tool list appears in your AI app after you install it.

Basic checksi

We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 6, 2026

  • ✓ Pass

    Maker matches the repo

    The registry name was verified with the GitHub account ottonic, which owns the repo

  • … Not checked yet

    Still maintained

    We have not read this repo from GitHub yet

  • … Not checked yet

    Has a licence

    We have not read this repo from GitHub yet

  • – Not applicable

    Endpoint responds

    This one runs on your computer; there is no internet endpoint

  • – Not applicable

    Sign-in with OAuth

    Runs on your computer and uses local settings instead

  • … Not checked yet

    No hidden instructions in tool descriptions

    Runs on your computer; we can only read tool lists from internet endpoints

Compared with others in Otheri

  • More stars than 0% of the other 32466 servers in this category
  • Published to the registry more recently than 84% of the other 32466 servers in this category
  • Basic checks equal to or better than 100% of the other 32466 servers in this category

Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.

Common questions

Is Ottosim — Simulation MCP Server safe?

It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.

What keys or codes does it need?

The registry does not list a required key, though some servers ask you to sign in on first use.

Does it run on my computer or in the cloud?

It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).

Is it still maintained?

The GitHub repo last changed –, and the latest version (0.3.0) reached the registry 6 days ago.

Which apps can use it?

Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Node.js on your computer.

What can I use instead?

In the same category: Spec Driven Development, Remote Desktop Commander, HotCodePush

Alternatives

Servers in the same category from other makers, sorted by stars.

Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi

Spec Driven Development

by formulahendry

MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.

Runs on your computer★ 440MITUpdated 14 months ago
Install

Remote Desktop Commander

by desktop-commander

Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.

Runs in the cloud★ 211Updated yesterday
Install

HotCodePush

by hotcodepush-team

Manage over-the-air (OTA) updates for React Native, Expo, Capacitor and Cordova apps.

Runs in the cloudUpdated today
Install

README from the maker

Open the README

Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.

Ottosim — Simulation MCP Server

Give an AI assistant first-order engineering physics on a real CAD model. This local stdio MCP server carries a STEP file through explicit meshing in Gmsh to a typed study in Elmer — steady and transient thermal, linear static structural, modal, DC conduction, and laminar flow — and returns revisioned results, with no cloud service and no prepared solver input.

Every engineering input is explicit: the materials, boundaries, and mesh are stated, never inferred, and each study, mesh, and result is revision-bound so a number can always be traced back to what produced it.

Qualified against analytic references. Gmsh 4.15.2 and Elmer (devel, most recently released as 26.2.1) complete production-SIF qualifications for every advertised physics — steady and transient thermal, static structural, modal frequency, DC potential, and steady and transient laminar flow — each against an analytic reference with mesh (or timestep) refinement.

Runs on Node 26 / TypeScript 7 against MCP SDK 2.4.0, with a Python Gmsh worker over a one-request/one-response JSON-file protocol (protocol: 1).

Install and launch

Distribution targets match Geometry MCP: Windows x64, macOS ARM64 (Apple Silicon), and Linux x64. Intel macOS, Linux ARM64, and Windows ARM64 are outside the target matrix. CI runs unit/artifact/process checks on these three targets, builds the pinned serial Elmer solver on each target, caches the native install, runs the analytic integration and qualification suites, then packs and smoke-tests the published tarball. This validates native execution; a standalone runtime package is not yet published.

The repository owns its artifact schema in contracts/. Builds bundle that schema and the Python worker; Gmsh and Elmer runtimes are installed separately.

From this directory:

nix develop

just setup just build export SIMULATION_INPUT_ROOTS='["/absolute/path/to/models"]' export SIMULATION_WORKSPACE=/absolute/path/to/run-workspace just start

.envrc already contains use flake; direnv allow is an alternative to nix develop. .env.example documents variables; .env is not auto-loaded. just setup installs npm dependencies without lifecycle scripts. The flake pins nixpkgs (and thus Gmsh) by commit, and pins upstream Elmer by commit. Elmer's transitive inputs use its checked-in lock.

Nix provisions the solver toolchain only on x86_64-linux. packages. .toolchain provisions Node, Gmsh, the Python wrapper and headless upstream Elmer built serially without MPI, OpenMP, ElmerIce or Lua. The analytic thermal benchmark passes with that serial solver. The dev shell also provisions Python, Ruff and Nix tooling; TypeScript language server/formatter/linter/test deps are project-local npm dependencies. Gmsh's Python module lives under its Nix package's lib, supplied through PYTHONPATH. Elmer is an external package, not compiled by npm.

Non-Nix deployments must provide compatible Gmsh Python bindings and native library plus ElmerGrid and ElmerSolver with HeatSolve, FluxSolver, SaveData and ResultOutputSolve modules. Executables are operator configuration:

VariableDefault / meaning
SIMULATION_INPUT_ROOTSRequired JSON array of existing absolute input roots
SIMULATION_WORKSPACE.simulation-runs; local run/artifact storage
SIMULATION_PYTHONpython3 (Windows: python); Nix sets its wrapper
SIMULATION_ELMERGRIDElmerGrid
SIMULATION_ELMERSOLVERElmerSolver
SIMULATION_TIMEOUT_MS120000 per worker/conversion/solve; maximum 3600000

Generic host configuration example (environment may instead be inherited from the Nix shell):

{

"command": "node", "args": ["/absolute/path/to/simulation/dist/src/index.js"], "env": { "SIMULATION_INPUT_ROOTS": "[\"/absolute/path/to/models\"]", "SIMULATION_WORKSPACE": "/absolute/path/to/run-workspace", "SIMULATION_PYTHON": "/absolute/path/to/provisioned/simulation-python", "SIMULATION_ELMERGRID": "/absolute/path/to/ElmerGrid", "SIMULATION_ELMERSOLVER": "/absolute/path/to/ElmerSolver" } }

Study tools

The public workflow is get_capabilities → inspect_model → query_model → validate_study → prepare_study → run_study → inspect_job → query_results. list_jobs recovers recent jobs after context loss and cancel_job stops an active preparation or solver process.

inspect_job accepts waitMs (up to 60 s) and then waits in-process for a terminal state instead of returning immediately, so prepare_study → inspect_job(waitMs) → run_study → inspect_job(waitMs) → query_results is normally five calls rather than dozens of polls. The state is returned whether or not the window expires. A cancelled or timed-out client request stops the mesh or the solve: ctx.signal is forwarded to the job's abort path and the record ends cancelled. Preparation and solver execution return job IDs immediately. Jobs survive client disconnects, not server shutdown. Interrupted jobs are recorded and are not resumed.

get_capabilities reports the available physics and the study shape (required and optional fields, notes, and a worked example); the machine-readable simulation://help resource carries the full study schema — per-physics material and boundary fields with units, regimes, observation quantities with time/mode selectors, enums, and a parseable example. Both are generated from one catalog so discovery cannot drift from the accepted study schema.

steady-thermal, transient-thermal, static-structural, modal, dc-conduction, and laminar-flow are implemented and benchmarked. Other physics reported by get_capabilities remain unavailable, not implied by the fact that Elmer has upstream solvers for them.

Transient studies require explicit density and heat capacity per solid, one uniform initial temperature, a positive timestep, and a step count capped at 10,000. Fixed-temperature, insulated and inward-heat-flux boundaries are supported; time-varying conditions and per-region initial temperatures are not. Transient scalar and VTU results are validated at every step. An observation may select a positive timestep-aligned time in seconds; without time, it observes the final step. Acceptance thresholds remain in the quantity's units (for example, K), not seconds.

Static structural studies require an explicit isotropic Young's modulus and Poisson ratio for every solid, and an explicit fixed-displacement, prescribed-displacement, uniform-traction, or free condition for every surface. The supported model is static, linear-elastic, and small-strain; displacement and stress summaries are unweighted nodal samples, not volume averages.

Modal studies require explicit density in addition to elastic properties, fixed-displacement/free surface assignments, and request 1–20 modes. The first modal implementation reports eigenfrequencies only; it does not expose mode shapes, damping, prestress, or harmonic response. Modal observations select a mode number and use Hz.

DC conduction studies require explicit positive isotropic electrical conductivity per solid, explicit prescribed-potential or insulated conditions on every surface, and at least two distinct prescribed potentials per disconnected conductive component. Results report the nodal potential field; current, Joule heating, magnetic effects, and transient/capacitive behavior are not modeled.

Laminar-flow studies model incompressible Newtonian fluids with explicitly assigned constant density and dynamic viscosity. Every fluid surface must be explicitly assigned either a prescribed pressure or a no-slip wall; each disconnected fluid region needs at least two distinct prescribed pressures. Steady and transient runs are supported; transient runs use first-order BDF, constant timestep, and an explicit quiescent initial velocity. The solver is Elmer's monolithic FlowSolve module; qualification covers pressure-driven square-duct flow and transient startup against the analytic rectangular-duct solution, inlet/outlet flux conservation, and mesh/timestep refinement. Flux and section averages are not exposed; reported velocity and pressure values are nodal extrema. Elmer's segregated IncompressibleNS module is installed but not qualified. Turbulence, compressibility, moving walls, nonzero initial velocity, and thermal/electric coupling are not modeled.

Selections use dimension-qualified inspection entity IDs (for example 3:1 for a volume or 2:7 for a surface), have unique names and cannot mix solids and surfaces. Every inspected entity must be assigned exactly once. Each solid selection needs one material; every surface selection defaults to insulated in thermal studies unless explicitly overridden. Structural, modal, and DC studies require explicit conditions on every surface. A thermal default is a declared engineering assumption, not an inferred boundary condition. The solver uses SI units, but study quantities may be supplied in compatible engineering units (for example mm, in, psi, ksi, lbf, degC) and are converted at the API boundary. Mesh sizes default to metres and accept mm, cm, in or ft through mesh.units. Results are SI by default; an optional displayUnits block (for example { "length": "in", "pressure": "ksi" }) returns observations in the engineer's units. Linear tetrahedra are still the only supported element type.

Material entries may carry an optional reference with the designation, source name/revision, and basis returned by a reference tool such as Standards. The study preserves this caller-supplied context alongside the explicit numeric properties; Simulation does not fetch or verify the source. A typical value remains distinct from a qualified design allowable.

Example steady thermal study after inspecting the STEP file:

{

"schemaVersion": "1", "name": "Bar conduction", "objective": "Estimate the steady temperature and heat flux", "model": { "source": { "revision": "sha256:<64 lowercase hex digits>", "uri": "file:///.../source.step", "format": "step", "units": "mm" }, "inspection": { "revision": "sha256:<64 lowercase hex digits>", "uri": "file:///.../inspection.json", "format": "json" } }, "selections": [ { "name": "bar", "entities": ["3:1"] }, { "name": "hot_end", "entities": ["2:2"] }, { "name": "cold_end", "entities": ["2:3"] }, { "name": "other_faces", "entities": ["2:4", "2:5", "2:6", "2:7"] } ], "mesh": { "minSize": 0.003, "maxSize": 0.006, "elementOrder": 1 }, "physics": { "kind": "steady-thermal", "defaultBoundary": "insulated", "materials": [ { "selection": "bar", "conductivity": { "value": 10, "units": "W/(m.K)" } } ], "sources": [], "boundaries": [ { "selection": "hot_end", "kind": "temperature", "temperature": { "value": 400, "units": "K" } }, { "selection": "cold_end", "kind": "temperature", "temperature": { "value": 300, "units": "K" } } ] }, "observations": [{ "id": "max_temperature", "quantity": "temperature_max" }], "acceptanceCriteria": [ { "observationId": "max_temperature", "operator": "<", "threshold": { "value": 410, "units": "K" } } ], "assumptions": [] }

The example entity tags are illustrative; use tags from query_model and confirm each selection against the actual part. prepare_study returns a jobId; poll inspect_job until it succeeds, then pass its prepared artifact to run_study, which returns another jobId. query_results reports solver evidence sepa

Only the beginning is shown; read the rest in the repo

Ask PopNx