mcp-data-platform

Documentation | Installation | Quick Start | Go Library

Your AI assistant can run SQL. But it doesn't know that cust_id contains PII, that the table has an open data-quality incident, or who to ask when something breaks.

mcp-data-platform fixes that. It is a single MCP server that connects AI assistants to your data infrastructure and enriches every response with business context from its own catalog: query a table and get its meaning, owners, tags, glossary terms, and open incidents in the same call.

It is a platform, not just a bridge. The same endpoint gives agents persistent memory and a governed path to write knowledge back to the catalog, proxies third-party MCP servers and REST APIs through one authentication, persona, and audit pipeline, and ships a web portal where AI-generated assets are saved, organized into collections, and shared with teammates.

---

The catalog is built in

The platform keeps its own data catalog in PostgreSQL. Every Trino, API and GraphQL connection is scanned into it; people curate it in the portal's Catalog section and agents curate it through apply_knowledge, with every change versioned and reversible. It is the semantic layer cross-enrichment reads, so there is no separate metadata service to run. Trino and S3 are components the platform composes behind provider interfaces; add them when you're ready. Learn why this stack.

Everything runs on PostgreSQL. The gateways, knowledge layer, memory, portal, catalog, and search/fetch need only the database. Without Trino there is nothing to query or enrich, not a smaller platform: query: and toolkits: are independent config blocks. See Deployment Shapes for exactly what each shape includes and leaves out.

---

Why

AI assistants are powerful at querying data, but they work blind. When an agent asks "What's in the orders table?", it gets column names and types. It doesn't know that customer_id is PII, that the table has an open data-quality incident, or who to contact when something looks wrong.

# Without mcp-data-platform
─────────────────────────────────────────────────────────────────────
User:      "Describe the orders table"
AI:        Queries Trino → gets columns and types
User:      "Who owns this data?"
AI:        Searches the catalog → finds owners
User:      "Can I trust this table right now?"
AI:        Reads the catalog again → finds an open incident
User:      "What does customer_id actually mean?"
AI:        Reads the catalog again → finds column descriptions
─────────────────────────────────────────────────────────────────────
4 round trips. Context scattered across conversations. Easy to miss warnings.

# With mcp-data-platform
─────────────────────────────────────────────────────────────────────
User:      "Describe the orders table"
AI:        Gets everything in one response:
           → Schema: columns and types
           → Open incident: late partition for yesterday
           → Owners: Data Platform Team
           → Tags: pii, financial
           → Column meanings and business definitions
─────────────────────────────────────────────────────────────────────
1 call. Complete context. Warnings front and center.

How It Works

sequenceDiagram
    participant AI as AI Assistant
    participant P as mcp-data-platform
    participant T as Trino
    participant C as Platform catalog

    AI->>P: trino_describe_table "orders"
    P->>T: DESCRIBE orders
    T-->>P: columns, types
    P->>C: Get semantic context
    C-->>P: description, owners, tags, terms, incidents
    P-->>AI: Schema + Full Business Context

The platform intercepts tool responses at the protocol level and enriches them with context from the other services. This cross-enrichment is bidirectional:

• Trino to catalog: query results include descriptions, owners, tags, glossary terms, and open incidents
• Catalog to Trino: a dataset read from the catalog says whether it is queryable, on which connection, and roughly how many rows it holds

Does it work? Measured effectiveness

The knowledge layer is not just a design claim; it is benchmarked. On knowledge-trap questions, the ones an agent answers plausibly but wrongly without business context, connecting the agent to the platform's semantic knowledge layer lifts accuracy from 42.7% (raw data tools) to 98.7%, a +56-point gain (95% CI +44 to +67). On plain lookups and arithmetic, where no business context is needed, the platform and bare tools are statistically tied, so the gain is specific to knowledge-gated questions, not a blanket accuracy boost.

This is an arm-vs-arm result on a single pinned model (same model, same tasks, only the platform configuration changes). It measures the knowledge layer specifically, that is cross-enrichment, search, and the memory/apply_knowledge lifecycle, not the whole platform. Every number is recomputed from committed raw data by a notebook that needs no API key. See the full, citable Benchmark Report (four-arm ablation, cold-start learning curve, lifecycle scorecard, threats to validity) and the benchmark report series, which indexes every study's protocol, toolchain, and archived run data.

Features

Each feature links to its full documentation.

Semantic data access

| Feature | Description | |---------|-------------| | Cross-enrichment | Business context added to every tool response automatically, with session dedup to save tokens | | Platform catalog | Every connection scanned into a catalog the portal and agents curate, with lineage recorded as data moves and every change versioned | | Universal search | One search tool fans a query across the catalog, knowledge pages, memory, insights, assets, prompts, and APIs; fetch dereferences any result | | Workflow gating | Session-aware guidance that steers agents to discovery before SQL, with escalating warnings | | Tools | Full tool reference for Trino, S3, knowledge, memory, portal, and gateway toolkits |

Knowledge and memory

| Feature | Description | |---------|-------------| | Memory layer | Persistent agent memory across sessions, PostgreSQL + pgvector, hybrid semantic/lexical recall | | Knowledge capture | Agents record domain insights during sessions; approved knowledge is written to the catalog or canonical knowledge pages | | Governance workflow | Human-in-the-loop review, approve/reject, changeset tracking, and rollback for every applied change | | Managed resources | Human-uploaded reference files (data, visual, playbooks, samples, templates, references) served to agents as MCP resources |

Gateways and extensibility

| Feature | Description | |---------|-------------| | MCP gateway | Re-expose any third-party MCP server through the platform's auth, persona, and audit pipeline | | API gateway | Proxy REST/HTTP APIs (Salesforce, Google, GitHub, Stripe) with four tools instead of one tool per endpoint | | API catalogs | Versioned OpenAPI bundles shared across connections, with semantic endpoint ranking | | REST invoke shim | Call gateway endpoints from NiFi, Airflow, or curl under the same auth and audit pipeline | | Self-configuration | Admins manage personas, connections, and prompts by asking the agent instead of clicking | | MCP Apps | Interactive UI panels rendered inline in the MCP host | | Go library | Import the platform as a library: custom toolkits, providers, and middleware |

Security and operations

| Feature | Description | |---------|-------------| | Authentication | Fail-closed model: OIDC (Keycloak, Auth0, Okta, Azure AD) and API keys for service accounts | | OAuth 2.1 server | A broker, not an identity provider: authorization server with PKCE and Dynamic Client Registration toward MCP clients, delegating every human login upstream to your IdP | | Outbound OAuth | OAuth to upstream MCPs and APIs with encrypted refresh tokens that survive restarts | | [Personas](https://mcp-data-