Plasma-trace

Inspiration

Sub-centimetre orbital debris is a genuinely unsolved problem. Objects this small are difficult to track with radar or optical systems, yet at orbital velocities they carry enough energy to damage spacecraft.

NASA-funded research has been exploring an indirect approach: a charged fragment moving through ionospheric plasma can excite nonlinear waves — solitons — that might be detectable even when the object itself is not. The physics comes from Sen et al. (2015) on forced-KdV soliton excitation by charged orbital debris, developed further in Christine Hartzell's NASA NIAC work at the University of Maryland.

I did not invent that science, and this project does not claim to. What interested me was a different question: exploring a model like this means sweeping parameters — size, velocity, altitude, day/night ionosphere — and that is exactly the kind of tedious, click-heavy loop where a human and an agent should be able to work on the same instrument instead of in separate tools.

What it does:

Plasma-trace is a browser-based forward model for debris detectability. Set a fragment's size, relative speed, and altitude, pick a daytime or night-time ionosphere, and it returns a detectability score plus a breakdown across eight altitude bins.

The point is that there are two ways to drive it, and they are the same instrument:

A person drags sliders and watches the chart redraw.
An AI agent calls WebMCP tools registered on the page — and the sliders and chart move exactly as if a person had dragged them.

Why WebMCP is a strong fit:

Scientific parameter exploration is a bad fit for the usual ways agents interact with web pages. Screen-scraping a slider is fragile and lossy: an agent reading "38/100" off the DOM has a rendered string, not a result it can reason over.

WebMCP changes the contract. The page exposes typed tools with schemas, so the agent calls a function and gets structured data back, while the human sees the same state update visually. Neither operator is second-class. That is what makes this feel like a shared instrument rather than an agent puppeting a UI built for someone else.

What people and agents can do together that was difficult before:

The clearest example is sweep_altitude. A person exploring where a 5 mm fragment is most detectable has to drag the altitude slider through eight positions and read the chart each time. An agent runs the whole sweep in one call and returns the best altitude with the full profile — while the human watches the same chart update.

Before WebMCP, that meant either building a separate API (and now the human and agent are using different systems that can drift apart) or having the agent scrape the UI (fragile, and it gets strings instead of data). Here there is exactly one code path.

explain_regime is the inverse case: the agent asks the instrument to explain why detectability peaks where it does, so the reasoning comes from the page's own model rather than the language model's guess.

How I built it:

One self-contained index.html — no backend, no database, no build step. Chart.js from a CDN is the only dependency.

runForwardModel() computes detectability from an altitude-dependent plasma density term, a size factor, and a speed factor.
The sliders call that function directly.
Four tools are registered with document.modelContext.registerTool(): set_debris_params, run_forward_model, sweep_altitude, and explain_regime. Each one calls the same functions the sliders call and updates the same chart. There is no parallel agent code path — that constraint is the whole design.
The page feature-detects document.modelContext and degrades gracefully: in a non-WebMCP browser it shows a banner explaining how to enable it, and every slider still works.

Challenges:

The WebMCP API is new enough that several third-party guides describe it incorrectly — a number of them say navigator.modelContext when the spec defines document.modelContext. Writing that line from memory or from a blog post would have produced a page that looks completely normal and silently registers nothing. I sourced the signature from the W3C explainer and cross-checked it against the spec IDL.

A second one: executeTool takes its arguments as a JSON string, not an object. Passing an object returns "Failed to parse input arguments" with no further detail. Worth knowing if you are testing via navigator.modelContextTesting in the console.

What's real, and what isn't

I would rather be precise about this than oversell it.

Real: the forward model runs in-page, the WebMCP registration is functional, the deploy is live, and agent tool calls demonstrably move the same sliders and chart a person uses.

Simplified: the ionosphere data is hardcoded. The model uses closed-form terms, not a plasma solver. Nothing here is validated against observations.

Not claimed: this does not detect debris. It is not an early-warning system — solitons propagate near the ion-acoustic speed while debris moves far faster, so this is a mapping and survey concept, not a collision alarm. The science is attributed to published research.

The contribution I am putting forward is the interaction pattern: a scientific instrument that a human and an agent operate through one shared set of functions.

What's next

Real ionosphere data (IRI or GNSS TEC) instead of hardcoded values, a trained ML model for the inverse problem — recovering fragment properties from an observed signature, which is not analytically solvable and is exactly what the NIAC team is working on — and multi-sensor localisation.