About the project
IMC Guardian is the stretch project out of the two projects I built for the WebMCP Challenge. It is an aviation weather decision-support prototype for a solo pilot or private jet crew flying a longer route. The main goal is to save time and add a second pair of eyes when weather conditions begin changing.
Pilots do not have a shortage of data. They have aircraft instruments, radar, dispatch, ATC, forecasts, advisories, and procedures. The harder problem is recognizing the exact moment when the picture no longer supports the plan. IMC Guardian is designed as an independent challenge layer, not a confirmation machine.
A pilot can ask AI to check a proposed route in plain English. Fifteen site-owned WebMCP tools give the agent structured access to the route, airport observations, forecasts, advisories, risk factors, nearby alternates, configurable notifications, validated alerts, incident evidence, and decision options.
The application does not tell a pilot that a flight is safe, issue a clearance, direct a maneuver, or replace an official briefing. It organizes the evidence and catches important changes, while the pilot remains in control.
Inspiration
The idea came from thinking about a long-route solo pilot or private jet pilot trying to keep up with weather while also managing everything else involved in a flight. Conditions can change quickly, especially ceilings and visibility. There can also be a lot of noise when the pilot only needs to know whether an important personal limit has changed.
I wanted to see whether WebMCP could let a pilot ask one clear question, rapidly inspect the weather along the route, and configure a focused notification instead of repeatedly checking several different panels and sources. The phrase that kept making sense was “a second pair of eyes.” The interaction is almost as simple as asking, “Guardian, what do you see?” The AI helps watch, organize, and challenge the current picture. It does not become the pilot.
Why this matters
We added five investigation-backed case studies because the problem is real.
Delta Flight 56 encountered severe turbulence in July 2025 after the crew had already discussed and adjusted around weather. The NTSB says the upset lasted about 2.5 minutes, two crew members were seriously injured, and the flight diverted to Minneapolis.
Delta Flight 175 encountered a rapidly developing convective cell near Atlanta in 2023. The NTSB found that the low-precipitation buildup was not apparent on the aircraft's weather radar or ATC scopes. Four people were seriously injured and thirteen received minor injuries.
The site does more than display that case. A WebMCP evidence replay loads the Delta 175 final-report record, reconstructs the weather timeline, compares the crew's concern with the recorded outcome, and explains what the evidence cannot prove. At 22:30 UTC the crew said conditions were about to get worse. Severe turbulence followed at 22:31:15 UTC. The result is deliberately precise: concern supported, action not judged. The NTSB found that near-real-time Graphic Turbulence Guidance Nowcast capability could have provided earlier awareness to secure the cabin, but the report does not establish that a different route choice or this prototype would have prevented the encounter.
Singapore Airlines Flight 321 diverted to Bangkok in 2024 after an extreme acceleration change over developing convective activity. Air Europa Flight 45 diverted to Natal, Brazil after severe turbulence injured dozens of people.
Air France Flight 447 is the foundational sensor-disagreement case. The BEA identified pitot-probe icing, erroneous speed indications, a stall, and impact with the ocean. IMC Guardian does not claim it would have prevented any of these events. The cases show why a concise, independent evidence check can matter when weather, workload, and human-machine interaction collide.
What it does
For the reproducible demonstration, a VFR pilot proposes a flight from Tampa to Tallahassee. Conditions deteriorate along the northern part of the route, the destination reports IFR, and a G-AIRMET for IFR overlaps the corridor.
The agent can inspect the evidence, explain why the route risk increased, find comparatively better nearby airports, and compare delaying, diverting, or canceling. The pilot can also configure Second Pair of Eyes to watch a specific metric. In the demo, a 1,500-foot ceiling limit is crossed. WebMCP checks the threshold, forecast context, and overlapping advisory before presenting the alert.
The project also includes a live Cesium globe with NASA satellite clouds, Apple WeatherKit context, and a Tampa-to-JFK weather corridor sampled across nine points. That gives the pilot and the agent a fast visual picture of changing conditions ahead.
The globe stays focused on Florida so the demonstration supports the route instead of becoming a generic spinning-earth effect. The top of the experience now explains the interaction in three steps: ask once, let WebMCP double-check, and keep the final decision with the pilot.
How we built it
We built a React and Vite application with a deterministic aviation-risk engine and fifteen imperative WebMCP tools registered through document.modelContext.registerTool. The user interface and the agent share the same route, assessment, alternatives, route watch, notifications, validation, historical replay, decision state, and live tool trace.
NOAA Aviation Weather Center is the aviation-data foundation. Its data is reached through a scoped, cached Vercel server-side proxy with a custom user agent. Apple WeatherKit provides supplemental current conditions, cloud cover, temperature, precipitation, and wind. Its signing credentials stay on the server.
CesiumJS provides the interactive 3D Earth. NASA EOSDIS GIBS supplies current GOES-East ABI GeoColor satellite imagery through a Web Map Service layer. The globe can animate roughly 90 minutes of recent satellite frames, focus on Florida, and display the demonstration route. Apple WeatherKit adds twelve global samples and nine cached checkpoints along the Tampa-to-JFK corridor.
The frontend also includes a live natural-language demonstration using GPT-OSS 120B on Groq. The model interprets the pilot's sentence and chooses an ordered subset of allowlisted tools. The browser executes the actual WebMCP tools and shows every step, along with model token usage. Weather facts come from application tools and identified data sources, not the model's memory.
The live session now exposes a safe server receipt so judges can see the complete connection path. It shows the browser request to /api/agent, the server-side call to Groq's OpenAI-compatible chat-completions endpoint, the selected model, response mode, prompt size, 10-tool allowlist, request receipt, latency, and token usage. The Groq credential and hidden system instruction remain on the Vercel server and are never returned to the browser. The page also links Groq's API reference, OpenAI's gpt-oss announcement, and the public server implementation.
We created a clearly labeled scenario mode so the judging flow stays reproducible even when live weather changes or a source is temporarily unavailable. Scenario values are never presented as current reports.
We also created a historical evidence mode from the NTSB Delta 175 final report and public docket. Three WebMCP tools load the case, compare the documented concern with the recorded event and final findings, and expose the replay's limits. It is a structured investigation replay, not certified live telemetry.
Challenges
The hardest product challenge was deciding what the system must not do. It would be easy to make the demo dramatic by having AI say go or no-go. That would be the wrong product. The tools surface evidence and tradeoffs, but return no clearance, safety guarantee, or automated flight decision.
The next challenge was keeping data provenance clear. Aviation Weather Center products are aviation evidence. Apple WeatherKit and NASA satellite imagery provide supplemental context. The interface identifies live information, scenario information, source time, and limitations instead of blending everything into one unsupported claim.
The biggest missing connection is live aircraft tracking. RadarBox or another commercial aircraft-data API could add near-real-time position, pressure altitude, GPS-derived geometric altitude, ground track, groundspeed, vertical trend, and time-to-weather calculations. That access was too expensive for this prototype, so we did not fake it. The plane shown on the Tampa-to-JFK corridor is a clearly illustrative route animation.
We also had to define the sensor boundary honestly. ADS-B can report position, barometric altitude, geometric altitude, ground track, groundspeed, and vertical velocity, but it does not report pitot-derived airspeed. A future approved aircraft-data connection could contribute a separate sensor comparison. An external feed can surface disagreement and give the pilot something concrete to run against the instruments, but the prototype must not diagnose a failed pitot tube or claim which onboard source is correct.
Making the technical pieces visually understandable was also a challenge. The project needed to show the globe, satellite weather, aviation reports, AI planning, WebMCP calls, notification logic, validation, and the final human boundary without turning into a wall of data.
What we learned
WebMCP fits this use case because the important information is a decision structure, not a collection of buttons. Aircraft and pilot context, route, conditions, trends, advisories, alternatives, missing information, configured limits, and the human choice can each become a named, auditable tool.
We also learned that security and human control do not have to mean asking for confirmation after every small step. The pilot can configure the limit once. The AI can collect, compare, and double-check repetitive evidence. It stops where human authority matters most, at the actual flight decision.
Where we see it going
The project was originally imagined with real production flight data from RadarBox. Commercial access was outside this prototype's budget, so we made the aircraft animation illustrative and said so directly. With the right budget, connecting RadarBox or a comparable live aircraft-data API is the clearest next step. Near-real-time position, reported altitude, ground track, groundspeed, vertical trend, and destination context could let IMC Guardian estimate when an aircraft may reach deteriorating weather and display viable airports behind, ahead, or beside the route.
The longer-term vision is a carefully approved onboard data path that can compare aircraft sources with independent surveillance and environmental context. The goal is not to add another alarm. It is to expose disagreement quickly, state what each source can and cannot prove, and let the pilot focus on flying the airplane.
The same approach could support pilot-defined personal minimums, instructor-reviewed profiles, notification subscriptions, post-flight decision review, and alerts designed around plan-continuation bias. Any operational version would require aviation-domain review, rigorous validation, redundant data sources, and careful regulatory and liability analysis.
Log in or sign up for Devpost to join the conversation.