Plexara: A Managed MCP Layer for Data Platforms

I have been assembling data platforms for clients for over twenty years. For most of 2025 I was also writing the glue that let a language model sit on top of them. Plexara is what Deasil Works runs in place of that glue: one MCP URL, in front of the warehouse, the catalog, the object store, and the vendor APIs the platform already talks to, signed in through the customer’s own identity provider, with every call attributed to a person. The software is txn2/mcp-data-platform, Apache-2.0, written in Go. Once the model vendors settled on MCP, the per-vendor harness I had been maintaining had no job left. The platform work did not go away. That work is older, it is harder, and it is what Plexara sells.

§Data Platforms Came First

Data platforms have been Deasil’s business for well over a decade. The verticals rotate; the bill of materials does not.

A national retailer, a couple thousand stores and ten warehouses, needs point-of-sale, inventory, and revenue sitting together, with the ERP and an old mainframe still feeding both. A fleet operator’s telematics arrives at a velocity that breaks most ingest pipelines. A manufacturer needs plant-floor signal, brokered over MQTT, in a place an analyst can query. An oil and gas exploration group needs models stored next to the data they were trained on. A media organization needs streaming, ratings, digital analytics, email, and audience data in one catalog, because the questions cut across all of them. Entertainment, logistics, retail, manufacturing, energy, and public media have each produced at least one of these, and I wrote a 500-page book in 2020 on assembling the common parts on Kubernetes.

The finished platform always looks like the same pile: an object store, a federating query engine, a metadata catalog nobody volunteers to keep current, an identity provider, an operational database or three, and then the part no book covers. That last piece is a large and always growing collection of vendor APIs, because the point-of-sale vendor, the ticketing system, the ad server, the marketing platform, and the fleet hardware each speak their own dialect, and the customer’s questions do not respect those boundaries. The book covered the first five. The API collection is specific to each customer, which is where most of the integration hours go, and has been on every engagement since long before anyone was talking about agents.

In 2020 I stood that inventory up on a four-node cluster that cost a few dollars a day, verbose manifests included, to show that you did not have to rent the cloud-vendor edition to have a working platform. The 2026 series on this site does the same job again with the tooling that exists now, one component at a time. Plexara is the layer that sits on that inventory when a language model is the consumer instead of a dashboard.

§The Glue I Stopped Writing

Mid-2025, those same customers wanted agents on the platforms, and I wrote the plumbing. One Go service per platform. A tool schema in whichever shape that month’s model vendor would accept. A loop that took a function call, turned it into a Trino query or a vendor API request, trimmed the payload to something a context window could hold, and handed it back. Add a second model vendor and you duplicated the schema and the loop. Add a second customer and you duplicated the interfacing code, because their APIs were not the same. I maintained all of it.

Putting a model in front of a warehouse is not difficult. I had already done the equivalent for dashboards, notebooks, and ETL. None of that code survived contact with a second vendor, so hours spent on the harness were hours spent on a layer that would need rewriting the next time a provider changed its tool-calling format. I knew what the shared layer should look like. I was not going to get OpenAI, Anthropic, Google, and Microsoft to agree on it.

§MCP Took the Integration Layer

Anthropic published MCP in November 2024. OpenAI picked it up in March 2025, Google and Microsoft came after, and the spec landed at the Linux Foundation in December 2025. None of that is a new idea. WSDL did discoverable remote procedures with a machine-readable description in 2001. OpenAPI has done it since. What changed is the caller. A language model reads the description and chooses the call, so the description has to be written for a model and the return value has to fit a context window. The problem is still an interface definition. The industry has solved that several times.

A shared protocol meant I could throw the harness out. The client owns the tool-calling loop. The spec owns the schema. I deleted the interfacing code and was left with the platform-facing side: return values a model cannot hallucinate column meanings from, identity held across a call so the warehouse sees a credential it already trusts, an audit row an investigator can read back to a person, and a refusal to run SQL before the catalog has been consulted. Switching protocols does not retire that. A competent analyst does the same work before they trust a table. That is where twenty years of this job apply.

I wrote in January that MCP is flawed and worth building on anyway. Most of the shots are still aimed at thin wrappers stood up carelessly. A thin wrapper runs SQL and dumps rows. The engine under Plexara is the platform side of the problem, with the protocol as a front door. The rest of this note is about that engine.

§The Engine

It started as three small servers: mcp-trino against the warehouse, mcp-datahub against the catalog, mcp-s3 against object storage. Each is a Go library, so one process can load all three and stamp the metadata of one onto the results of another. Composition is the point. I created the repository for the composed platform on January 19, 2026, tagged the first release three days later, and have shipped from it ever since.

Four kinds of backend, and the server will start with any one of them. PostgreSQL is where the platform keeps its own state: sessions, audit, memory, knowledge, saved assets, OAuth state, configuration overrides. DataHub sits behind a provider interface as the semantic layer. Omit the semantic block and that provider is a no-op; the process still boots. Trino is federated SQL over whatever the customer already runs. In practice that is PostgreSQL, MySQL, Snowflake, BigQuery, MongoDB, Elasticsearch, Iceberg tables on an object store, and the thirty-odd other Trino connectors. S3 is the object store, AWS or SeaweedFS or MinIO. Identity is the customer’s OIDC, Keycloak, Okta, Auth0, or Azure AD. The platform brokers OAuth 2.1 toward MCP clients and will not be an identity provider. None of these systems requires the others. The deployment shapes document says which shape needs which backend.

A production deployment shows an agent about three dozen tools, and the bound is the point. Six for Trino, five for DataHub, two for S3. The remainder belong to the platform: search and fetch across sources, memory and knowledge capture, assets and prompts, script execution, and four tools that stand in front of every REST API no matter how many endpoints it has.

platform_info    platform_find_tools   list_connections
search           fetch                 apply_knowledge
memory_capture   memory_manage
trino_query      trino_execute         trino_explain
trino_browse     trino_describe_table  trino_export
datahub_browse   datahub_create        datahub_update
datahub_delete   datahub_get_lineage
s3_list          s3_object
api_discover     api_invoke_endpoint   api_export
save_asset       manage_asset          manage_table
manage_resource  manage_feedback
manage_prompt    show_prompts          manage_script
show_scripts     run_script

The MCP by Design series is where those tools are argued, one mechanism at a time. This note names them and points at the note that covers each.

Cross-enrichment is why DataHub is in the stack, and it was the first feature. trino_describe_table returns Trino’s schema plus DataHub’s owners, tags, glossary terms, quality score, and deprecation status in one payload. Search the catalog and the hits come back marked queryable-or-not, with sample SQL attached. The knowledge loop is the next layer. An agent writes down what it learned. A person reviews it. Approved knowledge goes back into the catalog, or onto canonical pages that link to the assets they describe, so the next session does not start cold. Whether that helps, measured, is the MCP Studies series. On knowledge-trap questions, the ones a model answers fluently and wrongly when it lacks business context, the semantic layer moved a pinned model’s accuracy from 42.7 percent to 98.7 percent. On plain lookups that need no context, the two arms tied. Four reports sit on Zenodo with concept DOIs, and they rerun from committed raw data with no API key.

Most of the design notes went into identity and authorization, because that is where a thin wrapper does the most harm. The platform is an OAuth 2.1 broker in front of the customer’s IdP. The MCP spec wants that shape. It is not a reason to reimplement login. Personas map IdP roles onto an allow list of tools and connections, deny by default. A connection carries the credential. A read-only Trino service account and a write-capable one on the same cluster are two connections. Each persona gets the subset it may reach. The platform does not impersonate the caller downstream. Attribution lives in the audit table: user, persona, connection, sanitized parameters, timing, on every call. Catalog metadata is sanitized before it reaches the model. A tag or an owner note is a place someone can plant an instruction.

The gateways are how the API collection stays tractable. Any REST API that ships an OpenAPI document is fronted by four tools, not one tool per endpoint, and the document is indexed so a search for list customers hits every catalog. Third-party MCP servers come back out through the platform’s own authentication, persona, and audit path. Session handles sit in a tool argument because the protocol dropped them. Starlark is embedded so an agent can write the script that refreshes a dashboard after the conversation ends. Hive maps a CSV in a bucket to a table without ingesting it. Operators get a portal with the audit log, a tool explorer filtered by persona, and knowledge governance. Users get the reports and charts an agent saved, in collections, shareable. Hosts that support MCP Apps render interactive panels inline.

The AI on a Leash standard is the engineering discipline, applied to a tree agents author a large fraction of. The repository carries more test code than production code, 44 linters run on every change, mutation testing covers the public packages with a 60 percent efficacy floor, releases are signed with cosign and ship an SBOM, and the project carries OpenSSF Best Practices and Scorecard badges. The platform also imports as a Go library, so a team that wants its own toolkits, providers, or middleware builds on the same packages rather than forking the binary.

§What You Pay Deasil For

Plexara is that engine, run for you. Deasil deploys it, patches it, watches it, and supports it under an agreement. Pricing is per deployment: how many data sources, how much agent traffic you expect, which support tier. No per-seat charge, because the users are agents and counting seats would be a fiction. Customers point their MCP clients at one URL and run nothing. The software is free. The invoice is operations, support, and someone to call.

Most of a Plexara engagement is not the MCP layer. The site describes three stages: stand up the data platform, put a semantic layer and knowledge capture on it, then hang agents off MCP. Stage three is the engine and is the short one. Stages one and two are the twenty-year business. An organization that has never built a data platform usually finds out there, not at the agent, where the actual gap is. A customer who already has a warehouse, a catalog, and clean identity is connected in a week. A customer who has forty vendor APIs and a shared drive of spreadsheets gets a platform built first, and the MCP endpoint is the last thing that goes live.

Plexara’s site lists what it is not, and that list is the positioning. Other interfaces talk to it, so it is not a chatbot. It does not compete with any model, so it is not a copilot; each model gets better against the same data. It will not execute whatever SQL an agent invents. It is not an AI product built around one model’s current strengths, because those go stale in months. It is not lock-in. The managed service and the open project are feature-identical, no community edition, no enterprise edition. A customer can take the Apache-2.0 engine, their data, and their configuration, and run it on their own infrastructure the next day. I made that argument at length in July and will not recap it past the claim: a managed service should keep a customer on value, never on data they cannot leave with, and the open project is how that claim gets checked.

§Deployments I Can Describe

Deasil’s customers sit under agreements that do not allow me to name them. What I can describe are the shapes. One is a multi-tenant retail analytics platform that pulls point-of-sale, inventory, and revenue reporting across several systems. Five persona types decide which tools and connections each kind of user’s agent is allowed to see. Another is a media and broadcasting platform across six data domains, streaming, ratings, digital analytics, email marketing, audience data, and operational metadata, with more than 140 cataloged entities in the semantic layer the agents are enriched from. The older platforms in energy, logistics, and manufacturing are where the engine’s requirements came from, before there was an engine, and several of them are next.

Note: the tool list earlier in this note was copied off one of those deployments, not off the docs. What an agent can do with that list belongs in the design series.

§What This Note Leaves Out

This note does not install anything. The project documentation has installation, configuration, Docker Compose, and Kubernetes manifests. The July note puts the engine on the cluster the 2026 series builds. The wire protocol is MCP Without the SDK, message by message in Go, no framework. Design decisions are MCP by Design, one mechanism at a time. Whether the design works is MCP Studies.

What exists today is one MCP URL. Any client that speaks the protocol gets a governed, catalog-enriched, audited path into a data platform of the kind Deasil has spent a decade building. Anyone who wants the same software without Deasil can run the Apache-2.0 engine. Organizations that would rather not run it themselves pay Deasil to operate it. The platform will not impersonate a person on the warehouse side; that is a decision, not a missing feature. It will also not assemble the data platform for you. That work is the engagement. I deleted the harness. The platform was the job before MCP showed up, and it still is.