Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@io.github.qso-graph/eme-mcp what's the mutual moon window for DN31 and JO01 tonight?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for EME—Earth-Moon-Earth, moonbounce. When the moon is up from your grid, when it is up from both ends of a schedule at once, what the path costs on 2m, 70cm and 23cm, and which days ahead are least degraded.
Part of the qso-graph project. No network, no authentication.
The moon's position is computed here, from the abridged ELP-2000/82 series as Meeus tabulates it (Astronomical Algorithms, chapter 47). That is around 250 lines of standard library and a coefficient table. It is also what WSJT-X does, and the norm for EME software.
That matters for more than tidiness. Moonrise and moonset are different for every grid square, so a service-backed answer means a request per location per query—and a planning tool that stalls, rate-limits, or goes dark when a remote service does.
JPL Horizons is still here—as the test oracle. Recorded Horizons responses are fixtures, so every CI run checks these numbers against NASA's rather than against themselves. Measured against Horizons for a Boise grid:
agreement | |
Azimuth | within 0.01° |
Elevation | within 0.003° |
Range | within 9 km of ~392,000 (0.002%) |
Thirty arcseconds, against a 432 MHz array that is degrees wide.
Related MCP server: NOAA Space Weather MCP Server
uvx eme-mcp # run it; nothing to installTool | Description |
| Moon azimuth, elevation and range from a grid square over time—and, given a second locator, the mutual window when both stations can see it |
| One-way, round-trip and echo path loss on 2m / 70cm / 23cm, or any frequency |
| How much worse than perigee this moment is, with the moon's declination |
| The least degraded days ahead |
| Service version and the ephemeris series used |
Sky noise is not included. The full degradation figure an EME operator plans with
combines the distance term with the galactic background behind the moon, from the Haslam
408 MHz all-sky map. That map is not yet carried and pinned, so eme_degradation and
eme_calendar report the distance term and say so in every answer rather than
returning a number that looks complete and is not. Tracked in
qso-graph-devel#52.
Elevations are geometric: no atmospheric refraction, which lifts an object near the horizon by about half a degree.
They answer different questions and are often confused, so both are returned:
echo_db is the one to budget a station with—the radar equation, accounting for
the moon reflecting about 6.5% of what reaches it. Near 252 dB on 2m, 262 on 70cm and
271 on 23cm at mean distance, which are the numbers EME operators know.
round_trip_db is twice the free-space loss. It ignores the moon entirely.
GPL-3.0-or-later. See LICENSE.
The algorithms are from Jean Meeus, Astronomical Algorithms (second edition, Willmann-Bell, 1998), chapters 7, 11, 12, 22, 40 and 47—cited in the source where each is used. The implementation is ours; the mathematics is his and is not claimed.
The least degraded days ahead — when the moon is nearest.
Inputs: days. Returns: object
How much worse than the best case the moon is, now or at a given time.
Inputs: when, locator. Returns: object
Where the moon is from a grid square, and when both ends of a schedule can see it.
Inputs: locator (required), hours, step_minutes, other_locator. Returns: object
What the path to the moon and back costs, now or at a given time.
Inputs: band, when, locator, frequency_mhz. Returns: object
Get eme-mcp's version and the ephemeris series it computes from.
Inputs: no named parameters. Returns: object
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 5 tools
Each tool targets a distinct EME concept: version/source info, visibility windows, path loss, degradation, and a calendar of favorable days. The main overlap is between eme_degradation and eme_calendar, since the calendar is essentially a ranked view of degraded days, but their timing granularities and purposes are clear enough.
Four domain tools consistently use an eme_ prefix followed by a noun phrase, which is predictable and readable. get_version_info deviates with a get_ verb-noun convention, but it is a distinct metadata tool and does not create confusion.
Five tools is well-scoped for a focused EME calculation server. Each tool maps to a clear, useful capability without obvious filler or missing major operations.
The surface covers version/source provenance, moon visibility windows, path loss, degradation, and calendar-based planning, which is solid for the apparent EME domain. Minor gaps could exist around station-specific configuration or additional link-budget terms, but core workflows are covered.
Offline observational astronomy: positions, rise/set, moon phases, eclipses, and seasons.
Amateur radio MCP server with band plans, EIRP, cable loss, antenna gains, and more
Elevation-corrected sun, moon, twilight, solar and tide data for any point on Earth
Moon phase, moonrise, full Moons, eclipses, Moon sign and distance for any place in the world.
