Starburst’s MCP warning is simple: “read-only” is a hint unless the server enforces it

Starburst has put a useful warning into its latest explanation of agentic analytics: an MCP tool’s readOnlyHint does not itself make database access read-only. The company calls the protocol annotation advisory and says the real security boundary is what the server accepts and executes. Its own Galaxy MCP service parses incoming statements with the Trino SQL parser and rejects writes before they reach a cluster. Starburst’s Oct. 14 guide makes that distinction explicit, while its engineering account documents the implementation in more detail.

A label is not a policy

MCP lets a server describe a tool as read-only, which helps a client or model reason about risk. But that description still depends on the client cooperating. In Starburst’s hosted-MCP architecture, the query tool instead uses an allow-list: SELECT, supported SHOW statements and non-destructive EXPLAIN plans can pass; data-modifying statements are rejected at parse time.

That moves enforcement away from the model. A prompt injection, mistaken tool selection or non-compliant client cannot turn a write into an allowed query merely by ignoring the annotation. The database-facing service remains responsible for classifying the SQL.

Read access and action access are different systems

The newer guide goes one step further. Starburst separates the query path from the action path. Read-only SQL controls determine what an agent may see. If an agent can update a record, open a ticket or trigger another workflow, those operations need a separate control plane and their own authorization rules. That is a cleaner design than quietly adding write-capable tools to the same analytics endpoint.

Galaxy’s hosted service also inherits user permissions through OAuth and Starburst’s RBAC and ABAC controls, records MCP operations in its audit system, and tags agent-originated queries as mcp-query-tool, according to the engineering post. Those controls do not prove that an analytical answer is correct, but they make the access path enforceable and reconstructable.

What practitioners should test

For any database MCP server, ask three separate questions:

1. Does the server merely advertise read-only behavior, or does it reject disallowed statement classes itself?
2. Are row, column and catalog permissions evaluated as the requesting user?
3. Are operational actions isolated from the analytical query endpoint and audited separately?

The practical lesson is not specific to Starburst: tool metadata can communicate intent, but it cannot substitute for a server-side deny decision. Treat readOnlyHint as documentation. Treat parsing, authorization and audit logs as the control boundary.