VIYAN is a hackathon-built space traffic management project that exposes satellite tracking, conjunction detection, and collision-risk scoring as MCP tools. Built on the NitroStack SDK, it lets an AI assistant walk from raw orbital data to a recommended avoidance maneuver inside one conversation instead of a separate monitoring dashboard.
What this enables
- Chains six MCP tools from tracked satellites through to a recommended maneuver
- Scores collision probability with a scikit-learn model rather than a distance-only threshold
- Separates read-only satellite and conjunction data from the risk-analysis and negotiation tools
- Keeps orbital mechanics and ML prediction in a Python backend behind a typed MCP surface
Why a dashboard wasn't the interesting part
Low Earth orbit is getting crowded, and most space traffic tooling still works the way it did a decade ago: a monitoring system tracks known objects and raises an alert when two of them are predicted to pass close together. The operator then has to interpret that alert, weigh it against everything else on their console, and decide what to do. VIYAN's builders frame this as a reactive-monitoring problem: the system tells you something is wrong, but it doesn't help you decide what to do about it before it happens.
The team built VIYAN for an MCP hackathon around a narrower claim: an AI assistant with the right tools can move from raw telemetry to a recommended maneuver in the same pass, and the mechanism that makes this safe is a set of explicit, typed tool calls rather than a single black-box "AI recommendation."
Why collision risk needed more than distance
A closest-approach distance is easy to compute and hard to act on. Real avoidance decisions weigh factors a simple proximity check ignores, such as which mission a satellite serves, what maneuvers its orbit actually allows, and how confident the underlying trajectory prediction is. VIYAN's backend runs orbital propagation with Skyfield, then hands the resulting conjunction data to a scikit-learn model that estimates collision probability instead of a single fixed threshold. That two-step split, deterministic orbital mechanics first and a learned probability estimate second, is the constraint the rest of the architecture is built around.
Turning the workflow into MCP tools
VIYAN's MCP server, written in TypeScript with the NitroStack SDK, exposes the simulation and prediction backend as six tools rather than one combined "analyze" endpoint:
Tool
Description
run_simulation
Executes the full collision simulation
get_satellites
Retrieves tracked satellites
get_conjunctions
Detects satellite conjunctions
assess_risk
Assesses collision risk
predict_collision
Predicts collision probability
negotiate
Recommends an avoidance maneuver
The server also exposes three resources (simulation status, tracked satellites, and the latest conjunction report) plus two prompts for analyzing collision risk and summarizing a simulation run.
Behind the MCP layer, the runtime sequence is straightforward:
run_simulationkicks off the propagation and conjunction pass in the Python/FastAPI backend.get_satellitesandget_conjunctionsreturn the tracked objects and any predicted close approaches.assess_riskturns a conjunction into a bounded risk assessment.predict_collisionruns the scikit-learn model to estimate collision probability.negotiateproposes an avoidance maneuver based on that probability.
Splitting the workflow this way means an AI assistant, or a human operator working through NitroChat-style tooling, can stop at any step: pull satellite data without running a prediction, or check risk without asking for a maneuver recommendation.
Where NitroStack fits
The NitroStack SDK is the layer that turns VIYAN's Python simulation code into something an MCP client can call safely. The repository organizes the server as a dedicated module (viyan.module.ts) with separate files for tools, resources, and prompts (viyan.tools.ts, viyan.resources.ts, viyan.prompts.ts), which keeps the six tools, three resources, and two prompts as distinct, independently typed pieces rather than one large handler function.
That structure is what makes the read/analyze/decide split enforceable instead of just a design intention. get_satellites and get_conjunctions stay read-only; assess_risk and predict_collision are pure analysis; negotiate is the only tool that produces a maneuver recommendation. A client calling this server can see that boundary directly in the tool list, which matters more in an orbital-operations context than in most CRUD-style MCP servers, since a negotiation recommendation carries real operational weight even before any actual maneuver is executed.
There's no evidence in the repository of the server being deployed through NitroCloud or tested through NitroStudio. The current build runs locally via npm run dev against a FastAPI backend started separately, so this is an SDK-centric use of NitroStack rather than a full-platform one.
Why this design is interesting
The unglamorous part of VIYAN is also the most defensible one: it doesn't collapse "detect, score, and recommend" into a single tool call. A single analyze_collision tool would be easier to demo but harder to trust, since the caller would have no way to inspect the intermediate risk assessment before a maneuver suggestion appears.
By keeping assess_risk and predict_collision separate from negotiate, the project leaves room for a human, or a stricter policy layer, to sit between the ML prediction and the final recommendation, which is exactly where you'd want a checkpoint in a workflow that touches real orbital assets.
What the prototype demonstrates
VIYAN is a hackathon build, not a fielded operations tool, and its README makes no claim of live orbital data, production deployment, or validated model accuracy. Those sit explicitly in its list of future work, alongside live telemetry streaming and multi-satellite negotiation. What it does demonstrate is narrower and still useful: that a conjunction-detection-and-risk-scoring pipeline built from ordinary tools (Skyfield for propagation, scikit-learn for prediction) can be exposed through MCP as a sequence of separately callable steps, without forcing the AI assistant into a single opaque verdict.
Reusable takeaway
The pattern worth reusing isn't "AI predicts satellite collisions." It's the decision to keep data retrieval, probabilistic analysis, and the final recommendation as three distinct MCP tools instead of one. Any workflow where a model's output could trigger a consequential action, not just orbital maneuvers, benefits from the same boundary: let the model see the analysis before it reaches the recommendation, and let the caller stop at any point in between.
If you want to see VIYAN in action, check out the complete video here:
It walks through the MCP server, the satellite tracking and collision-risk workflow, how the tools move from orbital data and conjunction detection to ML-based risk assessment, and how the final maneuver recommendation remains separate from the underlying analysis.
To explore the implementation in more detail, head over to the NitroStack docs for guides on building tools, resources, prompts, testing MCP servers in NitroStudio, and deploying them through NitroCloud.
Check out the complete code over here. You can also read the source and build your own MCP application using the same SDK and workflow at nitrostack.ai.