MCP Reference: cloud-sql

Model Context Protocol（MCP）サーバーは、大規模言語モデル（LLM）または AI アプリケーションにコンテキスト、データ、機能を提供する外部サービスとの間のプロキシとして機能します。MCP サーバーは、AI アプリケーションをデータベースやウェブサービスなどの外部システムに接続し、そのレスポンスを AI アプリケーションが理解できる形式に変換します。

サーバーの設定

使用する前に、MCP サーバーを有効にして認証を設定する必要があります。Google と Google Cloud のリモート MCP サーバーの使用方法については、Google Cloud MCP サーバーの概要をご覧ください。

MCP 用 Cloud SQL Admin API

サーバー エンドポイント

MCP サービス エンドポイントは、安全で標準化された接続を確立するために AI アプリケーション（MCP クライアントのホスト）が使用する MCP サーバーのネットワーク アドレスと通信インターフェース（通常は URL）です。これは、LLM がコンテキストをリクエストしたり、ツールを呼び出したり、リソースにアクセスしたりするための接続ポイントとなります。Google MCP エンドポイントをグローバルまたはリージョンにすることができます。

cloud-sql MCP サーバーには、次の MCP エンドポイントがあります。

• https://sqladmin.googleapis.com/mcp

MCP ツール

MCP ツールは、現実世界でアクションを実行する目的で MCP サーバーが LLM または AI アプリケーションに対して公開する関数または実行可能な機能です。

cloud-sql MCP サーバーには次のツールがあります。

MCP ツール
list_instances	プロジェクト内のすべての Cloud SQL インスタンスを一覧表示します。
get_instance	Cloud SQL インスタンスの詳細を取得します。
create_instance	Cloud SQL インスタンスの作成を開始します。 ツールは長時間実行オペレーションを返します。get_operation ツールを使用して、オペレーションが完了するまでステータスをポーリングします。 インスタンスの作成オペレーションには数分かかることがあります。コマンドライン ツールを使用して 30 秒間一時停止してから、ステータスを再確認します。 create_instance ツールを使用してインスタンスを作成したら、create_user ツールを使用して、現在プロジェクトにログインしているユーザーの IAM ユーザー アカウントを作成できます。 data_api_access の値はデフォルトでは ALLOW_DATA_API に設定されています。この設定では、execute_sql ツールと executeSql API を使用して SQL ステートメントを実行できます。 特に指定しない限り、新しく作成されたインスタンスは開発環境のデフォルトのインスタンス構成を使用します。 開発環境のインスタンスのデフォルト構成は次のとおりです。 { "tier": "db-perf-optimized-N-2", "data_disk_size_gb": 100, "region": "us-central1", "database_version": "POSTGRES_18", "edition": "ENTERPRISE_PLUS", "availability_type": "ZONAL", "tags": [{"environment": "dev"}] } 本番環境のインスタンスには、次の構成をおすすめします。 { "tier": "db-perf-optimized-N-8", "data_disk_size_gb": 250, "region": "us-central1", "database_version": "POSTGRES_18", "edition": "ENTERPRISE_PLUS", "availability_type": "REGIONAL", "tags": [{"environment": "prod"}] } SQL Server には次のインスタンス構成が推奨されます。 { "tier": "db-perf-optimized-N-8", "data_disk_size_gb": 250, "region": "us-central1", "database_version": "SQLSERVER_2022_STANDARD", "edition": "ENTERPRISE_PLUS", "availability_type": "REGIONAL", "tags": [{"environment": "prod"}] }
execute_sql	Cloud SQL インスタンスで、データ定義言語（DDL）、データ制御言語（DCL）、データクエリ言語（DQL）、データ操作言語（DML）のステートメントなど、有効な SQL ステートメントを実行します。 execute_sql ツールをサポートするには、Cloud SQL インスタンスが次の要件を満たしている必要があります。 data_api_access の値は ALLOW_DATA_API に設定する必要があります。 MySQL インスタンスの場合、データベース フラグ cloudsql_iam_authentication は on に設定する必要があります。PostgreSQL インスタンスの場合、データベース フラグ cloudsql.iam_authentication は on に設定する必要があります。 execute_sql ツールを呼び出すには、IAM ユーザー アカウントまたは IAM サービス アカウント（CLOUD_IAM_USER または CLOUD_IAM_SERVICE_ACCOUNT）が必要です。このツールは、IAM データベース認証でログインしたデータベース ユーザーの権限を使用して SQL ステートメントを実行します。 create_instance ツールを使用してインスタンスを作成したら、create_user ツールを使用して、現在プロジェクトにログインしているユーザーの IAM ユーザー アカウントを作成できます。 execute_sql ツールには次の制限があります。 SQL ステートメントが 10 MB を超えるレスポンスを返すと、レスポンスは切り捨てられます。 execute_sql ツールのデフォルトのタイムアウトは 30 秒です。クエリの実行時間が 30 秒を超えると、ツールは DEADLINE_EXCEEDED エラーを返します。 execute_sql ツールは SQL Server ではサポートされていません。 「IAM 認証がインスタンスで有効になっていません」のようなエラーが表示された場合は、get_instance ツールを使用して、インスタンスの IAM データベース認証フラグの値を確認できます。 「The instance doesn't allow using executeSql to access this instance」などのエラーが表示された場合は、get_instance ツールを使用して data_api_access 設定を確認できます。 認証エラーが発生した場合: list_users ツールを使用して、現在ログインしているユーザー アカウントがインスタンスの IAM ユーザーとして存在するかどうかを確認します。 IAM ユーザー アカウントが存在しない場合は、create_user ツールを使用して、ログイン ユーザーの IAM ユーザー アカウントを作成します。 現在ログインしているユーザーに適切なデータベース ユーザーロールがない場合は、update_user ツールを使用してユーザーにデータベース ロールを付与できます。たとえば、cloudsqlsuperuser ロールは、IAM ユーザーに必要な多くの権限を付与できます。 現在ログインしているユーザーに、プロジェクトに割り当てられている適切な IAM 権限があるかどうかを確認します。gcloud projects get-iam-policy [PROJECT_ID] コマンドを使用して、ユーザーにプロジェクトに対する適切な IAM ロールまたは権限が割り当てられているかどうかを確認できます。 自動 IAM データベース認証を行うには、ユーザーに cloudsql.instance.login 権限が必要です。 execute_sql ツールまたは executeSql API を使用して SQL ステートメントを実行するには、cloudsql.instances.executeSql 権限が必要です。 必要な権限を含む一般的な IAM ロール: Cloud SQL インスタンス ユーザー（roles/cloudsql.instanceUser）または Cloud SQL 管理者（roles/cloudsql.admin） ExecuteSqlResponse を受け取った場合は、レスポンスの本文内の message フィールドと status フィールドを必ず確認してください。HTTP ステータス コードが成功を示していても、すべての SQL ステートメントが完全に成功するとは限りません。message フィールドと status フィールドは、SQL ステートメントの実行中に部分的なエラーまたは警告が発生したかどうかを示します。
get_operation	長時間実行オペレーションのステータスを取得します。長時間実行オペレーションは、完了するまでに数分かかることがあります。オペレーションに時間がかかる場合は、コマンドライン ツールを使用して 30 秒間一時停止してから、オペレーションのステータスを再度確認します。
create_user	Cloud SQL インスタンスのデータベース ユーザーを作成します。 このツールは、長時間実行オペレーションを返します。get_operation ツールを使用して、オペレーションが完了するまでステータスをポーリングします。 create_user ツールを使用する場合は、ユーザーのタイプ（CLOUD_IAM_USER または CLOUD_IAM_SERVICE_ACCOUNT）を指定します。 リクエストで他のデータベース ロールを明示的に指定しない限り、デフォルトでは、新しく作成されたユーザーに cloudsqlsuperuser ロールが割り当てられます。 新しく作成したユーザーが現在ログインしている IAM ユーザーである場合は、execute_sql ツールでそのユーザーを使用できます。execute_sql ツールは、IAM データベース認証を使用してログインしたデータベース ユーザーの権限を使用して SQL ステートメントを実行します。 create_user ツールには次の制限があります。 パスワード付きの組み込みユーザーを作成することはできません。 create_user ツールは、SQL Server のユーザーの作成をサポートしていません。 PostgreSQL で IAM ユーザーを作成するには: データベース ユーザー名は、IAM ユーザーのメールアドレスで、すべて小文字にする必要があります。たとえば、PostgreSQL IAM ユーザー [e-mail] のユーザーを作成するには、次のリクエストを使用します。 { "name": "[e-mail]", "type": "CLOUD_IAM_USER", "instance":"test-instance", "project": "test-project" } IAM ユーザー用に作成されたデータベース ユーザー名は [e-mail] です。 PostgreSQL で IAM サービス アカウントを作成するには: アカウントの完全なメールアドレスが [e-mail] であっても、データベース ユーザー名は .gserviceaccount.com サフィックスなしで作成する必要があります。たとえば、PostgreSQL 用の IAM サービス アカウントを作成するには、次のリクエスト形式を使用します。 { "name": "[e-mail]", "type": "CLOUD_IAM_SERVICE_ACCOUNT", "instance": "test-instance", "project": "test-project" } IAM サービス アカウント用に作成されたデータベース ユーザー名は [e-mail] です。 MySQL で IAM ユーザーまたは IAM サービス アカウントを作成するには: Cloud SQL for MySQL がユーザー名を格納するときに、ユーザーまたはサービス アカウントのメールアドレスから @ とドメイン名が切り捨てられます。たとえば、[e-mail] は example-user になります。 このため、同じユーザー名で異なるドメイン名の 2 つの IAM ユーザーまたはサービス アカウントを同じ Cloud SQL インスタンスに追加することはできません。 たとえば、MySQL IAM ユーザー [e-mail] のユーザーを作成するには、次のリクエストを使用します。 { "name": "[e-mail]", "type": "CLOUD_IAM_USER", "instance": "test-instance", "project": "test-project" } IAM ユーザー用に作成されたデータベース ユーザー名は example-user です。 たとえば、MySQL IAM サービス アカウント [e-mail] を作成するには、次のリクエストを使用します。 { "name": "[e-mail]", "type": "CLOUD_IAM_SERVICE_ACCOUNT", "instance": "test-instance", "project": "test-project" } IAM サービス アカウント用に作成されたデータベース ユーザー名は service-account-name です。
update_user	Cloud SQL インスタンスのデータベース ユーザーを更新します。update_user の一般的なユースケースは、ユーザーに cloudsqlsuperuser ロールを付与することです。これにより、ユーザーに必要な権限を多数付与できます。 このツールは、ユーザーを更新してデータベース ロールを割り当てる場合にのみ使用できます。 このツールは、長時間実行オペレーションを返します。get_operation ツールを使用して、オペレーションが完了するまでステータスをポーリングします。 update_user ツールを呼び出す前に、list_users ツールを使用して、ユーザーの既存の構成（ユーザータイプなど）を必ず確認してください。 MySQL の特殊なケースとして、list_users ツールが iamEmail フィールドに完全なメールアドレス（{name=test-account, iamEmail=[e-mail]} など）を返す場合は、update_user リクエストで、ツールリクエストの name フィールドの iamEmail フィールドに完全なメールアドレスを使用します。（例: name=[e-mail]）。 ユーザーロールの更新に関する主なパラメータは次のとおりです。 database_roles: ユーザーに割り当てるデータベース ロールのリスト。 revokeExistingRoles: 既存のロールの処理方法を制御するブール値フィールド（デフォルト: false）。 ロールの更新の仕組み: revokeExistingRoles が true の場合: ユーザーに付与されている既存のロールのうち、指定された database_roles リストに含まれていないロールは取り消されます。 取り消しはシステム以外のロールにのみ適用されます。cloudsqliamuser などのシステムロールは取り消されません。 ユーザーがまだ持っていない database_roles リスト内のロールはすべて付与されます。 database_roles が空の場合、既存のシステムロール以外のすべてのロールが取り消されます。 revokeExistingRoles が false の場合（デフォルト）: ユーザーがまだ持っていない database_roles リスト内のロールはすべて付与されます。 database_roles リストにない既存のロールは保持されます。 database_roles が空の場合、ユーザーのロールは変更されません。 例: 既存のロール: [roleA, roleB] リクエスト: database_roles: [roleB, roleC], revokeExistingRoles: true 結果: roleA を取り消し、roleC を付与します。ユーザーロールが [roleB, roleC] になります。 リクエスト: database_roles: [roleB, roleC], revokeExistingRoles: false 結果: roleC を付与します。ユーザーロールが [roleA, roleB, roleC] になります。 リクエスト: database_roles: [], revokeExistingRoles: true 結果: roleA を取り消し、roleB を取り消します。ユーザーロールが [] になります。 リクエスト: database_roles: [], revokeExistingRoles: false 結果: 変更なし。ユーザーロールは [roleA, roleB] のままです。
clone_instance	Cloud SQL インスタンスを、ソース インスタンスのクローンとして作成します。 このツールは、長時間実行オペレーションを返します。get_operation ツールを使用して、オペレーションが完了するまでステータスをポーリングします。 クローン オペレーションには数分かかることがあります。コマンドライン ツールを使用して 30 秒間一時停止してから、ステータスを再確認します。
update_instance	Cloud SQL インスタンスの構成設定を部分的に更新します。 このツールは、長時間実行オペレーションを返します。get_operation ツールを使用して、オペレーションが完了するまでステータスをポーリングします。
list_users	Cloud SQL インスタンスのすべてのデータベース ユーザーを一覧表示します。
import_data	Cloud SQL インスタンスにデータをインポートします。 ファイルが gs:// で始まらない場合、ファイルはローカルに保存されていると見なされます。ファイルがローカルの場合、実際の import_data 呼び出しを行う前に、ファイルを Cloud Storage にアップロードする必要があります。ファイルを Cloud Storage にアップロードするには、gcloud コマンドまたは gsutil コマンドを使用します。 ファイルを Cloud Storage にアップロードする前に、既存のバケットを使用するか、指定されたプロジェクトに新しいバケットを作成するかを検討してください。 ファイルが Cloud Storage にアップロードされた後、インスタンス サービス アカウントには、Cloud Storage バケットからアップロードされたファイルを読み取るための十分な権限が必要です。 これは、次のようにして実現できます。 get_instance ツールを使用して、インスタンス サービス アカウントのメールアドレスを取得します。ツールの出力から、serviceAccountEmailAddress フィールドの値を取得します。 指定された Cloud Storage バケットに対する storage.objectAdmin ロールをインスタンス サービス アカウントに付与します。gcloud storage buckets add-iam-policy-binding などのコマンドまたは Cloud Storage API へのリクエストを使用します。ロールが付与され、権限が Cloud Storage のサービス アカウントに伝播されるまでに、2 ～ 7 分以上かかることがあります。IAM ポリシーの更新後に権限エラーが発生した場合は、数分待ってからもう一度お試しください。 権限が付与されたら、データをインポートできます。オプション パラメータは空のままにして、システムのデフォルトを使用することをおすすめします。通常、ファイルの種類はファイル拡張子で判断できます。たとえば、ファイルが SQL ファイルの場合は .sql、CSV ファイルの場合は .csv です。 MySQL の SQL importContext の例を次に示します。 { "uri": "gs://sample-gcs-bucket/sample-file.sql", "kind": "sql#importContext", "fileType": "SQL" } MySQL には database パラメータはありません。これは、データベース名が SQL ファイルに存在することが想定されているためです。URI は 1 つだけ指定します。importContext 以外のフィールドは必須ではありません。 PostgreSQL の場合、database フィールドは必須です。次に、database フィールドが指定された PostgreSQL の importContext の例を示します。 { "uri": "gs://sample-gcs-bucket/sample-file.sql", "kind": "sql#importContext", "fileType": "SQL", "database": "sample-db" } import_data ツールは、長時間実行オペレーションを返します。get_operation ツールを使用して、オペレーションが完了するまでステータスをポーリングします。

MCP ツールの仕様を取得する

MCP サーバー内のすべてのツールの MCP ツール仕様を取得するには、tools/list メソッドを使用します。次の例は、curl を使用して、MCP サーバー内で現在使用可能なすべてのツールとその仕様を一覧表示する方法を示しています。

Curl リクエスト
curl --location 'https://sqladmin.googleapis.com/mcp' \ --header 'content-type: application/json' \ --header 'accept: application/json, text/event-stream' \ --data '{ "method": "tools/list", "jsonrpc": "2.0", "id": 1 }'