Choose Cloud SQL’s MCP endpoint before you tune the agent prompt

Google Cloud quietly added specialized endpoint URLs to the remote Cloud SQL MCP server on August 11. For MySQL and PostgreSQL, operators can now connect an AI client to an all-tools endpoint, a read-only endpoint, an instance-management endpoint or a query-execution endpoint. That makes the server URL itself part of the agent’s capability design—not just a connection detail. Google Cloud’s release note names the three specialized toolsets and says they are intended to restrict exposed tools by security and workflow requirements.

Start with the narrowest endpoint

The Cloud SQL MCP documentation maps each URL to a fixed tool subset. /readonly exposes instance, operation and user discovery plus execute_sql_readonly. /instance_manage exposes six tools for listing, reading, creating, cloning and updating instances and checking operations. /query_execution exposes execute_sql and get_operation. The unsuffixed /mcp endpoint exposes every available tool.

That division gives platform teams a concrete rollout sequence. A reporting assistant that only needs to inspect schemas and answer questions should begin on /readonly. An infrastructure workflow should use /instance_manage without also receiving query execution. A SQL-writing agent needs /query_execution, but that endpoint is not “read-mostly”: Google documents execute_sql as accepting valid DDL, DCL, DQL and DML statements. The endpoint limits which MCP tools are advertised; it does not turn a broad SQL executor into a read-only one.

Keep IAM as the enforcement layer

Endpoint selection is only one boundary. Google’s setup guide says MCP calls require the MCP Tool User role, while SQL execution additionally requires Cloud SQL permissions including cloudsql.instances.executeSql and cloudsql.instances.login. It also says SQL runs through an IAM database-authentication account and inherits that account’s database privileges. In practice, teams should pair a narrow toolset URL with a narrowly privileged agent identity rather than treating hidden tools as revoked permissions.

The same guide says Cloud SQL MCP does not accept API keys and recommends a separate identity for agents so access can be controlled and monitored. That gives reviewers two independently checkable controls: which tools the client can see, and what the authenticated principal can actually do.

Turn on query attribution during evaluation

For MySQL and PostgreSQL, both SQL tools accept an optional sql_commenter_enabled=true parameter. Google documents four appended tags: the MCP tool, remote server, authenticated user identity and identified client or agent. Those tags can be inspected in Cloud SQL Studio or Logs Explorer through query and audit logs.

Because tagging is optional, an evaluation should verify it explicitly rather than assume agent-generated SQL will be distinguishable later. A practical acceptance test is therefore three-part: confirm the configured endpoint advertises only the intended tools, attempt a forbidden operation with the agent identity to verify IAM denial, and inspect the resulting query log for the expected MCP attribution. The new endpoint split makes least-capability deployment easier, but only the combined test proves that the boundary survives beyond the prompt.