A frontier model can run SQL against everything you have built. That is not the same as understanding it. The model can query a table without knowing that cust_id holds PII, that the table was deprecated last month, or who to ask when a number looks wrong. Hand it raw access and it will confidently do the wrong thing, the way a new hire would on their first day with no one to ask. The fix is to give the model the same context a good engineer has, at the moment it acts, and that is what mcp-data-platform does. It is the Model Context Protocol gateway that ties this whole series together, and I built it for exactly this stack.

This series rebuilds my 2020 Apress book, Advanced Platform Development with Kubernetes, for 2026. The approach behind it comes from building and running data platforms in production for more than twenty years.

§Context at the Protocol Level

MCP is how a frontier model reaches your tools and data. The usual MCP server is a thin wrapper: it lets a model call a tool and hands back the raw result. mcp-data-platform does something more. When an agent queries a table through it, the response is not just rows and a schema; it carries the meaning, the ownership, the quality score, and the deprecation warnings from the DataHub catalog, joined to the live query against the Trino lakehouse. The semantic context you captured in the last post is injected into the answer, automatically, at the protocol level.

That cross-enrichment runs both ways. A Trino query comes back annotated with what the data means; a DataHub search comes back showing which datasets are actually queryable right now. And when an agent skips the discovery step and reaches straight for raw SQL, workflow gating notices and annotates the result with escalating warnings, the digital equivalent of a senior engineer clearing their throat. The goal is to ground the model, so a capable frontier model behaves like someone who knows your platform rather than someone guessing at it.

§What It Does

mcp-data-platform is a substantial project, and every piece of it exists to make a frontier model effective and safe against a real data platform. The capabilities that matter most:

• Bidirectional Trino and DataHub enrichment, so every query carries its meaning and every search carries its queryability.
• Persona-based access control over Keycloak OIDC, with required JWT claims, TLS enforcement, and a fail-closed default. Each role sees a filtered set of tools, so an analyst’s agent and an admin’s agent are not the same agent.
• Persistent memory in Postgres with semantic search across sessions, so an agent remembers what it learned yesterday instead of starting cold every time.
• Knowledge capture, letting agents record domain insights back into the platform, and managed resources for human-curated reference material like playbooks and templates.
• An API gateway that proxies other MCP servers and REST APIs, Salesforce, GitHub, Stripe, Jira, and the rest, through one unified authentication and audit pipeline, so the model reaches the outside world on the same governed path.
• Comprehensive audit logging mapped to user identity, and prompt-injection protection that sanitizes metadata before it ever reaches the model.

All of it runs against the components this series already stood up: Trino, DataHub, Postgres, object storage, and Keycloak. It is the agent-facing side of the platform you built, not a separate one.

§Deploy It

The project installs the way the rest of this series does, from plain manifests, and it is configured with a YAML file that points it at the platform’s services and the Keycloak realm. Give it a mcp database for its audit log, memory, and resources:

apiVersion: postgresql.cnpg.io/v1
kind: Database
metadata:
  name: mcp
  namespace: data
spec:
  cluster:
    name: platform-pg
  name: mcp
  owner: app

Then deploy the server with a config that wires it to Trino, DataHub, the object store, and OIDC. The exact schema lives in the repository; the shape is the platform you already have:

trino:
  host: trino.data
  port: 8080
datahub:
  gms: http://datahub-datahub-gms.data:8080
postgres:
  url: postgresql://platform-pg-rw.data:5432/mcp
storage:
  endpoint: http://seaweedfs.storage:8333
auth:
  oidc:
    issuer: https://auth.apk8s.dev/realms/platform
    audience: mcp-data-platform

Run it over HTTP transport and expose it through the gateway at mcp.apk8s.dev, and any agent that speaks MCP can connect. It authenticates with OAuth 2.1, PKCE and dynamic client registration included, against the same Keycloak realm as everything else, and it is fail-closed: no valid token with the required claims, no access. For Claude Code it is one command, and for a local workflow you can run it over stdio after a go install of the binary instead:

claude mcp add --transport http mcp-data-platform https://mcp.apk8s.dev

§What an Agent Can Now Do

Make it concrete, because the abstract version undersells it. Ask your assistant the question from the OpenSearch post: the top loyalty tiers by average spend. A model with raw Trino access would guess at table and column names and might run a query against a deprecated table holding personal data without knowing it. Through the gateway, the sequence is different. It discovers, via DataHub, that the right dataset is the transactions table, reads the glossary definition of “loyalty tier” so it groups on the correct column, and sees that cust_id carries a PII tag before it touches anything. It runs the governed aggregation, and the result comes back with the column meanings already attached and a note that one field is deprecated in favor of another. It records what it learned to its memory, so the next session starts from that knowledge instead of cold. And every step is logged against your identity through the audit pipeline.

A model that can reach your data and one that understands it are not the same thing. The persona it connected as decided which tools it could even see, so an analyst’s assistant and an administrator’s assistant are genuinely different agents over the same gateway. And when it needs the outside world, a record in Salesforce, an issue in GitHub, it goes through the same gateway’s proxy on the same governed, audited path, rather than a pile of separate credentials. The model does the work; the gateway makes sure it does it on the record, scoped to the persona, and grounded in the catalog.

§Built for This Stack, and Free to Leave

A word on where this comes from, because it is the argument of the whole series made concrete. I built mcp-data-platform, and my company, Deasil Works, sponsors it. It is Apache 2.0, the whole thing, on GitHub at txn2/mcp-data-platform: go install it, read it, fork it, run it. There is no held-back core, no open-core bait where the parts you actually need live behind a license.

Deasil also offers it as a managed product, Plexara, and it is worth being clear about what that is, because for a lot of teams it is the right call. Plexara is the productized, run-for-you build: Deasil deploys it, operates it, patches it, monitors it, supports it under an agreement, and stands behind it, for organizations that want the capability without running the platform themselves. That is a real service Deasil charges for, the same way you might pay someone to run any of the open components in this series rather than operate them yourself. What you are buying is the operations and the support and the accountability, not the software.

Here is the part that matters, and it is the whole series in one sentence: there is no community edition and no enterprise edition. Plexara and the open project are feature-identical. A Plexara customer can move one hundred percent to the Apache-2.0 txn2/mcp-data-platform tomorrow, with no loss of data or functionality, and Deasil will help them do it. The open project is not a lead magnet for the paid one; it is the same thing, and Plexara has to earn its keep every month on value alone.

It is the only model I believe in. A managed service should keep a customer by providing value, the operations, the support, the not-having-to-run-it-yourself, never by holding their data or their features hostage. It is the same principle that put OpenSearch, SeaweedFS, Valkey, and OpenTofu in this platform instead of the projects that closed their gates. I am not going to spend a series arguing against lock-in and then build it into my own product. If Plexara ever stops being worth it, a customer walks to the open project with everything intact, and knowing that is true is exactly why it stays worth it.

§The Platform, Whole

Step all the way back. You started with a cluster you own and ended with a frontier model working across a search engine, a streaming log, a lakehouse, an object store, operational databases, a metadata catalog, dashboards, and dataflows, all of it self-hosted on liberally licensed open source, all behind one single sign-on, all legible to AI through one governed gateway. That is the platform the 2020 book set out to describe, finished for the world as it actually is. The cloud vendors will sell you each piece of this on a meter. You can build the whole thing, own it, and hand it to an agent that runs it better than the experts you used to need.

From here it is icing, and the next posts cover it: self-hosted model inference for the work you want to keep on-cluster, and the vector and embedding layer for semantic search over your own data. But the platform is done. It is yours.