Mcp Server Trino Presto

An MCP server on Trino (or Presto) should connect through a dedicated resource group, authenticate via OAuth, and expose only the catalogs the agent needs. That setup turns a federated query engine into a safe agent backend that can span S3, Iceberg, Hive, and Postgres from one MCP endpoint.

Trino and Presto are the canonical federated query engines, which makes them unusually powerful MCP targets — one server can access every source in the data platform. This guide covers the production setup: authentication, resource groups, catalog exposure, query policies, and observability.

Federated Queries Change the Game

Most MCP servers talk to one database. Trino and Presto talk to any number of catalogs, so a single MCP endpoint can reach Iceberg lakes, Hive tables, Postgres OLTP, Kafka streams, and object storage without wiring up separate connectors. That is enormous leverage for an agent — but it also means the blast radius is the union of every catalog, so scoping matters more than ever.

Treat the MCP role as if it will query anywhere the engine can reach. If you do not want the agent touching the production OLTP catalog, do not expose that catalog to the MCP user. Trino's catalog-level access control makes this easy, but you have to use it.

OAuth Authentication

Modern Trino supports OAuth 2.0 via the JWT authenticator. Wire your identity provider (Okta, Google Workspace, Azure AD) to Trino and register the MCP server as a service application. The agent presents a signed JWT, Trino validates it, and maps the subject to a Trino user with catalog-level grants. This keeps auth consistent with the rest of the company.

• •OAuth / JWT — identity provider integration
• •TLS required — HTTPS coordinator only
• •Catalog-level access control — allowlist not denylist
• •System rules file — governs schemas and tables
• •Audit logging — every query logged to the event listener

Resource Groups

Trino's resource groups are the federated equivalent of Redshift's WLM queues. Create a group called agents with a memory limit, concurrency cap, and query priority that sit below the analyst queue. Route MCP queries to that group via a session property or selector rule, and agents cannot starve human users even under heavy load.

Catalog Allowlist

Trino's file-based access control lets you declare which catalogs, schemas, and tables a user can read. For the MCP agent, write an explicit allowlist: hive.default.*, iceberg.analytics.*, postgres.public.users_view. Everything else is denied by default. Do not start from a denylist — it is impossible to enumerate every dangerous table.

Query Policies and Timeouts

Set query.max-execution-time to 10 minutes and query.max-memory-per-node to a fraction of worker RAM. Those two settings prevent a single agent query from monopolizing the cluster. Add query.max-scan-physical-bytes for an extra safety net on Iceberg and Hive catalogs that back onto cheap object storage.

Observability with the Event Listener

Trino's event listener interface emits a structured event for every query, including user, catalog, SQL text, duration, bytes scanned, and cost. Point the listener at your log pipeline and you have a complete audit trail of agent activity. Starburst Galaxy ships this out of the box; open-source Trino needs a plugin like the Kafka event listener.

Data Workers on Trino

Data Workers' Trino connector handles OAuth, routes queries to the agent resource group, enforces catalog allowlists, and joins query events with the agent audit trail. It treats federated sources as a single virtual warehouse while keeping governance consistent. See AI for data infrastructure or read MCP server Databricks Unity Catalog for the lakehouse equivalent.

To see a Trino MCP server spanning multiple catalogs with resource groups and OAuth, book a demo. We will walk through allowlist setup, group routing, and event listener integration.

One advanced pattern is the shadow catalog: expose a read-only virtual catalog that maps to a subset of production catalogs with extra governance rules applied. The agent sees a curated view that combines tables from several source catalogs, with PII columns masked and row filters applied consistently. This is much easier than reconfiguring every source catalog to be agent-safe, and it gives you a single place to update policy as requirements change.

Trino's federation is also a double-edged sword on cost. A query that joins an Iceberg table on cheap object storage to a Postgres OLTP table on expensive compute can drive up the Postgres load dramatically. The MCP server should monitor query plans and warn the agent when a query is about to push load onto a sensitive source. Starburst's query analyzer and the open-source EXPLAIN facility both help here — expose them to the agent as a pre-flight check.

For teams adopting the open data lakehouse with Iceberg or Delta, Trino is often the query engine that makes the lakehouse usable. An MCP server on Trino then becomes the single point of agent access to the whole lakehouse, which is a strategic capability: one server, one auth model, one audit trail, covering every table in the organization. That kind of consolidation is rare enough that Trino MCP is often worth the extra setup effort just for the governance benefits.

Trino and Presto give MCP the widest reach of any backend — a single endpoint can query everywhere. Scope catalogs explicitly, isolate agents in their own resource group, and log every event to make that reach safe.