meteor-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Meteor scatter planning between two stations. Start with meteor_window, giving both grid squares (for example DN13 and EM12): it reports the path, which shower is nearest its peak, and hour by hour whether the geometry can actually reflect, in words with the reason. meteor_showers says what is near peak now; meteor_shower_info gives every published solution for one shower; meteor_activity and meteor_fireballs read live sources. Radiants come from the IAU Meteor Data Center and are cited in every answer that uses them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| meteor_windowA | When two stations can work each other by meteor scatter, and why. Give both grid squares. The answer covers the path itself (is it even a meteor-scatter distance), which shower is in play, and then hour by hour whether the geometry can reflect — reported as no / marginal / good / best with the reason that decided it. Three things decide it, and radiant elevation is only one: the path length, the radiant's elevation at the path midpoint (where the reflection happens, not at either station), and the angle between the radiant and the path. That last one is the one usually left out and the one that makes a reflection geometrically possible at all — a trail reflects only where it is tangent to the ellipsoid with both stations at its foci, so a radiant broadside to the path works and one up- or down-path does not, at the very same elevation. Your own end can be left out when the host supplies it from the operator's
station profile — ADIF's |
| meteor_showersA | Which showers are near their peak, closest first. The IAU MDC publishes each maximum as a solar longitude rather than a date, because solar longitude names the same point in the stream every year while a date drifts. The longitude is converted here to the date it falls on in the year asked about. |
| meteor_shower_infoA | Every published solution for one shower, unaveraged. The MDC carries several solutions per shower, each from a different study, with slightly different radiants and speeds. All of them are returned. None is blended, because the average of two published radiants is a third that nobody published and no paper stands behind. |
| meteor_activityA | How many meteors the Global Meteor Network has actually confirmed today. A count of observed trajectories broken down by shower — not a flux density, which is a different quantity GMN computes separately. The file is written during the day, so an early read covers a partial day; the generation time is in the answer. This reads the network. Attribution is a condition of GMN's CC BY 4.0 licence and is carried in the result. |
| meteor_fireballsA | Recent fireballs recorded by NASA CNEOS. Bolides bright enough to be detected from orbit — the "did anyone else see that" events, not a meteor rate. Reads the network. |
| meteor_source_infoA | Where every number in this server comes from, and how to cite it. The shower list is the IAU Meteor Data Center's, carried in the package with its checksum so the exact edition served is identifiable. The live sources are named with their licences. Nothing here is this project's own measurement, and the citations are the owners' own. |
| get_version_infoB | This server's version and the edition of the shower list it carries. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Most tools occupy clearly distinct slots: geometry forecast (meteor_window), shower list (meteor_showers), per-shower details (meteor_shower_info), live counts (meteor_activity), and fireballs (meteor_fireballs). The only real fuzziness is between meteor_source_info and get_version_info, since both speak to provenance and the shower-list edition, and meteor_showers vs meteor_shower_info require reading singular/plural carefully.
Six of seven tools follow a consistent meteor_<noun> namespacing scheme that reads predictably. get_version_info breaks the pattern by switching to verb_noun form, a minor but visible deviation.
Seven tools is well within the sweet spot and each maps to a distinct information need in the meteor-scatter domain. Nothing appears padded or redundant.
The surface covers forecast geometry, shower catalogs and details, live observed activity, fireballs, citations, and versioning — a full lifecycle for a meteor-scatter planning workflow. Minor gaps remain, such as looking up showers by date range or solar longitude beyond what meteor_showers returns, but agents can work around these via meteor_shower_info.