> [!IMPORTANT] > **Important:** The AlloyDB for PostgreSQL remote MCP server offers a global endpoint and regional endpoints. The Global endpoint is Generally Available. Regional endpoints are in Preview and subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the [Service Specific Terms](https://docs.cloud.google.com/terms/service-terms#1). Pre-GA products and features are available "as is" and might have limited support. For more information, see the [launch stage descriptions](https://cloud.google.com/products#product-launch-stages).
This document shows you how to use the AlloyDB for PostgreSQL remote Model Context Protocol (MCP) server to connect with AI applications including Gemini CLI, ChatGPT, Claude, and custom applications you are developing. The AlloyDB for PostgreSQL remote MCP server lets you access and run AlloyDB tools to manage AlloyDB clusters and instances from your AI-enabled development environments and AI agent platforms. The AlloyDB for PostgreSQL remote MCP server is enabled when you enable the AlloyDB for PostgreSQL API. [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro) (MCP) standardizes how large language models (LLMs) and AI applications or agents connect to external data sources. MCP servers let you use their tools, resources, and prompts to take actions and get updated data from their backend service. ## What's the difference between local and remote MCP servers? Local MCP servers : Typically run on your local machine and use the standard input and output streams (stdio) for communication between services on the same device. Remote MCP servers : Run on the service's infrastructure and offer an HTTP endpoint to AI applications for communication between the AI MCP client and the MCP server. For more information about MCP architecture, see [MCP architecture](https://modelcontextprotocol.io/docs/learn/architecture). ## Stateless core With [MCP version 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28), MCP changes from a bidirectional, stateful protocol to a stateless protocol. Each MCP request is self-describing and can be routed using headers. There isn't a need for the `initialize`/`initialized` handshake or `Mcp-Session-Id` because each request includes all the information needed in HTTP headers or the `_meta` parameter. MCP servers can request additional information required by a tool through [multi-round-trip requests (MRTR)](https://modelcontextprotocol.io/specification/latest/basic/patterns/mrtr). To help route and process requests without parsing the request body, some MCP headers are required, including the following: - Headers that are required by the MCP specification such as the [protocol version header](https://modelcontextprotocol.io/specification/latest/basic/transports/streamable-http#protocol-version-header) and [standard request headers](https://modelcontextprotocol.io/specification/latest/basic/transports/streamable-http#standard-request-headers). - [Custom headers](https://modelcontextprotocol.io/specification/latest/basic/transports/streamable-http#custom-headers-from-tool-parameters) that are defined by the MCP server. These headers are mirrored into HTTP headers from the tool's input schema using the `x-mcp-header` property. For example, an MCP server might define a custom header to specify the Google Cloud region or project ID. For more information about MCP architecture, see the MCP version 2026-07-28 [specification](https://modelcontextprotocol.io/specification/2026-07-28) and [key changes](https://modelcontextprotocol.io/specification/2026-07-28/changelog). You might want to use the AlloyDB local MCP server for the following reasons: - Local development and testing - Offline MCP use - Manage AlloyDB clusters and instances from your AI application For more information about how to use your local MCP server, see [Use AlloyDB for PostgreSQL with MCP, Gemini CLI, and other agents](https://docs.cloud.google.com/alloydb/docs/connect-ide-using-mcp-toolbox) or [AlloyDB for PostgreSQL MCP server](https://github.com/googleapis/mcp-toolbox). The following sections only apply to the AlloyDB for PostgreSQL remote MCP server. ## Google Cloud remote MCP servers Google and Google Cloud remote MCP servers have the following features and benefits:
- Simplified, centralized discovery - Managed global or regional HTTP endpoints - Fine-grained authorization - Optional prompt and response security with Model Armor protection - Centralized audit logging For information about other MCP servers and information about security and governance controls available for Google Cloud MCP servers, see [Google Cloud MCP servers overview](https://docs.cloud.google.com/mcp/overview). ## Limitations The AlloyDB remote MCP server has the following limitations: - The `create_user` tool doesn't support creating a [built-in authentication user with a password](https://www.postgresql.org/docs/16/auth-password.html#AUTH-PASSWORD). A user can only be created with [IAM authentication](https://docs.cloud.google.com/alloydb/docs/database-users/manage-iam-auth). - If the `execute_sql` tool returns a response that's larger than 10 MB, then the response might be truncated. - `execute_sql_read_only` is only supported for PostgreSQL versions 17 and later. ## Before you begin
### Required roles To get the permissions that you need to use the AlloyDB for PostgreSQL MCP server, ask your administrator to grant you the following IAM roles on the project where you want to use the AlloyDB for PostgreSQL MCP server: - Create an AlloyDB instance: [AlloyDB Admin](https://docs.cloud.google.com/iam/docs/roles-permissions/alloydb#alloydb.admin) (`roles/alloydb.admin`) - Create an AlloyDB user: [AlloyDB Admin](https://docs.cloud.google.com/iam/docs/roles-permissions/alloydb#alloydb.admin) (`roles/alloydb.admin`) - Run SQL queries in AlloyDB: - [AlloyDB Admin](https://docs.cloud.google.com/iam/docs/roles-permissions/alloydb#alloydb.admin) (`roles/alloydb.admin`) - AlloyDB Database User (`roles/alloydb.databaseUser`) (Studio Query User (`roles/databasesconsole.studioQueryUser`) also works) - Run read-only SQL queries in AlloyDB: - [AlloyDB Viewer](https://docs.cloud.google.com/iam/docs/roles-permissions/alloydb#alloydb.viewer) (`roles/alloydb.viewer`) - [AlloyDB Admin](https://docs.cloud.google.com/iam/docs/roles-permissions/alloydb#alloydb.admin) (`roles/alloydb.admin`) - [AlloyDB Database User](https://docs.cloud.google.com/iam/docs/roles-permissions/alloydb#alloydb.databaseUser) (`roles/alloydb.databaseUser`) - Get a AlloyDB instance or list all AlloyDB instances in a project: [AlloyDB Viewer](https://docs.cloud.google.com/iam/docs/roles-permissions/alloydb#alloydb.viewer) (`roles/alloydb.viewer`) - List AlloyDB users: [AlloyDB Viewer](https://docs.cloud.google.com/iam/docs/roles-permissions/alloydb#alloydb.viewer) (`roles/alloydb.viewer`) For more information about granting roles, see [Manage access to projects, folders, and organizations](https://docs.cloud.google.com/iam/docs/granting-changing-revoking-access). These predefined roles contain the permissions required to use the AlloyDB for PostgreSQL MCP server. To see the exact permissions that are required, expand the **Required permissions** section: #### Required permissions The following permissions are required to use the AlloyDB for PostgreSQL MCP server: - Make MCP tool calls: `mcp.tools.call` - Create an AlloyDB cluster: `alloydb.cluster.create` - Create an AlloyDB user: `alloydb.users.create` - Clone an AlloyDB instance: `alloydb.instances.create` - Run SQL queries on an AlloyDB instance: - `alloydb.instances.executeSql` - `alloydb.instances.login` - Run read-only SQL queries on an AlloyDB instance: - `alloydb.instances.executeSqlReadOnly` - `alloydb.instances.login` - Get an AlloyDB cluster: `alloydb.instances.get` - Get an AlloyDB cluster operation: `alloydb.clusters.get` - Import data to an AlloyDB cluster: `alloydb.clusters.import` - Export data from an AlloyDB cluster to Cloud Storage: `alloydb.clusters.export` - List AlloyDB clusters in a project: `alloydb.clusters.list` - List AlloyDB users: `alloydb.users.list` - Update an AlloyDB cluster: `alloydb.clusters.update` - Update an AlloyDB user: `alloydb.users.update` You might also be able to get these permissions with [custom roles](https://docs.cloud.google.com/iam/docs/creating-custom-roles) or other [predefined roles](https://docs.cloud.google.com/iam/docs/roles-overview#predefined). ## Authentication and authorization The AlloyDB for PostgreSQL remote MCP server uses the [OAuth 2.0](https://developers.google.com/identity/protocols/oauth2) protocol with [Identity and Access Management (IAM)](https://docs.cloud.google.com/iam/docs/overview) for authentication and authorization. All [Google Cloud identities](https://docs.cloud.google.com/docs/authentication/identity-products) are supported for authentication to MCP servers. The AlloyDB remote MCP server doesn't accept API keys. We recommend that you create a separate identity for agents using MCP tools so that access to resources can be controlled and monitored. For more information on authentication, see [Authenticate to MCP servers](https://docs.cloud.google.com/mcp/authenticate-mcp). ## AlloyDB MCP OAuth scopes OAuth 2.0 uses scopes and credentials to determine if an authenticated principal is authorized to take a specific action on a resource. For more information about OAuth 2.0 scopes at Google, read [Using OAuth 2.0 to access Google APIs](https://developers.google.com/identity/protocols/oauth2). AlloyDB has the following MCP tool OAuth scopes: | Scope URI for gcloud CLI | Description | |---|---| | `https://www.googleapis.com/auth/alloydb` | View, edit, configure, and delete your Google Cloud AlloyDB data, and view the email address for your Google Account. | Additional scopes might be required on the resources accessed during a tool call. To view a list of scopes required for AlloyDB, see [AlloyDB Admin API](https://developers.google.com/identity/protocols/oauth2/scopes#alloydb). ## Configure an MCP client to use the AlloyDB MCP server AI applications and agents, such as Claude or Antigravity, can instantiate an MCP client that connects to a single MCP server. An AI application can have multiple clients that connect to different MCP servers. If your application isn't listed in the [client-specific guidance](https://docs.cloud.google.com/mcp/configure-mcp-ai-application#client-specific-guidance), then you can use the following information to connect from most applications. In your AI application, look for a way to add or connect to a remote MCP server. For the AlloyDB for PostgreSQL MCP server, enter the following information as required: - **Server name**: AlloyDB for PostgreSQL MCP server - **Server URL** or **Endpoint** : `https://alloydb.googleapis.com/mcp` - **Transport** : [Streamable HTTP](https://modelcontextprotocol.io/specification/latest/basic/transports/streamable-http) - **Authentication details** : depending on how you want to authenticate, you can enter your Google Cloud credentials, your OAuth Client ID and secret, or an agent identity and credentials. For more information about authentication, see [Authenticate to MCP servers](https://docs.cloud.google.com/mcp/authenticate-mcp). - **OAuth scope** : the [OAuth 2.0 scope](https://developers.google.com/identity/protocols/oauth2/scopes) that you want to use when connecting to the AlloyDB for PostgreSQL MCP server. For application-specific guidance about setting up and connecting to MCP server, see [Client-specific guidance](https://docs.cloud.google.com/mcp/configure-mcp-ai-application#client-specific-guidance). For more general guidance, see the following resources: - [Connect to remote MCP servers](https://modelcontextprotocol.io/docs/develop/connect-remote-servers). - [Configure MCP in an AI application](https://docs.cloud.google.com/mcp/configure-mcp-ai-application). ## Available tools To view details of available MCP tools and their descriptions for the AlloyDB for PostgreSQL MCP server, see the [AlloyDB for PostgreSQL MCP reference](https://docs.cloud.google.com/alloydb/docs/reference/mcp/alloydb/mcp). ### List tools Use the [MCP inspector](https://modelcontextprotocol.io/docs/tools/inspector) to list tools, or send a `tools/list` HTTP request directly to the AlloyDB for PostgreSQL remote MCP server. The `tools/list` method doesn't require authentication. curl -X POST https://alloydb.googleapis.com/TOOLSET_ENDPOINT \ -H 'Content-Type: application/json' \ -H 'Accept: application/json' \ -H 'MCP-Protocol-Version: MCP_PROTOCOL_VERSION' \ -H 'Mcp-Method: tools/list' \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": { "_meta": { "io.modelcontextprotocol/protocolVersion": "MCP_PROTOCOL_VERSION", "io.modelcontextprotocol/clientCapabilities": { "extensions": { "io.modelcontextprotocol/ui": { "mimeTypes": ["text/html;profile=mcp-app"] } } } } } }' Replace the following: - `TOOLSET_ENDPOINT`: the remainder of the MCP endpoint after the service name. For example, for AlloyDB for PostgreSQL, this might be `mcp/toolset-name`. - `MCP_PROTOCOL_VERSION`: the MCP protocol version. For example, `2026-07-28`. ### Run SQL > [!IMPORTANT] > **Important:** Enabling Data API access on your instance lets authorized users access your instance from the public internet for private IP instances. To execute SQL statements, follow these steps: 1. Set the `data_api_access` instance setting on the AlloyDB instance to the value `ALLOW_DATA_API_ACCESS`. When you create an instance using the `create_instance` tool, the `data_api_access` configuration is enabled automatically. If the `data_api_access` configuration isn't enabled on an instance, you can enable it using the curl command to update the value of the field `dataApiAccess` to `ENABLED`: ``` curl -X PATCH \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ https://alloydb.googleapis.com/v1alpha/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_ID/instances/INSTANCE_ID?updateMask=dataApiAccess \ -d '{ "dataApiAccess": "ENABLED", }' ``` Replace the following: - `PROJECT_ID`: the ID of your Google Cloud project. - `LOCATION`: the region where your AlloyDB cluster is located. - `CLUSTER_ID`: the ID of your AlloyDB cluster. - `INSTANCE_ID`: the ID of your AlloyDB instance. 2. In the Gemini CLI, enter a prompt similar to the following: ` Enable IAM database authentication on the AlloyDB instance INSTANCE_NAME Make sure that the SQL statements use the privileges associated with the IAM database authentication user account USER_ACCOUNT ` Replace the following: - `INSTANCE_NAME`: the name of the AlloyDB instance. - `USER_ACCOUNT`: the IAM user account to use for [authentication](https://docs.cloud.google.com/alloydb/docs/database-users/manage-iam-auth) when executing SQL statements. ## Sample use cases The following are sample use cases for the AlloyDB MCP server. ### Web application development A sample use case might be the rapid development of web applications and the provisioning of AlloyDB instances as their source database. In this use case, using the AlloyDB MCP server lets you build a new database and populate it with initial data for a new project using natural language. **Sample prompt:** "Create a new alloydb PostgreSQL development instance and set up a table called products." **Workflow:** the workflow for setting up a web application might look like the following: - **Provisioning** : The agent creates a cluster that the instance can be allocated in. The agent then calls the `create_instance` tool to create a new AlloyDB instance with development environment-sized specifications. You can [enable Public IP connectivity](https://docs.cloud.google.com/alloydb/docs/connect-public-ip) on the new instance. You can also [automate Private Service Connect](https://docs.cloud.google.com/alloydb/docs/configure-private-service-connect) endpoint configuration. - **Verification** : The agent uses the `get_operation` tool to poll the status of the instance creation operation. - **Connection** : When the operation is complete, the agent uses the `get_instance` tool to retrieve the instance connection metadata. - **Schema setup** : The agent creates the database and then uses the `execute_sql` to run the `CREATE TABLE products` SQL statement. - **Data seeding** : The agent uses `execute_sql` again to insert initial seed data (DML) into the newly created table. ### Operational and database configuration management In this sample use case, you might review existing database instances to help ensure they meet operational configuration standards. You can also use the agent to manage database users on the instance. **Sample prompt**: "List all the PostgreSQL instances in my project and show me their details to verify that they're using the same configuration and that the most recent list database users has been successfully updated." **Workflow**: the workflow for checking AlloyDB instance and database user configuration might look like the following. - **Discovery** : The agent uses `list_instances` to retrieve a list of all AlloyDB instances in the project. - **Inspection** : For each instance identified, the agent calls `get_instance` to fetch detailed configuration metadata, such as the database version, region, and machine type, and calls `list_users` to check the database users on the instance. This metadata includes information about whether [public IP connectivity](https://docs.cloud.google.com/alloydb/docs/connect-public-ip) is enabled or if [Private Service Connect endpoints](https://docs.cloud.google.com/alloydb/docs/configure-private-service-connect) are configured. - **Reporting**: The agent summarizes the findings, highlighting any instances or users that deviate from the expected configuration. ## Optional security and safety configurations MCP introduces new security risks and considerations due to the wide variety of actions that can be taken with MCP tools. To minimize and manage these risks, Google Cloud offers defaults and customizable policies to control the use of MCP tools in your Google Cloud organization or project. > [!NOTE] > **Note:** When you use MCP and you execute SQL on an instance---even with a private IP--- traffic is sent across the internet. For more information about MCP security and governance, see [AI security and safety](https://docs.cloud.google.com/mcp/ai-security-safety). ### Use Model Armor [Model Armor](https://docs.cloud.google.com/model-armor/overview) is a Google Cloud service designed to enhance the security and safety of your AI applications. It works by proactively screening LLM prompts and responses, protecting against various risks and supporting responsible AI practices. Whether you are deploying AI in your cloud environment, or on external cloud providers, Model Armor can help you prevent malicious input, verify content safety, protect sensitive data, maintain compliance, and enforce your AI safety and security policies consistently across your diverse AI landscape. When Model Armor is enabled with [logging enabled](https://docs.cloud.google.com/model-armor/configure-logging), Model Armor logs the entire payload. This might expose sensitive information in your logs. #### MCP request routing to Model Armor Model Armor is available in [certain regions](https://docs.cloud.google.com/model-armor/locations). When Model Armor is enabled and you use an MCP server in a jurisdiction that Model Armor doesn't support, the routing behavior of the call might be different for different MCP servers and might break data residency compliance for in-use and in-transit data. For more information about the behavior of individual MCP servers, see [Model Armor supported products](https://docs.cloud.google.com/mcp/model-armor-supported-products). #### Enable Model Armor You must enable Model Armor APIs before you can use Model Armor.
### Console 1. Enable the Model Armor API, if it is not already enabled. **Roles required to enable APIs** To enable APIs, you need the `serviceusage.services.enable` permission. If you created the project, then you likely already have this permission through the Owner role (`roles/owner`). Otherwise, you can get this permission through the Service Usage Admin role (`roles/serviceusage.serviceUsageAdmin`). [Learn how to grant roles](https://docs.cloud.google.com/iam/docs/granting-changing-revoking-access). [Enable the API](https://console.cloud.google.com/apis/enableflow?apiid=modelarmor.googleapis.com)
2. Select the project where you want to activate Model Armor. ### gcloud Before you begin, follow these steps using the Google Cloud CLI with the Model Armor API: 1. In the Google Cloud console, activate Cloud Shell. [Activate Cloud Shell](https://console.cloud.google.com/?cloudshell=true) At the bottom of the Google Cloud console, a [Cloud Shell](https://docs.cloud.google.com/shell/docs/how-cloud-shell-works) session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
2. Run the following command to use the global API endpoint: ```bash gcloud config set api_endpoint_overrides/modelarmor "https://modelarmor.googleapis.com/" ``` #### Configure protection for Google and Google Cloud remote MCP servers To help protect your MCP tool calls and responses you can use Model Armor floor settings. A floor setting defines the minimum security filters that apply across the project. This configuration applies a consistent set of filters to all MCP tool calls and responses within the project. > [!TIP] > **Tip:** Don't enable the prompt injection and jailbreak filter unless your MCP traffic carries natural language data. Set up a Model Armor floor setting with MCP sanitization enabled. For more information, see [Configure Model Armor floor settings](https://docs.cloud.google.com/model-armor/configure-floor-settings). > [!NOTE] > **Note:** If the agent and the MCP server are in different projects, you can create floor settings in both projects (the client project and the resource project). In this case, Model Armor is invoked twice, once for each project. See the following example command: ```bash gcloud model-armor floorsettings update \ --full-uri='projects/PROJECT_ID/locations/global/floorSetting' \ --enable-floor-setting-enforcement=TRUE \ --add-integrated-services=GOOGLE_MCP_SERVER \ --google-mcp-server-enforcement-type=INSPECT_AND_BLOCK \ --enable-google-mcp-server-cloud-logging \ --malicious-uri-filter-settings-enforcement=ENABLED \ --add-rai-settings-filters='[{"confidenceLevel": "MEDIUM_AND_ABOVE", "filterType": "DANGEROUS"}]' ``` Replace `PROJECT_ID` with your Google Cloud project ID. Note the following settings: - `INSPECT_AND_BLOCK`: The enforcement type that inspects content for the Google MCP server and blocks prompts and responses that match the filters. - `ENABLED`: The setting that enables a filter or enforcement. - `MEDIUM_AND_ABOVE`: The confidence level for the Responsible AI - Dangerous filter settings. You can modify this setting, though lower values might result in more false positives. For more information, see [Model Armor confidence levels](https://docs.cloud.google.com/model-armor/overview#ma-confidence-levels). #### Disable scanning MCP traffic with Model Armor To stop Model Armor from automatically scanning traffic to and from Google MCP servers based on the project's floor settings, run the following command: gcloud model-armor floorsettings update \ --full-uri='projects/PROJECT_ID/locations/global/floorSetting' \ --remove-integrated-services=GOOGLE_MCP_SERVER Replace `PROJECT_ID` with the Google Cloud project ID. Model Armor doesn't automatically apply the rules defined in this project's floor settings to any Google MCP server traffic. Model Armor floor settings and general configuration can impact more than just MCP. Because Model Armor integrates with services like Vertex AI, any changes you make to floor settings can affect traffic scanning and safety behaviors across all integrated services, not just MCP. ### Control MCP use with IAM policies Identity and Access Management (IAM) [deny policies](https://docs.cloud.google.com/iam/docs/deny-overview) and [allow policies](https://docs.cloud.google.com/iam/docs/allow-policies) help you secure Google Cloud and Google MCP servers. You can combine multiple criteria to build customized security and governance policies by allowing or denying access based on the following: - The principal. - Tool properties like the read-only attribute. - The service name or tool name. - The application's OAuth client ID. For more information, see [Control MCP use with Identity and Access Management](https://docs.cloud.google.com/mcp/control-mcp-use-iam). ## What's next - Read the [AlloyDB MCP reference documentation](https://docs.cloud.google.com/alloydb/docs/reference/mcp/alloydb/mcp). - Learn more about [Google Cloud MCP servers](https://docs.cloud.google.com/mcp/overview).