Inspiration
Planning a short stargazing session asks a beginner to combine an observer's place and time, target visibility, object types, and a comfortable route. That is more than a list of astronomy facts: changing the observer or advancing the clock changes what the person sees. Night Sky Atlas makes that work collaborative instead of opaque.
What it does
A person can explore the planetarium manually, edit an observing plan, and save it locally. With WebMCP, an agent can query the same live sky context, find observable catalog targets, and propose a timed route. The agent's proposal appears in the same planner rail as an Agent preview. Previewing does not change observer location or time, so the person can inspect the route before approving any mutation. After approval, the agent can visibly set the observer, save the route, and advance the shared tour target by target.
This is a good fit for WebMCP because visual sky state is the product: the person and agent need the same map, time, location, selected target, and plan. The site exposes ten strict, top-level imperative tools that reuse the manual application actions rather than a parallel automation path. It remains a zero-build static site with local browser persistence; no account, backend, or API key is required.
How I built it
The July 22, 2026 baseline at commit 81672ede79762cbf3aadfe23a8dc9eee32013f94 was an interactive planetarium. During the challenge I added a persistent, human-editable observing plan and ten WebMCP tools. The tools reuse the same catalog, altitude calculations, validation, persistence, application actions, and visible state as the manual interface.
The intended safety sequence is read, find, preview, inspect, mutate, save. In particular, preview_observing_plan makes a proposed New York route visible while the current London observer and time stay unchanged; only an explicit location or time action mutates them.
Challenges I ran into
- Designing tools that share exactly the same state and validation as manual controls without creating a hidden agent-only path.
- Keeping location and time changes visible and reviewable while still making the agent route useful.
- Computing and preserving per-slot altitude constraints for a timed route.
- Making a dense planner rail work at desktop and mobile sizes with usable keyboard focus, live progress, and reduced-motion behavior.
Accomplishments that I'm proud of
- A preview-first workflow that visibly proposes a route before observer mutation.
- Ten narrow, strict-schema WebMCP tools: three read tools and seven visible write tools.
- A manual planner that remains useful without an agent, plus a saved guided tour that frames targets and advances time.
- Browser verification of an altitude-constrained New York demo route.
- 81 automated tests covering astronomy, planning, persistence, UI, and WebMCP integration.
What I learned
WebMCP is most compelling when it gives an agent a deliberate application surface while the person can still see and steer every result. Tool descriptions and schemas clarify what an agent may ask for, but the visible UI is what makes the collaboration legible. Separating preview from commit made the location change understandable instead of surprising.
What's next
- Add weather, darkness, and equipment-aware recommendations with clearly labeled data sources.
- Let people compare alternative plans side by side before saving one.
- Export plans as printable or calendar-friendly observing cards.
- Broaden accessibility testing across assistive technology and real devices.
Log in or sign up for Devpost to join the conversation.