SIRIUS MCP

Overview

AI agents are only as useful as the enterprise context they can reach. SIRIUS MCP is a Model Context Protocol (MCP) semantic retrieval layer that exposes enterprise configurations — site settings, standards, definitions historically buried in databases and documents — as tools any compliant agent can call. It turns retrieval from an implementation detail inside one application into shared infrastructure.

The engineering problem

Before SIRIUS, every AI application re-implemented retrieval: bespoke pipelines, bespoke chunking, bespoke access rules, duplicated everywhere and inconsistent between them. Worse,

Architecture

<rect x="280" y="30" width="180" height="50" style="fill:var(--paper);stroke:var(--red)"></rect>
<text x="370" y="52" text-anchor="middle" style="fill:var(--red)">FastMCP Server</text>
<text x="370" y="70" text-anchor="middle" style="fill:var(--dim)">standardized tool surface</text>

<rect x="550" y="20" width="210" height="70" style="fill:var(--paper);stroke:var(--ink)"></rect>
<text x="655" y="42" text-anchor="middle" style="fill:var(--ink)">Retrieval Engine</text>
<text x="655" y="58" text-anchor="middle" style="fill:var(--dim)">tier 1 — site-specific</text>
<text x="655" y="74" text-anchor="middle" style="fill:var(--dim)">tier 2 — global standards</text>

<rect x="550" y="110" width="210" height="56" style="fill:var(--paper);stroke:var(--ink)"></rect>
<text x="655" y="134" text-anchor="middle" style="fill:var(--ink)">Aurora PostgreSQL + pgvector</text>
<text x="655" y="150" text-anchor="middle" style="fill:var(--dim)">vectors beside source of truth</text>

<rect x="550" y="190" width="210" height="56" style="fill:var(--paper);stroke:var(--ink)"></rect>
<text x="655" y="214" text-anchor="middle" style="fill:var(--ink)">ETL Vectorization</text>
<text x="655" y="230" text-anchor="middle" style="fill:var(--dim)">configurations → embeddings</text>

<rect x="280" y="190" width="180" height="56" style="fill:var(--paper);stroke:var(--ink)"></rect>
<text x="370" y="214" text-anchor="middle" style="fill:var(--ink)">Enterprise Configs</text>
<text x="370" y="230" text-anchor="middle" style="fill:var(--dim)">databases · documents · rules</text>

<path d="M190,55 L280,55" style="stroke:var(--ink);fill:none;marker-end:url(#ah4)"></path>
<path d="M460,55 L550,55" style="stroke:var(--ink);fill:none;marker-end:url(#ah4)"></path>
<path d="M655,90 L655,110" style="stroke:var(--red);fill:none;marker-end:url(#ah4)"></path>
<path d="M655,166 L655,190" style="stroke:var(--ink);fill:none;marker-end:url(#ah4)"></path>
<path d="M550,218 L460,218" style="stroke:var(--ink);fill:none;marker-end:url(#ah4)"></path>

Technical design

• Tool surface (FastMCP) — retrieval is exposed as a small set of well-documented MCP tools with typed inputs/outputs, so agents consume context through a contract, not through hand-rolled HTTP calls.
• Vectorization ETL — enterprise configurations flow into the system through a pipeline that chunks, embeds, and indexes them with metadata (site, domain, sensitivity).
• Three-tier retrieval — site-specific knowledge, then global standards, then historical examples, with explicit precedence so conflicting guidance resolves deterministically.
• PostgreSQL + pgvector — vectors live in AWS Aurora PostgreSQL alongside the relational source of truth: one operational surface for backup, HA, and access control.

Key engineering decisions

• Why MCP? It standardizes the agent-to-tool boundary. Consumers came from different frameworks; MCP meant the retrieval layer serves all of them without adapters, and future agents onboard for free.
• Why pgvector in Aurora? Operational simplicity beats theoretical scalability here. The correlation between configurations and their embeddings is a feature: one transaction keeps them consistent.
• Why tiers instead of one flat index? Site precedence rules are a business requirement, not a ranking preference. Encoding them structurally made the behavior explainable to auditors and predictable to developers.

Challenges & solutions

• Chunking structured configuration — naive text chunking destroyed meaning. Solved with structure-aware chunking that respects configuration boundaries.
• Access control for retrieval — not every agent may see every site’s data; enforced per-tier authorization inside the tool layer, never in the client.

Results

• A single, governed retrieval surface replaced per-application retrieval stacks.
• Agent developers integrate enterprise context in days instead of weeks.
• The layer became a dependency of the recipe-authoring agent and other AI platforms.

What I learned

Platform thinking changes the questions: from “how do we retrieve for this app?” to “what does the organization’s knowledge API look like?”. The second question produces systems that compound.

What I would change today

I would add usage observability (which tiers, which queries, which consumers) from day one — it is the key input for tuning the retrieval strategy over time.

Technologies

FastMCP · MCP · PostgreSQL · pgVector · AWS Aurora · Python · FastAPI

the same enterprise knowledge had to be vectorized repeatedly for each consumer. The organization needed one governed, reusable retrieval surface — not N copies.

My role

I architected the platform: the FastMCP tool surface, the vector schema and ETL pipeline that vectorizes enterprise configurations, the three-tier retrieval strategy, and the operational model (deployment, observability, access control) around it.