MCP Semantic Retrieval Platform

Overview

AI agents are only as useful as the enterprise context they can reach. This project 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 this platform, every AI application re-implemented retrieval: bespoke pipelines, bespoke chunking, bespoke access rules, duplicated everywhere and inconsistent between them. Worse,

Architecture

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.