Starburst MCP Server: Governing AI Agent Access to Federated Data

AI agents increasingly need to query enterprise data, not only documents. The Model Context Protocol (MCP) has become a common way to connect an agent to a tool, and Starburst now documents an MCP server for both Starburst Enterprise and Starburst Galaxy. An agent connected this way can discover data, run read-only SQL and, in Starburst Enterprise, call pre-approved query templates and data product tools.

This article explains what Starburst’s MCP server does, how identity, access control and limits work, and what an architecture review should check before agents are allowed near production data. Capabilities differ between Starburst Enterprise and Starburst Galaxy, and by edition, licence and contract.

What the Starburst MCP server is

The Starburst Enterprise MCP server documentation describes a server that lets AI agents and LLM applications query a Starburst cluster through a stateless, authenticated HTTP endpoint. It runs on the coordinator at https://<coordinator-host>:<port>/mcp and is enabled with starburst.mcp.enabled=true in the coordinator configuration. It requires a valid MCP server licence.

The documented tools fall into three groups:

• Read-only query. The agent submits a SQL string and receives a JSON result with the query ID, columns and rows.
• Data products. searchDataProducts and getDataProductDetails return metadata about curated data products, their views and materialized views. These require data products to be enabled.
• Parameterized queries. listParametrizedQueryTools and parametrizedQuery expose query templates defined in YAML files, with validated inputs.

A further tool opens a stateful session with Starburst’s data product AI agent. That tool requires at least one configured language model. Sessions started through MCP appear in the chat history of AIDA, Starburst’s AI data assistant, where they are read-only in the interface.

The Starburst Enterprise versions page listed 482-e as the latest LTS release and 483-e as the latest STS release on the research date. The MCP documentation reviewed here is from the current documentation set. Confirm availability on the release you plan to run.

Galaxy and Enterprise are different routes

Starburst Galaxy offers a hosted MCP server. The Galaxy MCP server documentation describes a per-account endpoint at https://<account-name>.mcp.galaxy.starburst.io, available on the Mission Critical, Enterprise and free trial tiers. Starburst’s engineering blog on hosted MCP explains that it runs as a managed, multi-tenant service inside the Galaxy control plane.

Aspect	Starburst Enterprise	Starburst Galaxy
Where it runs	On your coordinator, in your environment	Hosted by Starburst
Enablement	Coordinator property and an MCP server licence	Available on the listed account tiers
Authentication	The cluster’s configured methods, including OAuth 2.0 and delegated OAuth	OAuth 2.0 with the galaxy.mcp scope; Basic authentication for testing
Queries	Read-only; DDL and DML rejected	Read-only: SELECT, SHOW, EXPLAIN
Result limit	Configurable with mcp.query.max-result-size	Fixed result limit documented by Galaxy
Templates and data product tools	Documented	Not described on the Galaxy MCP page
Role used	The connecting identity’s privileges	The user’s default role; custom role selection not supported

The choice between them usually follows the platform choice already made. A team running Starburst Enterprise on its own infrastructure keeps agent traffic inside its network. A Galaxy customer gets a managed endpoint without running the server. Trino OSS is a separate route: the MCP server described here is documented by Starburst as part of its own products, not as part of Trino.

Identity and access control: the agent is the user

Both routes apply a simple and important rule. The agent acts with the identity of the person or service that connected it.

• In Starburst Enterprise, queries run with the identity from the MCP connection and are subject to that identity’s privileges and access controls. The data product agent uses the same identity.
• In Galaxy, users can only access clusters, catalogs and data permitted by their role’s privileges, and the default role of the authenticated user is used for MCP operations.

This means existing access control does the heavy lifting, which is the right design. It also means weaknesses in existing access control become agent weaknesses. If an analyst’s account can read a table of personal data, an agent connected with that account can read it too, and can do so faster and more broadly than the analyst would by hand.

Practical consequences for design:

• Use dedicated identities for agents where possible, with narrow grants, rather than reusing broad personal accounts.
• Review row filters and column masks on sensitive tables before enabling MCP, not after.
• Prefer OAuth 2.0. The Enterprise documentation notes that dynamic client registration works only if the authorization server supports it, and that Starburst does not manage dynamic clients. Galaxy does not support dynamic client registration and requires an existing OAuth client.

Guardrails built into the server

The Enterprise documentation lists several controls that limit what an agent can do through MCP:

• Read-only enforcement. The query tool rejects statements that include INSERT, UPDATE, DELETE, MERGE, TRUNCATE, GRANT, REVOKE, and CREATE, ALTER or DROP on tables, schemas or catalogs.
• Time and size limits. mcp.query.max-query-execution-time caps run time, and mcp.query.max-result-size caps the result. Results that exceed the limit fail, and the documentation recommends LIMIT clauses or filters.
• Pre-approved templates. Parameterized tools validate inputs with constraints such as allowedValues, and the rendered query must still be read-only.
• Standard resource management. MCP queries follow the cluster’s normal timeouts and resource rules. With fault-tolerant execution, custom retry policies are overridden for MCP queries.

Parameterized templates deserve attention. They let a platform team publish a small set of reviewed questions, such as “revenue by region for a given month”, instead of allowing free-form SQL. The trade-off is flexibility: template definitions load at startup, so each change requires a restart.

The Starburst AI documentation also lists agent guardrails, prompt limiting, topic filtering, auditing of agent interactions and token usage reporting for its AI features. Confirm which of these apply to your licensed edition and to MCP traffic specifically.

Architecture questions to settle first

An MCP server makes agent access easy to switch on. The work is in deciding what agents should be allowed to see and do. Settle these questions before enabling it:

1. Which use cases? Exploration, documentation, analyst assistance and production automation have different risk profiles. Start with read-only, low-sensitivity exploration.
2. Which data? Decide whether agents query raw catalogs, curated data products or only templates. Data products give agents descriptions and context, which improves answers and narrows scope.
3. Which clients? List the MCP clients permitted, where they run and where their model provider processes prompts and results. Query results sent to an external model leave your platform.
4. Which identities? Map each agent or client to an identity with explicit grants. Avoid shared credentials.
5. What evidence? Decide how agent queries will be identified in query history and logs, and who reviews them. Starburst’s engineering blog states that Galaxy records every MCP operation in its audit log and tags MCP queries with the source mcp-query-tool. For Starburst Enterprise, confirm what your configured event listeners and query history capture for MCP traffic.
6. What load? Agents can issue many queries quickly. Use resource groups or equivalent controls so agent traffic cannot crowd out scheduled workloads.

Our enterprise AI and LLMOps architecture places this kind of data access inside a wider design that also covers model gateways, evaluation and observability.

Limits to be honest about

Read-only access reduces risk but does not remove it. A read-only query can still expose sensitive data to a model, return misleading results from a poorly written query, or consume significant cluster resources. Agents can also produce confident summaries of incorrect SQL output. Curated data products, templates and human review of important answers remain necessary.

Queries through MCP run synchronously, so long analytical queries are a poor fit. The documented result-size limits also mean agents are suited to answers and samples, not bulk extraction. Teams that need bulk data movement should keep using pipelines built for that purpose.

Finally, treat every agent as an untrusted client, even when a trusted person connected it. Agents act on instructions that may come from documents, web pages or other tools they have read, and those instructions can steer them towards data the user did not intend to query. Narrow grants, curated data products and templates limit the damage such steering can do. Monitoring agent query patterns, and being able to revoke an agent’s OAuth client quickly, completes the picture. These controls sit partly in Starburst and partly in the identity provider, the MCP client and the organisation’s own AI policy, so ownership of each should be written down.

How Bassirah can help

Starburst is a Bassirah strategic technology partner. We help teams decide whether agent access through Starburst’s MCP server fits their use cases, design identities, grants and templates for it, and test it on non-production data first. See our Starburst partner page and our enterprise AI AgentOps solution. Edition, licensing and support entitlements are confirmed with Starburst in each engagement.