The Ephemeris MCP: A Unified Celestial Computation Layer for Multi-Domain Applications

Abstract

This paper proposes the design of a centralized Ephemeris MCP (Model Context Protocol) as a reusable computational core for time- and location-dependent celestial phenomena. By separating objective astronomical computation from domain-specific interpretation, the system enables diverse applications—including astrology, satellite tracking, and photoperiod-based automation—to operate on a shared, internally consistent data foundation. The architecture emphasizes modularity, reusability, and temporal coherence, offering a scalable alternative to fragmented, service-specific solutions.

1. Introduction

Many modern applications rely on precise knowledge of celestial states: the positions of planets, the timing of sunrise and sunset, or the trajectory of artificial satellites. Traditionally, these domains are treated separately:

Astrology systems compute planetary relationships using external APIs
Satellite tracking tools rely on specialized orbital propagation libraries
Agricultural or home automation systems approximate daylight cycles using static timers

This fragmentation leads to redundancy, inconsistency, and dependence on external services.

The Ephemeris MCP is proposed as a unifying abstraction:

A single system that computes the state of the sky as a function of time and observer location, and exposes this state to multiple independent consumers.

2. Conceptual Framework

2.1 Objective vs. Interpretive Layers

The architecture is built on a strict separation:

Ephemeris Layer (Objective) Computes physical positions and temporal events without interpretation.
Application Layers (Interpretive) Apply domain-specific meaning to the data:
- Astrology: symbolic relationships
- Satellite tracking: visibility and communication windows
- Photoperiod control: biological light cycles

This separation ensures clarity, reusability, and testability.

3. The Ephemeris MCP

3.1 Core Function

The Ephemeris MCP implements a single conceptual mapping:

f(time, location) → sky state

Where sky state includes:

Solar position and rise/set times
Lunar position and phase
Planetary positions
Satellite positions and predicted passes

3.2 Internal Structure

The system is modular, with specialized computational components:

Ephemeris MCP
├── Time Module
│   ├── UTC handling
│   ├── timezone resolution
│   └── historical corrections
│
├── Location Module
│   ├── latitude / longitude
│   └── elevation (optional)
│
├── Solar Module
│   ├── sunrise / sunset
│   ├── solar altitude / azimuth
│   └── day length
│
├── Lunar Module
│   ├── position
│   └── phase
│
├── Planetary Module
│   └── positions (geocentric or topocentric)
│
├── Satellite Module
│   ├── TLE ingestion
│   ├── orbit propagation
│   └── pass prediction
│
└── Cache Layer
    ├── temporal caching
    └── shared state reuse

3.3 API Design

Typical exposed methods:

getSunTimes(location, date)
getDayLength(location, date_range)
getPlanetPositions(datetime)
getMoonPhase(datetime)
getSatellitePasses(location, time_range)
getSkyState(datetime, location)

All outputs are deterministic and reproducible.

4. Suggested Toolset and Libraries

4.1 Astronomy and Ephemeris

Swiss Ephemeris (high-precision planetary positions)
Skyfield (modern Python library for astronomy and satellites)
PyEphem (legacy but still functional)

4.2 Satellite Tracking

SGP4 propagation models
TLE (Two-Line Element) datasets
External data providers (e.g., CelesTrak)

4.3 Time and Location

Timezone libraries (IANA database)
Geocoding services (for birthplace or observer location resolution)

4.4 Infrastructure

Backend: Python or Node.js
Database: SQLite, PostgreSQL, or RDF-based systems
API Layer: MCP-compatible interface or REST abstraction

5. Use Case I: Astrology

5.1 Function

The astrology layer consumes planetary and lunar positions to compute:

Natal charts
Transits
Synastry (chart comparison)

5.2 Workflow

Request planetary positions for a given birth time and location
Convert positions into zodiac coordinates
Compute aspects and house placements
Store or return structured chart data

5.3 Advantages of Integration

Eliminates dependence on external astrology APIs
Ensures consistency across all calculations
Enables experimentation with custom models

6. Use Case II: Satellite Pass Prediction

6.1 Function

The system predicts when satellites are visible or within communication range.

6.2 Workflow

Load current TLE data
Propagate satellite orbits over a time window
Compute observer-relative altitude and azimuth
Detect passes above the horizon

6.3 Outputs

Next visible pass
Peak elevation
Duration of visibility

6.4 Challenges

Frequent TLE updates required
Higher computational load than planetary calculations

7. Use Case III: Photoperiod Simulation for Indoor Growing

7.1 Motivation

Outdoor plants respond to seasonal changes in day length. Indoor systems typically use static light cycles (e.g., 12/12), which do not replicate natural conditions.

7.2 Solution

Use the Ephemeris MCP to simulate natural daylight cycles based on latitude and date.

7.3 Workflow

Query daily sunrise and sunset times
Compute day length progression over time
Translate into lighting schedules

7.4 Example Strategies

Direct simulation: lights follow actual sunrise/sunset
Shifted schedule: fixed start time with variable duration
Threshold detection: trigger flowering when day length drops below a limit

7.5 Biological Basis

Plants respond to photoperiod via internal light-sensitive systems (e.g., phytochrome), making gradual changes in light duration more realistic than abrupt switching.

8. Design Considerations

8.1 Temporal Coherence

All domains operate on the same time model, preventing inconsistencies between systems.

8.2 Caching

Planetary data can be cached aggressively
Satellite data requires more frequent updates

8.3 Extensibility

New domains can be added without modifying the ephemeris core.

8.4 Push vs. Pull

Pull model: clients request data
Push model: system emits events (e.g., “sunset in 10 minutes”)

9. Discussion

The Ephemeris MCP represents a shift from domain-specific tools toward a shared computational substrate. By treating celestial mechanics as a reusable service, it enables:

Cross-domain innovation
Reduced duplication of effort
Greater experimental flexibility

It also aligns with broader trends in agent-based systems, where reusable data sources serve multiple autonomous processes.

10. Conclusion

A centralized Ephemeris MCP is both feasible and advantageous. By unifying astronomical computation and exposing it through a clean interface, it supports diverse applications ranging from symbolic interpretation to practical automation.

The key architectural principle is simple:

Separate what the sky is from what it means.

Once this boundary is respected, a wide range of systems can emerge naturally from a single, coherent foundation.

11. Future Work

Integration with home automation platforms
Graph-based representations of celestial relationships
Machine learning on temporal celestial patterns
Expansion into additional domains (navigation, circadian lighting, environmental modeling)

Appendix: Minimal Viable Implementation Path

Implement solar calculations (sunrise/sunset)
Add planetary positions
Integrate satellite propagation
Build API layer
Connect first consumer (e.g., grow light control)
Expand to astrology and satellite applications

End of paper.

initial_idea.md 7.9 KB Trvalý odkaz Historie Surový