EPS Astro-RAG MCP Server v2.3.0

Updated 7 July 2026

The paper demonstrates the server as the first MCP-compliant astrophysical retrieval system unifying heterogeneous datasets with deterministic, schema-driven access.
It integrates five curated corpora and offers REST, MCP, and browser interfaces to enable semantic search, metadata filtering, and fast numeric queries.
The server employs FAISS-based semantic search with MiniLM embeddings, ensuring reproducibility and complementing traditional archive querying methods.

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$ (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 28 May 2026).

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 (Flynn, 4 Jul 2026). 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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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:

$z=5.68$ 2

This design concentrates the embedding on scientifically meaningful descriptors rather than on JSON syntax, and the selected fields differ by corpus (Flynn, 4 Jul 2026).

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- $z=5.68$ 0 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 $z=5.68$ 1 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).

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 (Wu et al., 17 Dec 2025). 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 (Gan et al., 6 May 2025). 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 (Zhao et al., 8 Sep 2025). 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 (Croce et al., 26 Jul 2025). MCP-SafetyBench further reports large attack-success disparities across multi-step MCP workflows and identifies host-side attacks as particularly severe (Zong et al., 17 Dec 2025), 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 (Hao et al., 23 Apr 2026). 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 (Flynn, 4 Jul 2026).

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 (Flynn, 4 Jul 2026).