You are about to point an analytical agent at your company's data. Somebody on your team has asked whether Starburst is a safe place to do it, and you have an afternoon to find out. You open the vendor's own writing first, and then you check what the public record says. The two do not quite match.
Start with the writing. In a post called What Is Agentic Analytics?, Starburst, the Trino company, argues that an analytical agent "plans, queries, iterates, and can act." Its common failure, the post says, is missing business context. If an agent does not know that churn means "a cancellation within 30 days," it queries the support table instead of subscriptions, and "the numbers look plausible, but the answer is wrong." You copy down the line that sticks: "Better models don't fix missing definitions." The post carries no market figures, so the only thing you discount is the product pitch.
The governance advice is the substance, and it reads like a checklist you could hand to your security lead. Enforce read-only access on the query path. Apply RBAC and ABAC. Log audit trails from day one. Align Iceberg snapshot expiration with compliance policy "so that past agent queries can be accurately reconstructed."
Then you reach the paragraph on MCP, which is the one that matters to you. It is blunt: "its protocol-level read-only signals are purely advisory. True security depends entirely on what the server enforces." Starburst says it does that enforcing server-side. It parses every request through the Trino SQL parser and rejects writes before execution. It also says it exposes its context layer "to external agents through an MCP endpoint." You note that this is a specific claim, and a checkable one, which counts in the company's favor.
So you check it. You go to the Starburst provider page in the APIs.io catalog and find one API page, the Starburst Galaxy REST API. The catalog describes it as an OAuth2 client-credentials API for clusters, catalogs, users, roles, privileges, access policies, data products and SQL jobs. That is the management surface for the data products and access policies the post tells you to build first, so it is useful. But it is not the endpoint your agent would talk to.
The MCP endpoint does not appear as an API page. Neither does AIDA, the agent the post holds up as the pattern to follow. There is no agentic access profile either. You look for the thing the vendor says is real, and the catalog has nothing filed under it.
The scores say the same thing in numbers. Starburst scores 37.8 on the Kin Score, which is the thin band. Discoverability is 73.2 and developer ergonomics 64.3, so the company is easy to find and reasonable to work with. Contract quality is 0.0 and contract governance is 4.5. Agent Readiness is 2.5, which the catalog labels human-only. Auth clarity is the only dimension lit. Spec presence, agentic access and MCP server are all unlit.
Here is the turn you should hold onto. The company that wrote "true security depends entirely on what the server enforces" understands better than most that an agent can only trust what it can read. Its MCP endpoint is, by its own account, real. But until that endpoint is published where a crawler can find it, the public record measures Starburst as a platform agents cannot reach. The gap is in the record, not necessarily in the product. The catalog cannot verify the server-side read-only enforcement, and this post does not claim it is absent.
What you take away is practical. For your afternoon, treat Starburst's description as a claim worth testing, not a fact you can cite in a review. Ask the vendor for the endpoint, its documentation and the evidence of the write-rejection behavior, and do not let the catalog's low agent score stand in for a verdict on the product. More broadly, when you evaluate any platform for agents, separate what the company says from what its public record lets you confirm. A vendor who writes about governance carefully has done half the work. The other half is publishing the endpoint where you, or your tooling, can find it.
Read the original: https://apis.io/2026/10/27/starburst-describes-an-mcp-endpoint-its-public-record-does-not-show/