import_data

Import data into a Cloud SQL instance. If the file doesn't start with gs://, then the assumption is that the file is stored locally. If the file is local, then the file must be uploaded to Cloud Storage before you can make the actual import_data call. To upload the file to Cloud Storage, you can use the gcloud or gsutil commands. Before you upload the file to Cloud Storage, consider whether you want to use an existing bucket or create a new bucket in the provided project. After the file is uploaded to Cloud Storage, the instance service account must have sufficient permissions to read the uploaded file from the Cloud Storage bucket. This can be accomplished as follows: 1. Use the get_instance tool to get the email address of the instance service account. From the output of the tool, get the value of the serviceAccountEmailAddress field. 2. Grant the instance service account the storage.objectAdmin role on the provided Cloud Storage bucket. Use a command like gcloud storage buckets add-iam-policy-binding or a request to the Cloud Storage API. It can take from two to up to seven minutes or more for the role to be granted and the permissions to be propagated to the service account in Cloud Storage. If you encounter a permissions error after updatingthe IAM policy, then wait a few minutes and try again. After permissions are granted, you can import the data. We recommend that you leave optional parameters empty and use the system defaults. The file type can typically be determined by the file extension. For example, if the file is a SQL file, .sql or .csv for CSV file. The following is a sample SQL importContext for MySQL. { "uri": "gs://sample-gcs-bucket/sample-file.sql", "kind": "sql#importContext", "fileType": "SQL" } There is no database parameter present for MySQL since the database name is expected to be present in the SQL file. Specify only one URI. No other fields are required outside of importContext. For PostgreSQL, the database field is required. The following is a sample PostgreSQL importContext with the database field specified. { "uri": "gs://sample-gcs-bucket/sample-file.sql", "kind": "sql#importContext", "fileType": "SQL", "database": "sample-db" } The import_data tool returns a long-running operation. Use the get_operation tool to poll its status until the operation completes. It is categorised as a Write tool in the Mcp MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.

import_data accepts 4 parameters: body, project, instance, location. The full parameter table on this page comes from the server's own tool schema.

Register the MCP server in PolicyLayer and add a rule for import_data: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mcp. Nothing to install.

import_data is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.

Yes. Add a rate_limit block to the import_data rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

Set action: deny in the PolicyLayer policy for import_data. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

import_data is provided by the MCP server (https://sqladmin.googleapis.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.