Sky to Porch

• 

  Ambiguous place? The Agent asks, the page shows the same choices, and the map waits for the person to decide.

• 

  Official NYC air-quality evidence becomes a plain-English answer with sources and limitations beside the map.

• 

  The Missions view traces Las Vegas drought evidence to the NASA and U.S. Drought Monitor products behind it.

• 

  The Houston Beryl result shows validated NOAA wind observations, storm context, citations, and property-level limitations.

• 

  The About view explains Sky to Porch’s evidence model, coverage, safety boundaries, and independent attribution.

• 

  The catalog shows which NASA, NOAA, and regional satellite products are live, candidate, or require credentials.

Inspiration

After a wildfire or a storm, people ask whether smoke was recorded near their family that day. The records exist, but the hard part is tying a place and a date to what was actually observed.

What it does

Sky to Porch is a map-based evidence workspace where a person and an AI Agent investigate the same question on the same screen. The person gives a place, a completed date or range, a hazard, a radius, and a concern. The strongest supported assessment comes first, then the observations with times, official citations, confidence, limitations, and source status.

Seven hazard families are covered, and a broad question runs related ones together. Fire & Smoke brings Air Quality. Extreme Heat brings Drought & Land. Earth & Volcanoes brings Air Quality and Extreme Heat. A plain storm question runs Wind & Storm and Flood & Heavy Rain. Naming one hazard keeps it focused. Chains never merge. Rainfall is not proof of wind damage, and a regional observation is not a verdict on one house or one person.

Why WebMCP fits Sky to Porch

WebMCP lets the person skip that setup and ask the question they actually have. "What environmental evidence was recorded near Los Angeles during the wildfire?" The Agent picks the tools, runs the Fire & Smoke and Air Quality chains, and summarizes in plain English what they support.

Real questions also need cross-checking. A storm question means wind readings, rain totals, flood extent, and gauge levels from different agencies, on the same day, for the same area. A person doing that by hand runs each path and compares the results one at a time. An Agent is good at exactly this. It runs every relevant chain, reads all of them, and tells the person where the sources agree, where they differ, and what is still missing.

This is collaboration, not hand-off. Human queries and Agent calls use one analysis service and update the same map, Meaning panel, and Evidence panel. The person can take over at any point, change the radius or the date, pick a different hazard, or click into a source. The person can also keep asking. "Which source failed?" or "Show me the exact gust reading" gets answered from the result already on screen, without rerunning anything. Every chain keeps its own button, so the Agent cannot hide a result, and the final judgment stays with the person.

How I built it

The stack is Next.js, React, TypeScript, and MapLibre GL. Adapters for NASA, NOAA, USGS, and EPA sources feed one deterministic analysis service that owns validation, retrieval, calculations, freshness, provenance, confidence, limitations, and safe display. The model chooses tools and explains validated results. It cannot invent an observation.

The page registers eight WebMCP tools, covering hazard analysis, two-scenario comparison, active-result inspection without a rerun, source coverage, help and demos, a storm claim checklist, place lookup, and map layers. The Agent comes from a WebMCP-compatible browser. The site holds no model API key.

Challenges I ran into

• Ambiguity. "Houston" matches several places, so the place tool lists up to five candidates with stable IDs and waits. The pick resumes the run with the original date, hazard, radius, and concern intact.
• Size. A result gets about 2,400 characters, so compaction drops optional detail first and keeps the strongest observations, provenance, limitations, and links to the visible result.
• Real Agent behavior. A valid schema does not mean the Agent picks the right tool or runs every chain, so I added live-source checks and model-scored evaluations of tool selection, ambiguity recovery, comparisons, and summaries.

Accomplishments that I'm proud of

• User-specified locations, dates, and radii stay authoritative.
• Every result separates a valid observation from no observation returned, source failure, unsupported coverage, stale data, and inconclusive evidence.
• The Agent can answer a follow-up from the active result without rerunning it.
• The same experience works on desktop and mobile.
• The current build passes typecheck, lint, 1,617 unit tests, 133 integration tests, a 14-page production build, and the full desktop and mobile Playwright suite.

What I learned

Exposing tools is the easy part. The collaboration has to be visible on the screen. "No observation returned" is not the same as "no hazard," and a source failure must never disappear inside a confident summary.

What's next

I want more official-source coverage, portable evidence summaries, and contextual follow-up tools across the whole hazard catalog.

Prior work and Challenge contribution

Sky to Porch existed before the OpenAI WebMCP Challenge. The map, the human query interface, the source adapters, and the evidence contracts are prior work. Everything Agent-facing above is the Challenge contribution, along with more evidence for all hazards and the WebMCP testing. I built it solo with AI coding assistance. PRIOR_WORK.md in the repo documents the boundary.

Built With

• airnow
• chatgpt
• codex
• geomet
• github
• maplibre
• nasa
• next.js
• noaa
• node.js
• playwright
• react
• rest
• typescript
• usgs
• vercel
• vitest
• webmcp