---
title: EPS Astro-RAG MCP Server v2.3.0
url: https://www.emergentmind.com/topics/eps-research-astro-rag-mcp-server
type: topic
---

# EPS Astro-RAG MCP Server v2.3.0

The **EPS Research Astro-RAG MCP Server v2.3.0** is a cross-platform **Model Context Protocol (MCP)** implementation for retrieval-augmented generation over astrophysical survey corpora. It is designed as a unifying access layer over heterogeneous kinematic datasets that would otherwise remain fragmented by survey, epoch, schema, and access method. The server exposes a browser interface, a REST API, and an LLM-native MCP endpoint, and supports deterministic retrieval, metadata filtering, structured JSON analysis, and corpus-wide semantic search across **2,064 objects** spanning **\(z=0\) to \(z=5.68\)** [2607.03946].

## 1. Definition, lineage, and intended role

The server is part of the **EPS Research RAG Corpus Series** and is framed as infrastructure for **LLM-native astrophysical retrieval** rather than as a replacement for archive-specific query systems. In the paper’s formulation, the practical problem is not merely data availability but fragmentation across corpora with incompatible field names, formats, and archives. The server therefore functions as a schema-unifying, machine-readable service layer over curated astrophysical datasets, so that assistants compatible with MCP can invoke typed tools directly instead of relying on ad hoc wrappers or scraping [2607.03946].

Its intellectual lineage sits within the broader **EPS Research Astro-RAG Platform**, which had already established a machine-readable, cross-epoch corpus infrastructure with common-schema distribution, executable notebooks, and a reproducibility pathway. That platform emphasized open-science corpora, JSON/CSV/JSONL distribution, and cross-epoch kinematic analysis, while the MCP server operationalizes those data as directly callable tools for agents and research workflows [2605.30384].

Within the scope claimed by the server paper, the system is presented as the **first MCP-compliant astrophysical data server**, and specifically as the first with **cross-epoch kinematic coverage plus semantic search** [2607.03946]. The niche it occupies is therefore narrower than the general Virtual Observatory stack and broader than a single archive wrapper: it is an **LLM-oriented, schema-unified retrieval substrate** for curated astrophysical corpora.

## 2. Corpus integration and scientific coverage

The server integrates **five corpora** from the EPS Research corpus series and brings them into one retrieval environment. Together they cover nearby HI rotation-curve systems, dwarf and irregular galaxies, Milky Way globular clusters, intermediate-redshift kinematic samples, and high-redshift ALPINE targets [2607.03946].

| Corpus | Objects | Coverage |
|---|---:|---|
| Unified HI Rotation Curve Corpus v7.0 (`v7`) | 438 galaxies | \(z \approx 0\) |
| Dwarf/Irregular HI Corpus v1.0 (`dwarf`) | 129 galaxies | \(z \approx 0\) |
| Milky Way Globular Cluster Corpus v1.3.2 (`gc`) | 174 globular clusters | MW |
| IntZ Kinematic Corpus v1b (`intz`) | 1,292 galaxies | \(z \approx 0.4\)–2.7 |
| High-z ALPINE Kinematic Corpus Z1 (`z1`) | 31 galaxies | \(z=4.26\)–5.68 |

Each corpus preserves distinct scientific emphases even after harmonization. The paper notes that **v7** records emphasize morphology, distance, inclination, maximum rotation velocity, quality tier, and telescope; **globular cluster** records emphasize metallicity, Galactic coordinates, dynamical mass, and core-collapse status; **IntZ** records emphasize redshift, stellar mass, star-formation rate, and kinematic class; and **Z1** records emphasize tracer line, redshift, rotation classification, and ALPINE identifiers [2607.03946].

The result is not a homogenized loss of domain detail, but a common access surface over scientifically heterogeneous records. This enables use cases that range from local rotation-curve retrieval and dwarf-galaxy comparison to Galactic cluster studies, intermediate-redshift population analysis, and early-universe disk or rotator exploration. The server paper also gives the relevant corpus DOIs: **10.5281/zenodo.19563417** for `v7`, **10.5281/zenodo.20320362** for `dwarf`, **10.5281/zenodo.19907766** for `gc`, **10.5281/zenodo.20453189** for `intz`, and **10.5281/zenodo.20369286** for `z1` [2607.03946].

## 3. Runtime architecture and exposed interfaces

Architecturally, the server is implemented in **Python** using **FastMCP** and serves **three interfaces concurrently from a single process**. The interfaces are an **MCP endpoint** at **`/mcp`**, a **REST API** at **`/api/*`** backed by **FastAPI** with documentation at **`/docs`**, and a browser-oriented interface at **`/`** described as a single-page HTML application for point-and-click querying, semantic search, and JSON or text export [2607.03946].

Data are loaded from **JSONL files at startup** and stored in an in-process cache named **`CORPORA_CACHE`**. Fetching uses **httpx** asynchronously, and the server may also download FAISS indexes from GitHub during initialization if they are not already present. On the HuggingFace Spaces free tier, the reported **cold-start latency** is **about 30–90 seconds**, depending on whether index download is required; once loaded, subsequent structured requests are served from the cache with **sub-millisecond latency** [2607.03946].

The MCP layer exposes **seven typed tools**, each returning structured JSON with at least **`success`**, **`tool`**, **`data`**, and **`human_text`** fields:

- **`list_corpora`** returns metadata, record counts, redshift ranges, and Zenodo DOIs.
- **`list_objects`** returns paginated object IDs with optional survey and quality-tier filters.
- **`get_object`** returns the full JSON record for an object ID, including survey-merged fields and provenance.
- **`search_metadata`** performs case-insensitive substring search over metadata fields.
- **`filter_objects`** supports numeric range filtering on any field and an **`omega_ready_only`** flag.
- **`get_corpus_schema`** returns schema and column definitions.
- **`semantic_search`** performs natural-language top-\(k\) retrieval over FAISS indexes [2607.03946].

The paper emphasizes that these tool signatures are typed and documented in the MCP manifest so that an LLM can choose them automatically. It gives concrete mappings from natural-language requests to tool calls, such as a request for galaxies with rotation velocity above 150 km s\(^{-1}\) mapping to **`filter_objects`** with `field = vrot_max_kms` and `min = 150`, and a request for galaxies similar to DDO 154 mapping to **`semantic_search`** [2607.03946].

## 4. Unified schema and deterministic retrieval

The server’s common data model is a **machine-readable JSON schema** with **native-typed fields**—floats, ints, bools, and nulls—together with **embedded survey provenance** and **consistent field naming across epochs**. The paper cites normalized field names such as **`vrot_max_kms`**, **`inc_deg`**, **`distance_mpc`**, **`kinematic_model`**, and, for redshifted samples, **`z_spec`** [2607.03946].

This common schema is the basis for deterministic retrieval. `get_object` supports stable object-ID lookup, exemplified in the paper by direct retrieval of **`NGC3198`** in corpus `v7`. The returned record includes survey-merged fields such as inclination, position angle, distance, kinematic model, \(V_\mathrm{rot}\) profile, and provenance. `list_objects`, `search_metadata`, and `filter_objects` support exact navigation and selection over corpus contents, while `get_corpus_schema` exposes field and column definitions to clients [2607.03946].

The paper gives explicit filtering examples. Applying `filter_objects` to `v7` with `field = distance_mpc`, `min = 1`, and `max = 10` yields **119 of 438 galaxies**. Applying it to `intz` with `field = z_spec`, `min = 0.5`, and `max = 1.0` yields **822 of 1,292 objects**. These examples are reported as completing in **under 100 ms** [2607.03946].

This deterministic layer is central to the server’s role in retrieval-augmented workflows. It allows an assistant to retrieve a full machine-readable record instead of approximating astrophysical values from memory, and it supports constrained selection over survey membership, quality tier, redshift interval, and numeric kinematic properties. The paper is explicit that the system thereby supports **deterministic retrieval**, **metadata filtering**, and **structured analysis** through JSON rather than through prose-only responses [2607.03946].

## 5. FAISS semantic search and cross-epoch exploration

Version **2.3.0** introduces the server’s major new feature: **FAISS-based semantic search**. The implementation uses **`all-MiniLM-L6-v2`** from **sentence-transformers**, producing **384-dimensional dense embeddings**. For each corpus, embeddings are constructed **offline** and indexed with **`faiss.IndexFlatL2`**, that is, exact nearest-neighbor search in L2 space. The paper justifies this choice as appropriate for corpora of order \(10^3\) and as guaranteeing **reproducible, deterministic results** [2607.03946].

Rather than embedding raw JSON records, the system constructs a **curated summary string** for each object from selected metadata fields. For `v7`, the paper gives the example summary string for NGC 3198:

```text
Galaxy NGC3198. survey THINGS. morphology SBc (Sc). distance 13.8 Mpc. inclination 72.0 deg. max rotation velocity 150.0 km/s. quality tier 1. omega ready True. telescope VLA.
```

This design concentrates the embedding on scientifically meaningful descriptors rather than on JSON syntax, and the selected fields differ by corpus [2607.03946].

The semantic-search layer is packaged as **15 index artifacts**: **five `.faiss` binaries**, **five `_ids.json` files**, and **five `_texts.json` files**, archived at **Zenodo DOI 10.5281/zenodo.21147895** and hosted on GitHub for automatic download. At query time, the server encodes the query with the cached MiniLM model, runs `index.search`, and returns top-\(k\) object IDs together with **L2 similarity scores**. Query latency is reported as being dominated by embedding inference, at roughly **10–50 ms on CPU**, while FAISS adds negligible overhead for **\(N \le 2{,}064\)** [2607.03946].

The paper includes representative examples. For the query **“dwarf irregular low mass”** over `v7`, the top results are **CVnIdwA** (score **1.216**), **DDO_210** (**1.218**), **IC_1613** (**1.219**), **DDO_154** (**1.221**), and **DDO_168** (**1.223**). For **“Sculptor group low rotation”** over the dwarf corpus, the results include **UGCA442**, **ESO349-G031**, and **ESO245-G005**. For globular clusters, **“core-collapsed high concentration globular cluster”** retrieves post-core-collapse systems [2607.03946].

The semantic layer is, however, explicitly distinguished from physical similarity. The paper states that **MiniLM embedding similarity is not physical similarity in astrophysical parameter space**. Two objects that are close in embedding space may still differ strongly in inclination, kinematic model quality, or other quantitative parameters. The recommended tool for numeric similarity questions is therefore **`filter_objects`**, not semantic search [2607.03946].

## 6. Reproducibility, deployment, and operational profile

The server is publicly deployed on **HuggingFace Spaces** at **`https://dflynn5656-astro-rag-mcp.hf.space`** and distributed under the **MIT License**. The codebase is part of the **EPS Research RAG Corpus Series** repository at **`https://github.com/eps-research/rag-corpus-series`**. The software archive is published at **Zenodo DOI 10.5281/zenodo.21154451**, and the paper states that the full platform is reproducible from Zenodo **without network access to HuggingFace** [2607.03946].

Deployment uses **Docker**. To mitigate free-tier hibernation on HuggingFace Spaces, the author reports use of an **UptimeRobot** keepalive ping every five minutes, which is said to maintain effectively zero cold-start latency for regular users. The server also includes a **cross-platform launcher (`launch.py`)** with GUI progress popups and automatic dependency management for **Windows 11** and **Ubuntu** [2607.03946].

Named dependencies include **FastMCP**, **FastAPI**, **FAISS**, **sentence-transformers**, **httpx**, and HuggingFace Spaces infrastructure. The operational profile reported in the paper is simple but explicit: warm structured lookups are **sub-millisecond**, metadata filters complete in **under 100 ms** in the examples, and semantic-search inference takes approximately **10–50 ms on CPU** [2607.03946].

The server’s reproducibility posture is unusually strong for an MCP tool. The paper ties together a live deployment, versioned code, corpus-specific DOIs, a software DOI, and a separately archived FAISS-index release. This makes the system not only callable by agents but also citable, reproducible, and inspectable as research infrastructure [2607.03946].

## 7. Position in the MCP ecosystem, security context, and limitations

The server occupies a specific niche within the wider MCP ecosystem. It is not a general-purpose MCP benchmark corpus like **MCPZoo**, which aggregates **90,146 distinct MCP servers** from six public sources and emphasizes large-scale discovery, runnability, and security analysis rather than domain-specific scientific data access [2512.15144]. Nor is it a tool-routing framework such as **RAG-MCP**, which treats MCP selection itself as a retrieval problem and reports that retrieval-first routing can reduce prompt size and improve tool selection accuracy in large MCP registries [2505.03275]. The EPS Research server instead contributes a concrete, domain-specific MCP endpoint whose tools are already aligned with astrophysical retrieval and analysis.

The broader MCP security literature is directly relevant to any deployment that places this server alongside other MCP services. Work on **Parasitic Toolchain Attacks** argues that MCP systems can fail through “lack of context–tool isolation” and “absence of least-privilege enforcement,” allowing untrusted retrieved content to steer later sensitive tool invocations [2509.06572]. Related work on cross-server exfiltration shows that even a benign-seeming server can induce an agent to invoke unrelated sensitive tools if the host permits broad composition [2507.19880]. **MCP-SafetyBench** further reports large attack-success disparities across multi-step MCP workflows and identifies host-side attacks as particularly severe [2512.15163], while **MCP Pitfall Lab** emphasizes that trace-grounded auditing is more reliable than agent self-report and that small server-side changes such as allowlists, guard clauses, and structured logs can eliminate static pitfall findings [2604.21477]. A plausible implication is that an Astro-RAG deployment should treat third-party MCP services as untrusted, keep sink actions narrowly scoped, and preserve trace-level observability when combining retrieval with communication, filesystem, or execution tools.

The server paper itself states several limitations. The most important conceptual limitation is that semantic similarity in the MiniLM embedding space is **not** a physical metric. A second limitation is metadata completeness: in the **IntZ** corpus, some records have missing **`identifiers.name`** fields, so semantic-search results may return numeric index IDs instead of object names. More generally, the paper reports **no formal benchmark suite, precision/recall study, or user evaluation** beyond representative examples and latency observations [2607.03946].

Finally, the server is positioned as **complementary** to established astronomy infrastructure rather than a replacement for it. The paper states that **astroquery** remains useful for live database-specific access, and that VO standards such as **TAP**, **ADQL**, and **VOTable** remain the appropriate mechanisms for formal archive querying. The MCP server instead fills the niche of **schema-unified, LLM-oriented, cross-epoch corpus retrieval** over a curated set of astrophysical kinematic datasets [2607.03946].

Source: https://www.emergentmind.com/topics/eps-research-astro-rag-mcp-server