Skip to main content

AI Agents & MCP Server

I publish a read-only Model Context Protocol (MCP) server so AI agents can query Dark Skies Atlas's structured data directly, instead of scraping rendered pages. There's no authentication and no API key: the server only reads, it never writes or changes state.

This page is a static entry point for search engines and agent crawlers. It doesn't make an agent discover or connect to the MCP server automatically. A page alone can't do that: an agent (or its operator) still has to read the details below and configure the connection itself.

Connect

Note the discovery document above is separate from the _mcp.darkskiesatlas.com DNS TXT record some agent frameworks look up first. The TXT record only points to this discovery document; it is not the MCP endpoint itself.

Any MCP client that takes a JSON config

{
  "mcpServers": {
    "darkskies": { "type": "http", "url": "https://agents.darkskiesatlas.com/mcp" }
  }
}

Tools

All six tools work from live forecasts or local astronomy calculations, not sample data. The two general tools default to compact structured JSON; set detail to detailed for every window and the model context, or presentation to markdown to add a readable briefing alongside the same data. The aurora, Milky Way and meteor tools return structured JSON only. moon_now can add an ASCII drawing of the phase, tilted the way the Moon looks from that place, with presentation set to ascii; size (small, medium or large) sets its height, for clients that show monospace text.

  • dark_sky_window: Finds stargazing windows for up to seven nights at one place. It compares the GFS and ECMWF hourly cloud forecasts, calculates astronomical darkness and Moon conditions locally, and adds NOAA's planetary Kp index for context. Each night gets a verdict, the local observing windows, a confidence level, the reasons, and source timestamps. Pass a place name or latitude/longitude; coordinates work better for parks and remote sites, and ambiguous names return candidates.
  • compare_stargazing_locations: Compares 2–3 places you supply over the same local evening dates, using the same forecasts as dark_sky_window. It ranks each night and each place's best night by verdict, confidence, the longest clear moonless window, then the longest usable window. Ties, excluded places, and partial coverage are reported rather than forced into a winner. It needs a start_date (YYYY-MM-DD) and doesn't search this site's destinations, so supply coordinates you've checked.
  • aurora_forecast: Checks NOAA's short-term OVATION aurora model for one place. It returns the model's overhead aurora value for the nearest one-degree grid cell, the observation and forecast times, how dark the sky is, and the GFS and ECMWF cloud cover for that hour. The model only looks 30 to 90 minutes ahead, so this answers "is it worth going outside now?", not "which week should I book?". The value is not your chance of seeing aurora from the ground: a display can sit low on the horizon outside the cell, and cloud or daylight can hide it. Stale NOAA data comes back as unavailable, never as a guess.
  • milky_way_core_window: Finds when the bright core of the Milky Way stands at least 20° above the horizon during dark, moonless, forecast-clear time, over up to seven local nights. Each night gets its local windows, the core's altitude and compass direction, weather coverage and a confidence level. That's the check dark_sky_window doesn't make: a clear, moonless night is no use for the core if it's below the horizon. It can't tell you whether light pollution, smoke or a ridge line will block the view.
  • meteor_shower_window: Finds observing windows for the named showers in a curated 2026–2027 calendar, over up to seven local nights. It combines each shower's activity dates and approximate UTC peak with where the radiant sits in your sky, darkness, the Moon, and the GFS and ECMWF forecasts. A peak date is not a meteor-rate forecast, outbursts aren't predicted, and a night with no listed shower can still produce meteors. Dates outside the calendar return a coverage error rather than last year's peaks.
  • moon_now: Tells you what the Moon is doing right now at one place: its phase, how much of it is lit, whether it's above the horizon, its altitude and compass direction, the next moonrise and moonset, and which side of the disc looks lit from there. It also gives the Moon's age and the times of the next new moon, first quarter, full moon and last quarter, accurate to about a quarter of an hour. The phase and illumination are the same everywhere on Earth; only the position, rise and set times and the lit side change with your location, so a waxing Moon is lit on the right from the Northern Hemisphere and on the left from the Southern. It's calculated locally, with no weather, so use dark_sky_window to know whether you'll actually see it.

Before you rely on it

  • This is an experiment: I want to learn what agents actually ask for. A good verdict is a forecast, not a promise of clear skies. Confidence and missing data are stated in every response, so check the source timestamps and recheck conditions before you travel.
  • The tools don't assess light pollution, terrain, atmospheric seeing, travel access, or safety. The Kp index in dark_sky_window is planetary context. For a local aurora check use aurora_forecast, and even then read its number as a model value for a grid cell, not the odds of a sighting. For Bortle ratings and the rest of the researched figures on this site, see my editorial standards.
  • I keep the meteor shower calendar by hand, from the International Meteor Organization and American Meteor Society calendars. It currently runs to 24 August 2027, and I'll extend it before then. Peak dates are approximate UTC dates, not predictions of how many meteors you'll see.
  • Requests are rate-limited per network address; the server returns an HTTP 429 with a Retry-After header when a client goes over.
  • Calls are logged so I can see what agents ask for. IP addresses are never stored, and obvious personal data is stripped from logged arguments. Don't send personal data in tool arguments regardless.

Questions about the site itself, rather than the MCP server?

Editorial standards Contact us