DualSPHysics MCP
PYPI · DUALSPHYSICS-MCP
Agent toolchain for the DualSPHysics SPH solver: case creation, runs, post-processing, validation.
Available components
Last scanned (1 day ago)
Scores higher than 80% of PyPI servers
Category Health and Science
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
- 1 of 28 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency48
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 40 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability61
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 2384 tokens (~238/item across 10 items; 10 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 10 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 10 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 29 Oct 26 +15
- Malware scan: unverified → pass ▲ security
- 22 Oct 26 0
- Stability: 0.97 → pass security
- 21 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 19 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.
- 18 Oct 26 −15
- Malware scan: pass → unverified ▼ security
- 17 Oct 26 +16
- Malware scan: unverified → pass ▲ security
- 15 Oct 26 −14
- Malware scan: pass → unverified ▼ security
- 12 Oct 26 +2
No change was recorded against any check on this day. Stability & Change Management went from 53 to 67. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 4 Nov 2026 · Analysed pypi/dualsphysics-mcp@0.2.0
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
| Reason | No attestation published |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 28 packages
| Packages resolved | 28 |
|---|---|
| No linked repository | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
check_environment ~86
Probe the DualSPHysics toolchain: paths, versions, solver features. Reports for GenCase / CPU solver / PartVTK / MeasureTool whether each binary was found (env var, PATH or conventional install dirs), its version, and the solver's feature flags (a build without WaveGen cannot run wave cases). Call this first; missing tools come with install hints.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| hint | string | yes | – |
| jobs_dir | string | yes | – |
| jobs_dir_exists | boolean | yes | – |
| missing | array | yes | – |
| omp_threads | integer | yes | – |
| ready | boolean | yes | True when all four tool paths were found |
| server_version | string | yes | – |
| tools | array | yes | – |
No examples provided.
create_case ~735
Create a GenCase case XML (`*_Def.xml`) from a template plus overrides. Pure Python — no solver needed. Designs a 2D dam-break-family experiment in the XZ plane (y pinned to 0) WITHOUT hand-writing XML, with strong parameter validation and a lattice-arithmetic particle estimate to self-check the design before running gencase. The `dambreak_val2d` template reproduces the official validation layout: dp=0.01, 1 m x 2 m water column at the origin, 4 m x 3 m open-top tank, domain (-1, 0, -1)..(4.5, 0, 3.5), TimeMax=2 s, TimeOut=0.01 s, one vertical SWL gauge (x=0.2) and one horizontal (z=0.03). GenCase-measured baseline counts: fluid 20,000 + bound 1,001 = 21,001. Overrides (all optional; unknown keys are DSPH_BAD_INPUT): - dp: float > 0 — particle spacing (m); particle counts scale as dp^-2. - column_length / column_height: floats > 0 — water column at the origin. - tank_length / tank_height: floats > 0 — open-top tank around it. - obstacle: {"x": float, "width": float, "height": float} | null — solid box standing on the tank floor; x must be >= column_length (downstream) and the box must stay inside the tank. Post-processing absolute MK is 11. - margins: {"x_min"?, "z_min"?, "x_max"?, "z_max"?} — domain box = tank expanded by these margins (defaults 1.0 / 1.0 / 0.5 / 0.5 m for splash headroom). All must be > 0: GenCase silently clips geometry that leaves the domain, so the guard rejects anything that could clip. - domain: {"pointmin": [x, z], "pointmax": [x, z]} — explicit domain box (overrides margins); must strictly contain the tank. - time_max / time_out: floats — TimeMax / TimeOut (s); 0 < time_out <= time_max. - gravity, rhop0, cfl, visco: floats — physics constants (defaults 9.81, 1000, 0.2, 0.02 artificial viscosity). - gauges: list of {"type": "vertical", "x": float, "z_top": float?} or {"type": "horizontal", "z": float, "x_end": float?} — SWL probes (vertical: free-surface height at fixed x; horizontal: front position at fixed z). Repla…
| Name | Type | Req | Description |
|---|---|---|---|
| out | string | yes | – |
| overrides | – | – | – |
| template | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| applied | array | yes | Override keys applied (sorted) |
| case | – | yes | – |
| next_step | string | yes | – |
| obstacle_mk_note | – | – | Absolute MKBound id of the obstacle for post-processing |
| out_path | string | yes | – |
| template | string | yes | – |
No examples provided.
describe_case ~122
Summarise a `*_Def.xml` case: geometry, timing, gauges, particle estimate. Read-only self-check loop for case design: reports dp, the domain box, water column / tank / obstacle dimensions, TimeMax/TimeOut, gauges and a lattice-arithmetic particle estimate (fluid/bound/total) to compare with gencase's real counts. Accepts the same 2D dam-break-family vocabulary as edit_case (the official CaseDambreakVal2D layout parses fine).
| Name | Type | Req | Description |
|---|---|---|---|
| path | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| case | – | yes | – |
| obstacle_mk_note | – | – | – |
| path | string | yes | – |
| template | string | yes | Vocabulary the case was recognised as |
No examples provided.
edit_case ~233
Edit an existing `*_Def.xml` with the create_case override vocabulary. Reads the case (must parse as the 2D dam-break family: one fluid drawbox, one tank drawbox, optional obstacle, vertical/horizontal SWL gauges), applies the same overrides as create_case, re-validates the merged case (including the domain-contains-geometry guard) and writes the result. Files that violate the vocabulary (3D domains, multiple obstacles, diagonal gauges, ...) are rejected with DSPH_BAD_INPUT. Args: path: Case XML to edit (with or without .xml suffix). overrides: Same keys as create_case; e.g. {"column_height": 1.5, "obstacle": {"x": 2.5, "width": 0.1, "height": 0.1}}. An empty dict revalidates and rewrites the file in canonical form. save_path: Write the edited case here instead of overwriting path.
| Name | Type | Req | Description |
|---|---|---|---|
| overrides | – | – | – |
| path | string | yes | – |
| save_path | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| applied | array | yes | Override keys applied (sorted) |
| case | – | yes | – |
| obstacle_mk_note | – | – | – |
| path | string | yes | Case XML that was read |
| saved_to | string | yes | Where the edited case was written (path or save_path) |
No examples provided.
gencase ~162
Run GenCase: case XML -> Case.xml + Case.bi4 (+ preview VTK files). Args: xml_path: Path to the *_Def.xml case definition (with or without .xml). output_dir: Output directory (default: <name>_out next to the XML). out_name: Output case name (default: XML stem minus _Def). save_modes: GenCase -save value (default "all" = bi4 + preview VTKs). extra_args: Extra GenCase flags (e.g. ["-dp:0.02"]).
| Name | Type | Req | Description |
|---|---|---|---|
| extra_args | – | – | – |
| out_name | – | – | – |
| output_dir | – | – | – |
| save_modes | string | – | – |
| xml_path | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| bi4_exists | boolean | yes | – |
| command | array | yes | – |
| duration_s | number | yes | – |
| next_step | string | yes | – |
| out_bi4 | string | yes | – |
| out_xml | string | yes | – |
| particle_counts | object | yes | total/fluid/bound particle counts (None = not reported) |
| returncode | integer | yes | – |
| stderr_tail | string | – | – |
| stdout_tail | string | – | – |
| vtk_files | object | yes | – |
No examples provided.
job_status ~83
Poll a background solver job: state + Run.out progress digest. Returns the running state (plus pid/returncode), simulated time vs tmax, percent, step counters, the solver's Time/Sec throughput (wall-clock seconds per simulated second), the solver's own projected finish time, particle counts and the Run.out tail.
| Name | Type | Req | Description |
|---|---|---|---|
| job_id | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| command | – | – | – |
| current_time | – | yes | Simulated time of last PART (s) |
| dirout | – | – | – |
| eta | – | yes | Solver's projected finish date-time |
| eta_note | string | – | – |
| exception | – | – | – |
| finished_at | – | – | – |
| job_id | string | yes | – |
| last_part | – | – | – |
| particles | – | yes | – |
| percent | – | – | – |
| pid | – | – | – |
| poll_hint | – | – | – |
| returncode | – | – | – |
| run_out_exists | boolean | yes | – |
| run_out_tail | string | – | – |
| started_at | – | – | – |
| state | string | yes | running | succeeded | failed | finished |
| steps_last_part | – | – | – |
| tmax | – | – | – |
| total_steps | – | – | – |
| wall_sec_per_sim_sec | – | yes | Solver Time/Sec column: wall-clock s per simulated s |
| wall_sec_per_sim_sec_note | string | – | – |
No examples provided.
measure_tool ~307
MeasureTool: interpolate SPH values at points -> CSV time series. For the dam-break validation use a horizontal line of points just above the bottom (examples/dambreak_val2d/points_damtip.txt) with density (default -vars:-all,rhop): points beyond the surge front read 0, so the furthest wet point is the front position that validate_dambreak compares against the experiment. Args: job_id: Job whose data/ directory holds the Part_*.bi4 files. dirdata: Explicit particle data directory (alternative to job_id). points_file: MeasureTool points file (POINTS/POINTSLIST/POINTSENDLIST). pointsdef: Inline points definition, e.g. "ptels[x=0:0.01:4,z=0.03]". variables: Variables to interpolate (default density only). onlytype: Particle filter (default fluid only). savecsv: CSV output prefix (default measure/damtip inside the job). savevtk: Optional VTK prefix for the measuring points. extra_args: Extra MeasureTool flags (a -csvsep here overrides ours).
| Name | Type | Req | Description |
|---|---|---|---|
| dirdata | – | – | – |
| extra_args | – | – | – |
| job_id | – | – | – |
| onlytype | string | – | – |
| points_file | – | – | – |
| pointsdef | – | – | – |
| savecsv | string | – | – |
| savevtk | – | – | – |
| variables | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| command | array | yes | – |
| csv_files | array | – | – |
| duration_s | number | – | – |
| file_count | integer | – | – |
| next_step | – | – | – |
| output_files | array | – | – |
| returncode | integer | yes | – |
| stderr_tail | string | – | – |
| stdout_tail | string | – | – |
| vtk_files | array | – | – |
No examples provided.
partvtk ~177
PartVTK: convert Part_*.bi4 particle files to VTK for visualisation. Args: job_id: Job whose data/ directory holds the Part_*.bi4 files. dirdata: Explicit particle data directory (alternative to job_id). savevtk: Output prefix (default particles/PartFluid inside the job). onlytype: Particle filter (default fluid only). variables: Variables to store, e.g. "+idp,+vel,+rhop,+press". first/last: Part index range. extra_args: Extra PartVTK flags.
| Name | Type | Req | Description |
|---|---|---|---|
| dirdata | – | – | – |
| extra_args | – | – | – |
| first | – | – | – |
| job_id | – | – | – |
| last | – | – | – |
| onlytype | string | – | – |
| savevtk | string | – | – |
| variables | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| command | array | yes | – |
| csv_files | array | – | – |
| duration_s | number | – | – |
| file_count | integer | – | – |
| next_step | – | – | – |
| output_files | array | – | – |
| returncode | integer | yes | – |
| stderr_tail | string | – | – |
| stdout_tail | string | – | – |
| vtk_files | array | – | – |
No examples provided.
run_case ~228
Start the CPU solver in the BACKGROUND and return a job_id. The case must have been processed by gencase first (Case.xml + Case.bi4). Progress is tracked with job_status; outputs land in the job directory (Run.out, data/Part_*.bi4). Restart/cancel are not implemented; solver flags such as -partbegin:<n> can be passed via extra_args. Args: case_path: Processed case base (gencase out_xml, with/without .xml). dirout: Output directory (default: jobs/<job_id>). omp_threads: OpenMP threads (default: DSPH_OMP_THREADS or all cores). tmax: Override TimeMax (seconds of simulated time). tout: Override TimeOut (seconds between Part files). extra_args: Extra solver flags (e.g. ["-svres"]).
| Name | Type | Req | Description |
|---|---|---|---|
| case_path | string | yes | – |
| dirout | – | – | – |
| extra_args | – | – | – |
| omp_threads | – | – | – |
| tmax | – | – | – |
| tout | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| case | string | yes | – |
| command | array | yes | – |
| data_dir | string | yes | Where Part_*.bi4 files appear |
| dirout | string | yes | – |
| finished_at | – | – | – |
| job_id | string | yes | – |
| omp_threads | string | yes | – |
| pid | integer | yes | – |
| poll_hint | string | yes | – |
| restart_note | string | yes | – |
| returncode | – | – | – |
| run_out | string | yes | Progress log parsed by job_status |
| started_at | string | yes | – |
| state | string | yes | – |
| stderr_log | string | yes | – |
| stderr_tail | string | – | – |
| stdout_log | string | yes | – |
No examples provided.
validate_dambreak ~251
Validate a 2D dam-break run: dam-tip front vs Koshizuka & Oka (1996). Reads the CSV produced by measure_tool with the SAME points definition (columns map to points by order), reconstructs the front position per output time (furthest point above the wetness threshold) and reports per-time errors plus MAE / RMSE / max error in metres and as % of the column length. Args: csv_path: MeasureTool time-history CSV. points: Points [[x, y, z], ...] in CSV column order. points_file: The points file used for the measurement. threshold: Wetness threshold (500 kg/m^3 for rhop; ~0.05 for vel). column_length: Water column length a in metres (normalisation). experiment: Embedded experiment (koshizuka1996). max_time: Ignore simulated samples beyond this time (s).
| Name | Type | Req | Description |
|---|---|---|---|
| column_length | number | – | – |
| csv_path | string | yes | – |
| experiment | string | – | – |
| max_time | – | – | – |
| points | – | – | – |
| points_file | – | – | – |
| threshold | number | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| column_length_m | number | yes | – |
| experiment | string | yes | – |
| experiment_reference | string | yes | – |
| front_series | array | yes | – |
| impact_time_s | – | – | When the front plateaued at the tank end (wall impact), if it did |
| mae_m | number | yes | – |
| mae_pct_of_column | number | yes | – |
| max_abs_error_m | number | yes | – |
| n_samples | integer | yes | – |
| notes | – | – | – |
| rmse_m | number | yes | – |
| threshold | number | yes | – |
No examples provided.
How do I install the DualSPHysics MCP server?
DualSPHysics MCP runs locally as a PyPI package, launched with uvx dualsphysics-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · dualsphysics-mcp
claude mcp add vegetableno1-dualsphysics -- uvx dualsphysics-mcp
What is the DualSPHysics MCP server?
DualSPHysics MCP is listed in the public MCP registry as io.github.vegetableno1/dualsphysics. Agent toolchain for the DualSPHysics SPH solver: case creation, runs, post-processing, validation. This page covers its PyPI package (dualsphysics-mcp).
Is the DualSPHysics MCP server safe to use?
DualSPHysics MCP scores 80 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 4 November 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the DualSPHysics MCP server expose?
DualSPHysics MCP exposes 10 tools: check_environment, create_case, edit_case, describe_case, gencase, and 5 more. Their descriptions and schemas cost roughly 2,384 tokens of context every time the server is loaded.
Is the DualSPHysics MCP server still maintained?
DualSPHysics MCP is still listed as active in the MCP registry. We last reached this channel on 4 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the DualSPHysics MCP server under?
DualSPHysics MCP declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.