# 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

1. Request planetary positions for a given birth time and location
2. Convert positions into zodiac coordinates
3. Compute aspects and house placements
4. 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

1. Load current TLE data
2. Propagate satellite orbits over a time window
3. Compute observer-relative altitude and azimuth
4. 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

1. Query daily sunrise and sunset times
2. Compute day length progression over time
3. 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

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

---

End of paper.