# Reported issues for HYRR

Pod holds 19 of 24 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to [HYRR](/mcp/hyrr).

## Most discussed

### spike: one version identity for the MCP surface (and settle the cargo install channel)

**Spike.** Design decision, not a bug fix. #599 is the symptom; this is the shape that produced it.

## Motivation

ADR 0001 committed HYRR's MCP to *one Rust SSoT, thin entry points, drift architecturally impossible*, guarded by a byte-for-byte parity test across all three entry points. That worked: tool logic has genuinely not drifted.

**Version identity was never brought under that principle.** Three numbers claim to be "the version of HYRR's MCP", and which one you see depends on how you…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/603) · 2026-08-13 · open · outside contributor · 3 comments

### MCP browser link (#config=) drops custom-alloy composition (+ density overrides + secondary_neutron) → online view can't reproduce the run

## Summary
The `simulate` MCP tool returns a **"View in browser" `#config=` link**, but for any run that uses a `define_material` **custom alloy**, the encoded config stores only the material **name** — not its composition. The online app has no such (session-scoped) material, so the link renders a different/broken run. "Incl. the impurities" is exactly what's silently lost.

## Repro
1. MCP `define_material` — an 11-element alloy, e.g. `alsi10mg` (Al bal, Si 10, Fe 0.55, Mn 0.45, Cu/Ni 0.05,…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/531) · 2026-07-20 · closed · outside contributor · 3 comments

### hyrr-mcp: auto-fetch data on first invocation

## Problem

`hyrr-mcp/src/main.rs` calls `data_dir::resolve()` (a pure read-only path lookup) and bails if nothing is found. The auto-download logic exists (`core/src/data_fetch.rs` — `ensure_meta_stopping()`, `ensure_library()`) but is only wired into the Tauri desktop binary's `seed_cache_from_resources()` + `ensure_data()` command — not the MCP entrypoint.

This means `uvx hyrr-mcp` is **not** one-shot installable. Users must manually pre-populate `~/.hyrr/nucl-parquet/` or set `HYRR_DATA`,…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/245) · 2026-05-20 · closed · outside contributor · 3 comments

### hyrr-mcp reports version 0.1.0 — py-mcp/Cargo.toml is never bumped

## Problem

The published `hyrr-mcp` package reports the wrong version to users:

```console
$ uvx hyrr-mcp@0.19.0 --version
hyrr-mcp 0.1.0
```

Every release since the package existed reports `0.1.0`. Confirmed against the
live PyPI artifact:

```console
$ uvx --from hyrr-mcp==0.19.0 python -c \
    "import importlib.metadata as m, hyrr_mcp; \
     print('dist:', m.version('hyrr-mcp')); print('native:', hyrr_mcp.__version__)"
dist:   0.19.0
native: 0.1.0
```

The distribution metadata is…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/599) · 2026-08-06 · closed · outside contributor · 2 comments

### Spike: settle the TLS backend + CI runner strategy behind the aarch64 wheel failure (#461)

## Motivation / why

`release-hyrr-mcp.yml`'s `linux-aarch64` leg has **failed on every recent release** — including the ones we called successful:

| run | tag | `build (linux-aarch64)` | published aarch64 wheel? |
|---|---|---|---|
| 29368972044 | `hyrr-mcp-v0.18.0` | ❌ failure | no |
| 28085072023 | `hyrr-mcp-v0.17.0` | ❌ failure | no |
| 28068952086 | `hyrr-mcp-v0.16.3` | ❌ failure | no |

PyPI confirms it — `hyrr-mcp` 0.18.0 ships exactly four files:

```…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/573) · 2026-08-06 · closed · outside contributor · 2 comments

### MCP: structured data export (parquet/JSON) for full simulation inventory

## Problem

The MCP tools currently return markdown tables, lossy and per-tool. For any analysis beyond a single isotope I have to make many round trips and re-assemble in Python.

### Concrete example from a recent session

To compute F-18 + Sc-44 joint activity over a 24-h cooling tail with contaminant tracking and 511 keV purity, I had to:

- `get_isotope_production_curve` once per isotope (F-18, Sc-44, Sc-43, Sc-47, Sc-48) — 5 calls, 100 markdown rows each, parsed by hand
- `get_decay_data`…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/427) · 2026-06-01 · closed · outside contributor · 2 comments

### feat: offline-first data distribution — user stories + installer variants

## Problem

No single install path gives users a "download once, work offline forever" experience. The current tiers:

| Distribution | Data bundled | First-run download | Full offline? |
|---|---|---|---|
| **Hosted frontend** | Static CDN assets | 0 (browser fetches per-file) | Only with browser cache |
| **Tauri desktop** | meta+stopping (320 MB in installer) | XS library ~50 MB on first sim | Partial — depth preview yes, simulation no |
| **hyrr-mcp** | Nothing | Not wired (#245) | No |
|…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/264) · 2026-05-21 · closed · outside contributor · 2 comments

### natMg(p,x)24Na @ 17.8 MeV: TENDL-2025 evaluation ~10^4-10^5x below measured (EXFOR) cross-section — webapp vs. hyrr-mcp disagree on same data version

## Motivation / why

Reproduction: `p` at 17.8 MeV, natural Mg, 2 mm target, 20 µA, 1h irradiation, 1h cooling.

- **hyrrprd.ethz.ch (v0.20.1, data 2026.8.2)**: Na-24 via `25Mg(p,2p),26Mg(p,2pn)` — EOB 4.337 MBq, Sat. Yield 4.79 MBq/µA.
- **hyrr-mcp v0.20.1 (same reported data version, 2026.8.2)**: same beam/stack — Na-24 EOB ≈ 54 Bq, Sat. Yield 59.7 Bq/µA (24h-cooling activity 17.8 Bq).

Same code version, same pinned nuclear-data version, but the two surfaces disagree by **~80,000x** on this…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/669) · 2026-08-20 · open · outside contributor · 1 comment

## Most recent

### projectile 'n' without neutron_flux silently runs a 1e13 fission-fast default — not echoed in output (silent-default class, cf. #712)

## Summary

A `projectile: "n"` call that omits `neutron_flux` silently runs a **fission-fast spectrum at 1e13 n/cm²/s** (`parse_neutron_flux` → `FluxModel::Fast { flux: 1.0e13, temp_mev: 1.4 }`). The response never states which spectrum or flux was used. The numbers look plausible and are off by orders of magnitude. This is the same silent-default class as #712, but it survived because the default is intentional ("so the run still produces a sensible result rather than erroring").

## How I…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/725) · 2026-09-28 · open · outside contributor · 0 comments

### Layer density_g_cm3 override never applies to materials without a built-in density (resolve_material called with density_override=None): Tc, CaCO3, etc. error out

**Component:** hyrr-core `mcp/tools.rs`: layer parsing (`:1182`, `:1313`) and `tool_get_stopping_power` (`:1912`)
**Version:** hyrr-mcp 0.21.1 (= `main` @ 01a34a8)
**Type:** bug. The documented override never gets a chance to apply, and the error message recommends a fix that doesn't work.

## TL;DR

The layer schema documents `density_g_cm3` as *"Override density [g/cm3] for this layer. Replaces the material's resolved density."* For any material hyrr has no built-in density for, the override…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/713) · 2026-09-28 · closed · outside contributor · 0 comments

### Unknown tool-argument keys silently ignored + undocumented 0.1 cm thickness default: thickness_mm gives a 10× thick target with no warning

**Component:** hyrr-core `mcp/tools.rs`: argument parsing for `simulate` and the stack-shaped tools
**Version:** hyrr-mcp 0.21.1 (= `main` @ 01a34a8)
**Type:** bug. Silent input handling produces confidently wrong physics.

## TL;DR

Unknown keys are silently ignored at every level of the tool arguments. Combined with an undocumented default thickness, a unit-mistaken or misspelled field gives a plausible-looking but wrong result with no warning. The tool schemas declare no…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/712) · 2026-09-28 · closed · outside contributor · 0 comments

### Thermal neutron spectrum uses the Maxwellian density shape as flux: thermal (n,γ) over-predicted ~26% (4/π for 1/v)

**Component:** hyrr-core `neutron.rs::FluxModel::phi` (Thermal), consumed by `neutron_channel_rate`
**Version:** hyrr-mcp 0.21.1 (= `main` @ 01a34a8)
**Type:** bug. Physics: thermal (n,γ) production is over-predicted by ~26% (4/π for a pure 1/v absorber).

## TL;DR

`FluxModel::Thermal` is documented and implemented as

```
φ(E) = flux·(2/√π)·√E/kT^{3/2}·exp(−E/kT)        // neutron.rs:40, :71–77
```

That is the Maxwellian **density** distribution, n(E) ∝ √E·e^{−E/kT}, normalized to integrate…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/711) · 2026-09-28 · closed · outside contributor · 0 comments

### ensure_library never fetches the routed neutron / heavy-ion libraries (endfb-8.0, hi-xs-prod): n and heavy-ion runs silently empty out of the box

**Component:** hyrr-core `data_fetch.rs::ensure_library`. Callers: `hyrr-mcp/src/main.rs:111`, `py/src/lib.rs:460`, `py-mcp/src/lib.rs:83`
**Version:** hyrr-mcp 0.21.1 (= `main` @ 01a34a8)
**Type:** bug. Silent, physics-relevant: neutron and heavy-ion runs are empty out of the box.

## TL;DR

`library_for_projectile()` (`core/src/db.rs:33`) routes neutrons to `endfb-8.0` and heavy ions to `hi-xs-prod`. But on a cold cache, `ensure_library(library)` extracts only `MANDATORY_PREFIXES` plus…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/709) · 2026-09-28 · closed · outside contributor · 0 comments

### Disk stack-result cache key omits data identity: an empty result computed on incomplete data outlives the data fix

**Component:** hyrr-core `mcp/cache.rs` (disk tier, #568)
**Version:** hyrr-mcp 0.21.1 (= `main` @ 01a34a8)
**Type:** bug. A silently wrong result survives the fix to its cause.

## TL;DR

The on-disk stack-result cache (`~/.cache/hyrr/stack-results/`) is keyed on `CACHE_SALT | library | registry_fp | args`. The key doesn't include the **data**: not the resolved data root, not `DataSource`, not the data release or `data_sha256`. So a result computed against incomplete data keeps being served…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/708) · 2026-09-28 · closed · outside contributor · 0 comments

### feat(mcp): list hyrr-mcp in the official MCP Registry so agents can discover it

## Problem

`hyrr-mcp` is on PyPI (0.21.1) and works via `uvx hyrr-mcp`, but nothing lets an agent *find* it: `registry.modelcontextprotocol.io/v0/servers?search=hyrr` returns 0 servers. There is no `server.json`, no `mcp-name` ownership marker on PyPI, and no publish step. Every MCP client or directory that browses the official registry (or one of its mirrors) is blind to it; the only discovery path is a human reading our README.

## Plan

- `py-mcp/server.json`: name…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/706) · 2026-09-28 · closed · outside contributor · 0 comments

### secondary_neutron: downstream layer shows no neutron-induced activation (silent, e.g. Al-27(n,α)Na-24 behind a Be converter)

**Component:** hyrr-mcp / hyrr-core, `secondary_neutron` (ADR-0003 Phase 2)
**Version:** hyrr-mcp 0.20.1 (latest release as of filing), `tendl-2025` library
**Related:** #513 (Phase 2 tracker — claims "Secondary source magnitude ✅ E_p-dependent — folded from `(x,n)` xs against the degrading proton energy per layer"), #590 (explicitly lists "secondary-neutron" as one of three untested MCP paths where "a regression would be silent")
**Type:** bug (silent, physics-relevant under-reporting)

##…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/668) · 2026-08-19 · closed · outside contributor · 1 comment

### Data releases are not detected the way software releases are — and release-notes.json reports the wrong data_version for 0.19.0

## Short answer: no. A new **data** release is not noticed the way a new **software** release is.

Asked while tracing what `uvx hyrr-mcp` actually pulls. The two update paths are not symmetric, and one of them is currently reporting a wrong value.

### Software releases — actively detected

`core/src/update_check.rs` fetches `latest.json` from GitHub Releases (24 h cache TTL, 5 s timeout, `HYRR_DISABLE_UPDATE_CHECK` opt-out) and compares it to `hyrr_core::VERSION`. When newer,…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/606) · 2026-08-13 · open · outside contributor · 1 comment

### MCP: relative activity clamp (~1e-6 × peak EOB) silently drops long-lived minor-component products from the inventory

**Component:** hyrr-mcp / hyrr-core inventory step
**Version:** hyrr-mcp 0.18.0, data bundle `nucl-parquet-data-2026.7.1`, library `tendl-2023-iso`
**Related:** #130 (clamp negligible values — likely the origin), #528 (silent under-reporting)
**Type:** bug (silent, physics-relevant under-reporting)

## TL;DR

The inventory step drops any produced isotope whose **EOB activity is below ~1×10⁻⁶ of the run's peak isotope EOB activity**. The threshold is **relative to the peak, not absolute**, and…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/533) · 2026-07-21 · closed · outside contributor · 0 comments

### hyrr-mcp 0.18.0 auto-fetch broken: compiled DATA_VERSION `v0.15.0` (SemVer) has no matching CalVer data release → silent stopping/xs failure

## Summary
On **hyrr-mcp 0.18.0**, running **without** a pinned `--data-dir` (i.e. relying on auto-fetch) fails. The binary resolves `HYRR_DATA_VERSION = v0.15.0` and tries to fetch `nucl-parquet-data-v0.15.0`, but the nucl-parquet **data releases use CalVer** (`data-2026.7.1`, `data-2026.6.1`, …) — there is **no `v0.15.0` data release**. It pulls a little metadata into `~/.nucl-parquet/v0.15.0/` but can't get the parquet files, then errors on the first query.

## Repro
1. Config: `uvx --from…

[Read the thread](https://github.com/exoma-ch/hyrr/issues/529) · 2026-07-17 · closed · outside contributor · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/exoma-ch/hyrr/issues).