# Arxyne Solver (pypi · arxyne)

Run physics simulations and read their results, from the Arxyne free CLI.

- Trust score: 52/100 (low)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-18

## Components

- pypi · `arxyne`: 52/100 (this document), [markdown](https://verifymcp.io/servers/com-arxyne-solver/arxyne.md), [page](https://verifymcp.io/servers/com-arxyne-solver/arxyne)

## Channel facts

- Registry: `pypi`
- Package: `arxyne`
- Version: `0.7.0`
- Transport: `stdio`

## Trust breakdown

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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-18.

- **Supply Chain Security**: 87/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - Install-script risk not yet assessed.
  - 4 of 54 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 6/100
  - Repository check failed: no source repository is declared.
  - Build provenance not yet verified: this release has too many files to check every attestation, so provenance was not assessed. This is a gap on our side, not a finding about the package.
  - License check failed: the license (BUSL-1.1) isn't a recognized OSI-approved license.
  - Actively maintained (last published 0 days ago).
  - Security-disclosure policy not yet verified: we couldn't inspect the source repository.
- **Schema Quality & AI Usability**: 59/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 1772 tokens (~161/item across 11 items; 11 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 3/100
  - Stability observed for 1 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 67/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "unregister_solver" implies "remove" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 11 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the Arxyne Solver MCP server?

Arxyne Solver runs locally as a PyPI package, launched with uvx arxyne. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add com-arxyne-solver -- uvx arxyne
```

### Cursor

```json
{
  "mcpServers": {
    "com-arxyne-solver": {
      "command": "uvx",
      "args": [
        "arxyne"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-arxyne-solver": {
      "command": "uvx",
      "args": [
        "arxyne"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add com-arxyne-solver -- uvx arxyne
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-arxyne-solver": {
      "type": "local",
      "command": [
        "uvx",
        "arxyne"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-arxyne-solver --command uvx --arg arxyne
```

### Hermes

```yaml
mcp_servers:
  com-arxyne-solver:
    command: "uvx"
    args: ["arxyne"]
```

### Netclaw

```json
{
  "McpServers": {
    "com-arxyne-solver": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "arxyne"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-arxyne-solver -t stdio -c uvx -a arxyne
```

### Other

```json
{
  "mcpServers": {
    "com-arxyne-solver": {
      "command": "uvx",
      "args": [
        "arxyne"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-18 (score 52, +15)

- [security improvement] Malware scan: unverified → pass
- [functional improvement] Stability: unverified → 0.03
- [functional] Package version: 0.6.0 → 0.6.1

### 2026-10-17 (score 37)

First indexed and scored.

## MCP tools (11)

### `list_solvers` (~137 tokens)

List what can run here: every domain, its solvers, and what each can do.

A caller that has never used the CLI starts here. Returns
\``{"domains": [{"domain", "status", "kpis", "default_solver", "solvers": [...]}]}``.
Each solver carries ``alias``, ``name``, ``kind``, ``gpu``, ``differentiable``,
\``tier``, ``version``, ``image``, ``products`` and ``availability``
(``"available"`` everywhere the image is readable on this box, else ``"not present"``).

### `list_products` (~105 tokens)

List the products here: what a ``simulate`` can target, and what can yet be created.

Returns ``{"products": [{"product", "description", "solvers", "held"}]}``.
\``held`` is true when this machine already has the product's twin (so ``simulate``
can run it now); false when a solver image declares the product but it has not been
scaffolded yet. ``solvers`` lists the aliases that can serve it.

### `get_kpi_spec` (~25 tokens)

Return the KPI spec for a solver.

Input parameters:

- `solver` (string, required)

### `get_solver_inputs` (~124 tokens)

Return the declared inputs for a solver — the ``case_yaml`` contract.

\``simulate`` takes ``case_yaml``, a flat ``key: value`` document. This tool
returns the keys that document may hold, each with ``type``, ``default``,
\``path``, ``min``/``max`` and ``description``. Inputs are declared per
product, so pass ``product`` for that product's exact set; omit it for the
union across the solver's products.

Input parameters:

- `product` (string)
- `solver` (string, required)

### `get_product_targets` (~232 tokens)

Return the design-intent targets a run is gated against.

\``get_kpi_spec`` says which KPIs exist and each one's direction. This says
what each KPI must reach for one product. Read it before a run to explain a
gate verdict, and after one so ``kpi_converged`` (which only says whether a
KPI settled) is not mistaken for a target result.

The targets are read with the same producer the gate evaluator uses, so
what this returns is exactly what a run is judged against.

Returns ``{"product", "targets": [{"kpi", "name", "units", "direction",
"kind", "min", "nominal", "max", "value"}]}``. ``kind`` is ``"range"``
when the target carries min/max bounds, else ``"single"``. A ``"range"``
target gates by its bounds; a ``"single"`` target gates by its direction
(minimize: value <= target). An empty ``targets`` list means none are set.

Input parameters:

- `product_name` (string, required)

### `get_product_results` (~237 tokens)

Return a product's latest KPIs, its targets, and the gate verdict.

This is what the CLI prints with ``arxyne results``, as data. An agent reads
it to answer "what is the drag now, and did it pass?" without guessing.

The values and the verdict come from the same producers the CLI uses
(``product.current``, ``product.targets``, ``run_gates``), so an agent and a
person read one answer.

Returns ``{"product", "kpis": [{"kpi", "name", "units", "value",
"target", "benchmark"}], "gates": {"summary", "all_passed", "gates":
[{"kpi", "status", "value", "target_min", "target_nominal", "target_max"}]}}``.
\``value`` is null for a KPI with no saved result yet. Each gate ``status`` is
the CLI's recorded verdict (PASS, FAIL, WARN, INCONCLUSIVE, NOT RUN,
SKIPPED), never a value computed here.

Input parameters:

- `product_name` (string, required)

### `register_solver` (~52 tokens)

Register an external solver from a Docker image.

🚨 SINGLE REGISTRATION PATH. All solver registration routes
through this MCP tool — CLI, onboarding, everything.

Input parameters:

- `alias`
- `image` (string, required)

### `unregister_solver` (~32 tokens)

Remove a user-added solver from the registry. Built-in solvers cannot be removed.

Input parameters:

- `alias` (string, required)

### `simulate` (~163 tokens)

Dispatch a simulation for any domain. Single entry point.

Args:
    case_yaml: the flat input contract, built by the platform.
    geometry: optional ``{input_key: {filename, content_b64}}`` — geometry
        supplied as BYTES rather than as a path, so the caller need not
        share a filesystem with the MCP server and the MCP server need not
        share one with the container. Staged under ``/case/geometry/``
        and referenced from case.yaml by its in-case path.

Input parameters:

- `attribution`
- `case_yaml` (string)
- `domain` (string, required)
- `geometry`
- `nprocs`
- `product_name` (string, required)
- `solver` (string)

### `save_results` (~349 tokens)

Save simulation results to the product's USD twin (prototype or benchmark layer).

Args:
    save_target: "prototype" (default, results layer), "benchmark",
        or "design_intent" (targets only)
    parameters: ``{param_name: {value, default, path, override}}`` —
        overridden params get recorded in resultsHistory as
        ``override_<name>=<value>`` entries.
    only_missing_targets: with save_target="design_intent", skip KPIs
        that already have a target in that layer (idempotent
        population — existing targets are never overwritten).
    converged: False → the run's KPIs are not written to the
        prototype ``arxyne:current:*`` attrs (P1 — unconverged runs
        must not overwrite the last good result). The run is still
        fully traced in resultsHistory + the per-run record.
    tag_baseline: when True (and save_target="prototype"), append a
        baseline-promotion entry to the prototype layer.  All USD
        writes happen here in the MCP server — the CLI never touches
        USD directly.

Input parameters:

- `assumptions`
- `converged` (boolean)
- `domain` (string, required)
- `extra_meta`
- `gates`
- `kpis` (object, required)
- `only_missing_targets` (boolean)
- `parameters`
- `product_name` (string, required)
- `product_params`
- `provenance`
- `run_id` (string)
- `save_target` (string)
- `solver` (string)
- `tag_baseline` (boolean)

### `import_twin_state` (~316 tokens)

Apply a peer's exported twin state to this product's twin. MERGED, never replaces.

THE import path (the twin/USDA channel). A host converges to hold what its peers hold:
each peer's daemon EXPORTS its own twin, and the host APPLIES it here. The session RELAY
carries live CLI calls and is a different channel - an import is not a relay and does not
use one. One writer (this server) applies everything, so the CLI stays the only twin writer.

\``bundle`` is ``{"layers": {name: usda_text}, "history": [raw_line, ...]}``:
  \* each layer text is written under ``layers/imported/<name>.usda`` and added as a WEAKEST
    sublayer - OpenUSD composes strongest-first, so a value this host already holds wins and
    a value only the peer holds is gained. Nothing the host held is lost; the twin is only
    ADDED TO (import_layer_weaker).
  \* each history line is appended, deduped by run pin / timestamp, so two peers running the
    same product + solver both survive as two runs (import_history_entries).

Refuses when the product's twin does not exist: import requires a twin to import INTO
(the same rule as a results write - the caller creates the twin first if the name is held).

Input parameters:

- `bundle` (object, required)
- `product_name` (string, required)

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/com-arxyne-solver/arxyne#diagnostics

## Score history

- 2026-10-18: 52
- 2026-10-17: 37

## Common questions

### What is the Arxyne Solver MCP server?

Arxyne Solver is an MCP server listed in the public MCP registry as com.arxyne/solver. Run physics simulations and read their results, from the Arxyne free CLI. This page covers its PyPI package (arxyne).

### Is the Arxyne Solver MCP server safe to use?

Arxyne Solver scores 52 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 18 October 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 Arxyne Solver MCP server expose?

Arxyne Solver exposes 11 tools: list_solvers, list_products, get_kpi_spec, get_solver_inputs, get_product_targets, and 6 more. Their descriptions and schemas cost roughly 1,772 tokens of context every time the server is loaded.

### Is the Arxyne Solver MCP server still maintained?

Arxyne Solver is still listed as active in the MCP registry. We last reached this channel on 18 October 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 Arxyne Solver MCP server under?

Arxyne Solver declares the BUSL-1.1 licence, which is not on the OSI-approved list. Read the terms before using it at work, and note this covers the source only, not the cost of any service it calls.

## Links

- PyPI project: https://pypi.org/project/arxyne/
- Socket report: https://socket.dev/pypi/package/arxyne
- Changelog RSS feed: https://verifymcp.io/servers/com-arxyne-solver/arxyne.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-arxyne-solver/arxyne.json
- HTML version of this page: https://verifymcp.io/servers/com-arxyne-solver/arxyne