Mcp Data Platform

[](https://mcp-data-platform.txn2.com)

[](https://github.com/txn2/mcp-data-platform/blob/main/LICENSE) [](https://pkg.go.dev/github.com/txn2/mcp-data-platform) [](https://codecov.io/gh/txn2/mcp-data-platform) [](https://goreportcard.com/report/github.com/txn2/mcp-data-platform) [](https://scorecard.dev/viewer/?uri=github.com/txn2/mcp-data-platform) [](https://slsa.dev)

Documentation | Installation | Library Docs

Your AI assistant can run SQL. But it doesn't know that cust_id contains PII, that the table was deprecated last month, or who to ask when something breaks.

mcp-data-platform fixes that. It connects AI assistants to your data infrastructure and adds business context from your semantic layer. Query a table and get its meaning, owners, quality scores, and deprecation warnings in the same response.

The only requirement is DataHub as your semantic layer. Add Trino for SQL queries and S3 for object storage when you're ready. Learn why this stack →

MCP Data Platform Ecosystem

mcp-data-platform is the orchestration layer for a broader suite of open-source MCP servers designed to work together as a composable data platform. Each component can run standalone or be combined through mcp-data-platform for unified access with cross-enrichment, authentication, and personas.

• txn2/mcp-datahub — DataHub metadata catalog: search, lineage, glossary terms, domains, tags, and ownership
• txn2/mcp-s3 — S3 object storage: list buckets, browse prefixes, read objects, generate presigned URLs
• txn2/mcp-trino — Trino distributed SQL: query any data source Trino connects to with configurable timeouts and row limits

The platform also includes a gateway toolkit that re-exposes any well-behaved third-party MCP server through the platform's auth, persona, and audit pipeline. Operators add connections through the admin portal (DB-backed, encrypted credentials); tools surface as __. Optional declarative cross-enrichment rules join proxied responses with Trino queries or DataHub lookups, so a vendor MCP can return its own data plus warehouse context in a single call.

For REST/HTTP APIs that aren't MCP servers, the API gateway toolkit (kind: api) proxies upstreams like Salesforce, Google APIs, GitHub, and Stripe through the same pipeline. Four tools (api_invoke_endpoint, api_list_endpoints, api_list_specs, api_get_endpoint_schema) cover every operation on every upstream; api_list_specs lets the model browse a multi-spec catalog's sections before drilling into one. Auth modes cover bearer, API key, HTTP Basic (RFC 7617, for legacy APIs like Jenkins or on-prem Jira), OAuth 2.1 clientcredentials, and OAuth 2.1 authorization_code with browser sign-in. static_headers adds operator-supplied per-call headers alongside the auth header, so APIs that require both an OAuth bearer AND a project/subscription header (Google's x-goog-user-project for quota billing, vendor subscription keys) work without code changes. A REST shim at POST /api/v1/gateway/{connection}/invoke exposes api_invoke_endpoint to non-MCP HTTP clients (Apache NiFi, Airflow HttpOperator, curl) using the same Authorization/X-API-Key headers, persona allowlists, route-policy gates, and audit pipeline. A global in-flight memory budget (apigateway.memory.max_in_flight_bytes) bounds the bytes committed to api_invoke_endpoint response buffering across all connections, so a burst of large responses cannot OOMKill the pod — excess requests get a retryable 429. api_export streams the upstream response directly to S3 (multipart, no full-body buffer) so it stays at bounded memory regardless of size and is exempt from the budget. For large or binary downloads, POST /api/v1/gateway/{connection}/invoke-raw streams the upstream body straight to the client at bounded memory, still injecting the held credential (a 413 rejects bodies over raw_max_bytes).

OpenAPI specs are stored in versioned API catalogs: globally-owned bundles of component specs that any number of connections can reference. One Google Workspace catalog (drive.yaml, calendar.yaml, gmail.yaml) backs every Google Workspace connection in the deployment; an organization running a Salesforce sandbox and a Salesforce production org points both connections at one Salesforce catalog. Specs ingest via paste, file upload, or HTTPS URL (with strict SSRF guards); mutations fan out to live connections without a process restart.

---

Why mcp-data-platform?

The Problem: AI assistants are powerful at querying data, but they're working blind. When Claude asks "What's in the orders table?", it gets column names and types. It doesn't know:

• The customer_id column contains PII requiring special handling
• The table is deprecated in favor of orders_v2
• The data quality score dropped last week
• Who to contact when something looks wrong

The Solution: mcp-data-platform adds semantic context at the protocol level. Your AI assistant gets business meaning automatically—before it even asks.

Without vs With

# Without mcp-data-platform
─────────────────────────────────────────────────────────────────────
User:      "Describe the orders table"
AI:        Queries Trino → gets columns and types
User:      "Who owns this data?"
AI:        Queries DataHub → finds owners
User:      "Is this table still active?"
AI:        Queries DataHub again → finds deprecation status
User:      "What does customer_id actually mean?"
AI:        Queries DataHub 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
           → ⚠️ DEPRECATED: Use orders_v2 instead
           → Owners: Data Platform Team
           → Tags: pii, financial
           → Quality Score: 87%
           → 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 D as DataHub

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

The platform intercepts tool responses and enriches them with semantic metadata. This cross-enrichment pattern means:

• Trino → DataHub: Query results include owners, tags, glossary terms, deprecation warnings, quality scores
• DataHub → Trino: Search results include query availability (can this dataset be queried? what's the SQL?)
• S3 → DataHub: Object listings include matching dataset metadata
• DataHub → S3: Dataset searches show storage availability

---

Features

Semantic-First Data Access

Every data query includes business context from DataHub. Table descriptions, column meanings, data quality scores, and ownership information flow automatically. Your AI assistant understands what data means, not just what it contains.

Bidirectional Cross-Enrichment

Context flows between services automatically. Trino results come enriched with DataHub metadata. DataHub searches show which datasets are queryable in Trino. No manual lookups or separate API calls needed.

Workflow Gating

LLM agents tend to skip DataHub discovery and jump straight to SQL. Session-aware workflow gating detects this and annotates query results with warnings when no discovery has occurred. Warnings escalate after repeated violations. Built-in description overrides on trino_query and trino_execute also guide agents to call search first. A platform-owned instruction baseline (versioned with the release, layered beneath the admin's agent_instructions, and naming only tools the caller's persona can reach) carries the search-first operating model to every deployment without per-deployment edits, so admins write business context rather than restating how to operate. See the Middleware Reference for details.

Enterprise Security

Built with a fail-closed security model. Missing credentials deny access—never bypass. TLS enforcement for HTTP transport, prompt injection protection, and read-only mode enforcement for sensitive environments. See MCP Defense: A Case Study in AI Security for the security architecture rationale.

OAuth 2.1 Authentication

Native support for OIDC providers (Keycloak, Auth0, Okta), API keys for service accounts, PKCE for public clients, and Dynamic Client Registration. Claude Desktop can authenticate through your existing identity provider. Outbound gateway connections send oauth_scope to the IdP verbatim — operators add offline_access (Keycloak/Auth0/Okta) or refresh_token (Salesforce) themselves to get refresh tokens that survive platform restarts beyond the IdP's interactive SSO session timeout.

Live Tool Inventory Updates

When a gateway upstream re-authenticates or a connection is added/removed, downstream agents (Claude.ai, Claude Desktop) receive a notifications/tools/list_changed event over a long-lived SSE channel — no disconnect / reconnect required. Works in stateless streamable-HTTP mode (the multi-replica deployment shape) via a postgres LISTEN/NOTIFY broadcaster; falls back to in-memory fan-out for single-replica deployments.

Role-Based Personas

Define who can use which tools. Analysts get read access to queries and searches. Admins get everything. Tool filtering uses wildcard patterns (allow/deny rules) mapped from your identity provider's roles.

Comprehensive Audit Logging

Every tool call is logged with user identity, persona, request details, and timing. PostgreSQL-backed for querying and compliance. Know who queried what, when, and why.

Prometheus Metrics

OpenTelemetry instrumentation exposes /metrics on a dedicated :9090 listener. Phase 1 instruments two chokepoints: every MCP tool call (mcp_tool_calls_total, mcp_tool_call_duration_seconds, mcp_inflight_tool_calls) and every apigateway outbound HTTP call (apigateway_outbound_total, apigateway_outbound_duration_seconds), each with a small, bounded label set (tool, toolkit_kind, persona, status_category, connection, http_status_class). High-cardinality fields like user id and raw URLs are deliberately kept off labels and reserved for traces (Phase 2). Enabled by default; set OTEL_METRICS_ENABLED=false to disable. See the Observability documentation for details.

Persistent Memory

Agents accumulate knowledge across sessions: preferences, corrections, domain context, and institutional facts. Backed by PostgreSQL with pgvector for semantic search. The memory_manage tool provides CRUD operations; reading memory back (relevance, entity lookup, and DataHub lineage traversal) is part of the universal search tool. Hybrid ranking improves recall on identifier-heavy content, and ranking degrades gracefully to lexical-only when the embedder is unavailable. A reconciler backfills embeddings missed during an outage or invalidated by a model swap. Memories are automatically added to toolkit responses via the cross-enrichment middleware. A staleness watcher flags memories when referenced DataHub entities change. Scoped by user and persona with full audit logging. See the Memory Layer documentation for details.

Knowledge Capture

AI sessions generate valuable domain knowledge: column meanings, data quality issues, business rules. The memory_capture tool records these observations during sessions (one verb, routed by sink-class, recall-first), and apply_knowledge provides admins with a structured review workflow to promote reviewed captures. Approved insights are written back to DataHub with full changeset tracking and rollback. search is the universal, topology-free discovery entry point: a single query fans across the technical catalog and its context documents, canonical knowledge pages, the caller's memory, captured insights, the caller's feedback, saved assets, prompts, API endpoints, and connections, returning a balanced, grouped-by-source, per-user-scoped result set with a coverage summary so the agent sees breadth it would otherwise miss. Search returns navigational pointers with truncated snippets; the companion fetch tool dereferences any reference search emits (a knowledge page, context document, catalog dataset, saved asset, prompt, connection, captured insight, or personal memory record) back to its full content, honoring the same per-user scope so it never reads what search could not surface. The per-user forms (memory and insights) are fetch-only and not citable on a shared page: a private record would resolve only for its owner, so an insight is instead promoted to the catalog and cited as its urn:li:... entity. A browse mode on search (one source, no intent, an offset) enumerates a corpus in full with a total count and no relevance threshold, so an agent can audit or migrate the knowledge pages and context documents that ranked search cannot list. Knowledge pages stay de-duplicated and navigable: creating a page whose content closely matches an existing one is blocked with the matching pages returned (re-apply against one to update it, or pass force_new to create a distinct page), an oversized page gets a non-blocking suggestion to split into focused sub-pages, and a fetch returns a page's outbound references so an agent can deep-crawl a graph of focused, cross-linked pages (with thin index pages) rather than one sprawling page. An Admin REST API supports integration with existing governance tools. See the Knowledge Capture documentation for details.

Resource Templates

Browse platform data as parameterized MCP resources using RFC 6570 URI templates. Three built-in templates expose table schemas (schema://catalog.schema/table), glossary terms (glossary://term), and data availability (availability://catalog.schema/table) without making tool calls.

Managed Resources

Human-uploaded reference material (samples, playbooks, templates, references) surfaced directly to AI assistants via MCP resources/list and resources/read. Resources are scoped to three visibility levels: global (visible to all authenticated users), persona (visible to users in a specific persona), and user (visible only to the owner). Metadata is stored in PostgreSQL; file blobs are stored in S3. A REST API at /api/v1/resources provides CRUD operations, and the Admin Portal includes a dedicated Resources page for uploading, browsing, and managing resources. Enabled automatically when a database is available.

Progress Notifications

Long-running Trino queries send granular progress updates to

…

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: txn2
• Source: txn2/mcp-data-platform
• License: Apache-2.0
• Homepage: http://mcp-data-platform.txn2.com/

Install and usage instructions live in the source repository linked above.