Arxyne Solver

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

Connector by arxyne.com · Domain verified by the MCP Registry

IndexedLicense unknownLocal (stdio)

Install

Works with Claude Code, Codex, VS Code, Cursor, Windsurf, Claude Desktop. Read the repository before you give any tool access to your data.

npx agentmarket install connector/arxyne-com-solver

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

About

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

Use cases: data-analysis

Reviews

Write a review

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this server can do and what it asks for, from its tool list and install config. Checked Oct 25, 2026.

Tools: 19 read · 7 write · 1 delete · 3 not yet classified
Secrets: None asked for
Install scripts: Not scanned yet
Runs as: Python package

Tools by what they do 30

Read from the source code; the running server may list different tools.

Read 19 · Look things up without changing anything.

diff_releases
export_twin_state
get_baseline_history
get_coverage
get_doctor
get_kpi_spec
get_product_info
get_product_params
get_product_results
get_product_targets
get_release
get_solver_fidelity

Show 7 more tools

get_solver_info
get_solver_inputs
list_products
list_releases
list_solvers
list_tests
search_public_solvers

Write 7 · Create, change, send or run things.

assess_release
create_product
freeze_product_release
import_twin_state
register_solver
save_results
update_solver_tiers

Delete 1 · Delete, drop, revoke or wipe things.

unregister_solver

Not yet classified 3 · We could not tell from the name and description.

clean_product_history
pull_solvers
simulate

Tools (30)

Read from the source code; the running server may differ. Descriptions are the server’s own words; hidden characters are shown as [U+…].

assess_release
Assess one release's KPIs against a regulation, per requirement. This is what the CLI prints with ``arxyne assess``, as data. The verdict per requirement comes from the one producer ``core/certification.check_release``.
clean_product_history
Deduplicate and trim a product's run history. What ``arxyne clean-history`` does, as a call. Full parity: an agent may trim history, not only read it. ``keep_days=0`` wipes the history plus the current KPI and provenance attributes. The one producer ``core/usd_product.clean_history``; this tool does not edit the USD itself.
create_product
Create a new product (programme) twin, scaffolded from the solver contract. What ``arxyne onboard`` does when it scaffolds a product, as a call. Full parity: an agent may create a product, not only read it. The scaffold is solver-driven - the domain is written to ``design_intent`` and the first run derives the rest from the solver's own defaults - built by the one producer ``core/onboarding.create_programme``. Refuses a name that is not a valid identifier. An existing product is reported as ``status: existing`` with its path, never re-scaffolded.
diff_releases
Return what changed between two releases, and which layer authored each change. This is what the CLI prints with ``arxyne release-diff``, as data.
export_twin_state
Read a product's twin as a bundle that ``import_twin_state`` accepts. The inverse of import. ``import`` applies ``{"layers": {name: usda_text}, "history": [raw_line, ...]}``. Until this tool existed the CLI offered the import and no way to produce the file, so the command pointed at a bundle the user could not make. Layer text is the SUBLAYER FILE verbatim, not the composition: an export carries what this host holds, and composing would bake this host's values into the receiving side's layers. The canonical layer names are kept, so a bundle round-trips back to where it came from. The one pr…
freeze_product_release
Freeze this machine's product state as an immutable release. What ``arxyne freeze <version>`` does, as a call. Full parity: an agent may freeze a release, not only list one. Captures the composed values plus each input layer beside the product as ``releases/<version>.usda``, through the one producer ``core/releases.freeze_release``. A version that already exists is refused: a release is immutable.
get_baseline_history
Return a product's baseline-promotion audit trail, oldest first. This is what the CLI prints with ``arxyne baseline-history``, as data. Each entry records a baseline promotion (timestamp, git commit, domains, summary). Read through the product's own reader, the same one the CLI calls.
get_coverage
Return the product x solver coverage matrix and the solver inventory. This is what the CLI prints with ``arxyne coverage``, as data: which solvers can run which product, the products common across several solvers (the cross-solver anchors), and one inventory row per registered solver. Schema-driven from the images, from the one producer ``core/solver.coverage_matrix``. A solver whose image is not on this box claims no coverage.
get_doctor
Return this machine's pre-flight checks, as data. What ``arxyne doctor`` prints, so an agent can answer "why will a run not start" without guessing: Python, USD, Docker, workspace, CPU, GPU, layer composition, the LLM backend, one verdict per solver image, resource fit, contract conformance on images already on disk, and the persistent services. From the one producer ``core/doctor_checks`` - the CLI renders the same checks. The two checks that need a door (contract conformance spawns a subprocess per solver; services start and inspect containers) run here, on the server, which is where they …
get_kpi_spec
Return the KPI spec for a solver.
get_product_info
Return a product's summary: identity, layer stack, physical, bindings, recent runs. This is what the CLI prints with ``arxyne info``, as data. Read it to learn how a product is composed (its USD layers, strongest first) before a run, or to see the values a run will use. The whole view comes from ``core/product_views.info_view``, the same producer the CLI renders, so an agent and a person read one answer.
get_product_params
Return a product's design parameters and its KPI targets. This is what the CLI prints with ``arxyne params``, as data. The rows carry the RAW keys the design_intent layer holds, so an agent sees which fields exist rather than a renamed table. From the one producer ``core/product_views.params_view``, the same one the CLI renders.
get_product_results
Return a product's latest KPIs, its targets, the gate verdict and recent runs. 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 whole view is built once, in ``core/product_views.results_view``, and returned verbatim: the CLI renders this same dict. Returns ``{"product", "last_updated", "kpis": [{"kpi", "name", "units", "value", "target", "benchmark"}], "gates": {"summary", "all_passed", "rows", "coverage", "attestation"}, "history": [...]}``. ``gates.rows`` are the gate engine's own record…
get_product_targets
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 `…
get_release
Return one frozen release's recorded facts. A READ: the release's metadata and composed attribute snapshot, no model call and no verdict. ``assess`` reads this over MCP and then asks the model itself, so the egress confirmation stays with the caller that makes the call.

Show 15 more tools

get_solver_fidelity
Return a product's declared fidelity levels — what ``--fidelity`` accepts. Fidelity is HOW ACCURATE a run is (mesh density, element density, timestep). A scenario test is WHAT the run is. They answer different questions with different flags, and a contract never sets the same parameter in both. Pass ``simulate(..., fidelity="high")`` to apply one. Omit ``product`` to ask which products declare fidelity at all; a level is resolved per product, because the knob differs by product (a snappy cell budget for aerodynamics, a cell count for a thermal cavity). From the one producer ``core/solver.ge…
get_solver_info
Everything declared about one solver: its image, version, tier and scope. ``list_solvers`` is the menu; this is the dish. Use it when choosing between two solvers for a run, or when explaining why one cannot run here. ``availability`` says whether the image is readable on this box, so a caller can tell "not installed" from "not supported". Returns the solver's own record, read by the same producer the CLI's ``arxyne solver info`` uses. An unknown alias is an error naming the ones that exist, not an empty object: an empty answer reads as "a solver with no properties", which is a different fac…
get_solver_inputs
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. The union comes from ``core.solver.union_solver_inputs`` — the same producer the enterprise surface calls, so the two doors cannot disagree about which keys a solver takes.
import_twin_state
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 …
list_products
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.
list_releases
Return a product's frozen releases, oldest first. This is what the CLI prints with ``arxyne releases``, as data. A release is the product's state frozen at a point in time, an immutable record.
list_solvers
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_tests
Return every scenario test declared by every registered solver. This is what the CLI prints with ``arxyne tests list``, as data: the cross-domain catalogue of declared tests. From the one producer ``core/solver.tests_catalog``.
pull_solvers
Pull solver images onto THIS machine. What ``arxyne pull`` does, as a call: an agent that finds a missing image (via ``get_doctor``) can fetch it instead of reporting a dead end. Omit ``aliases`` to pull every image-backed solver; pass names to pull only those. The download is large and can take a long time, so this is deliberately explicit rather than implied. Returns ``{"pulled", "failed", "skipped"}``: ``skipped`` names endpoint- hosted solvers, which have no image. Runs ``core/doctor_checks.pull_solvers``, which uses the one pull primitive, so platform resolution (a single-arch image on…
register_solver
Register an external solver from a Docker image. 🚨 SINGLE REGISTRATION PATH. All solver registration routes through this MCP tool — CLI, onboarding, everything.
save_results
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 K…
search_public_solvers
The public community solver directory: what exists that you have not installed. Read-only and never touches local state. A solver listed here is not installed; ``register_solver`` adds one, ``get_solver_info`` describes what is already here. Returns ``{"status", "solvers": {alias: {...}}}``, or an error when the registry cannot be read. A registry that is down is reported as an error rather than an empty directory: "nothing is published" and "I could not ask" are different answers, and only one of them should stop a caller looking.
simulate
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. fidelity: ``low``, ``standard`` or ``high`` — HOW ACCURATE the run is. Applied before ``case_yaml``, so a ke…
unregister_solver
Remove a user-added solver from the registry. Built-in solvers cannot be removed.
update_solver_tiers
Refresh the tier of installed solvers from the public registry. A tier is reputation, not capability, and only Arxyne awards ``validated``. This syncs what the registry knows onto solvers this host already has; it never adds a solver and never changes a solver's configuration. Returns the producer's own result: which tiers changed and which were already current.

Signals

Weekly downloads: 16,405
Last release: Oct 26, 2026 (4 days ago)
Last package publish: Oct 24, 2026 (6 days ago)

From the package registry.

Details

Registry name: com.arxyne/solver
Version: 0.10.11
Auth: No auth
Packages: pypi arxyne
License: License unknown
First seen: Oct 24, 2026
Last checked: Oct 26, 2026
Source: Official MCP Registry

Cite this page

Arxyne Solver MCP server. Agent Mart. https://agentmart.dev/connectors/arxyne-com-solver (last updated 2026-10-26)