🍳

SQL MCP Server が GA したらしい

に公開

2026 年 6 月に、 SQL MCP Server が GA しました。特にブログなどもなく、Azure Update
でひっそりアナウンスされてました。ちょっと時間があったので、どんなものかいじってみた内容をシェアできればと。

例によって例のごとく、GitHub Copilot さんと一緒にやってみただけなので、参考程度として頂ければと。

SQL MCP Server とは

Data API Builder という、SQL Server、Azure Cosmos DB、PostgreSQL、MySQL など、サポートされているデータベース用の REST API および GraphQL API を作成するツールがあります。SQL MCP Server は、そのツールの一部としてリリースされた機能となります。

MCP Server を公開して、バックエンドの DB に対する操作を担ってくれるもので、AI エージェントから DB が利用できるようになります。具体的には、以下の 7 つの DML ツールが既定で公開され、AI エージェントが呼び出せるようになります。

ツール名 説明
describe_entities 使用可能なエンティティと操作を検出
create_record 新しい行を挿入
read_records テーブルとビューのクエリ
update_record 既存の行を変更
delete_record 行を削除
execute_entity ストアドプロシージャを実行
aggregate_records 集計クエリを実行

実際の使用では、Azure Container Apps にデプロイして使用する想定と思いますが、DAB コマンド ラインを使用してローカルで実行することもできます。ちょっと触ってみたいだけなので、今回はこのローカル実行で動きを確認しました。なので、RBAC の辺りなどは未確認です。

ツールの公開はコントロール可能

デフォルトでは、前述の 7 つの DML ツールが公開されています。エージェントが、ツールのリストを要求すると、7 つすべてのツールに関する情報が返されます。以下、抜粋となりますが、create_record、delete_record といったツールに関する情報が返ってきています。

    {
      "name": "create_record",
      "description": "STEP 1: describe_entities -> find entities with CREATE permission and their fields. STEP 2: call this tool with matching field names and values.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "entity": {
            "type": "string",
            "description": "Entity name with CREATE permission."
          },
          "data": {
            "type": "object",
            "description": "Required fields and values for the new record."
          }
        },
        "required": [
          "entity",
          "data"
        ]
      }
    },
    {
      "name": "delete_record",
      "description": "STEP 1: describe_entities -> find entities with DELETE permission and their key fields. STEP 2: call this tool with full key values.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "entity": {
            "type": "string",
            "description": "Entity name with DELETE permission."
          },
          "keys": {
            "type": "object",
            "description": "All key fields identifying the record."
          }
        },
        "required": [
          "entity",
          "keys"
        ]
      }
    },

ツールの公開については、エンジンを制御するための構成ファイルである dab-config.json ファイルに書くことで、コントロールできます。以下の例では、create-record、update-record、delete-record を false にして、AI エージェントに見えないように設定しています。こうすることで、ツールのリストに載らないようにすることが可能です。正直、適当にレコードの更新されてもアレなので、参照専用にできるのは安心材料かと思いました。

    "mcp": {
      "enabled": true,
      "dml-tools": {
        "describe-entities": true,
        "create-record": false,
        "read-records": true,
        "update-record": false,
        "delete-record": false,
        "execute-entity": true,
        "aggregate-records": true
      }
    },

本命の使い方?カスタム ツール

標準の DML ツールだけでなく、ストアドプロシージャをカスタム ツールとして公開することもできるようです。今回は、ストアドプロシージャ内でトランザクションを開始して、3 つのテーブルを更新するようなストアドプロシージャを作成しました。このストアドプロシージャを、以下のように登録します。パラメータなども指定できますね。

dotnet tool run dab -- add prc_ordercreate `
  --source "dbo.prc_ordercreate" `
  --source.type "stored-procedure" `
  --permissions "anonymous:execute" `
  --description "Create an order transaction: inserts order record, decrements inventory, and increments user order count atomically." `
  --rest false `
  --graphql false `
  --parameters.name "UserId,ProductId,OrderQty" `
  --parameters.description "User ID,Product ID,Order quantity" `
  --parameters.required "true,true,true" `
  --mcp.custom-tool true `
  --config "$resolvedConfigPath"

実際にツールのリスト上では下記のような形でリストされていました。description はツール選択の精度に効く重要情報なので、複数登録する場合はここがキモになりそうですね。

    {
      "name": "prc_ordercreate",
      "description": "Create an order transaction: inserts order record, decrements inventory, and increments user order count atomically.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "OrderQty": {
            "type": "integer",
            "description": "Order quantity"
          },
          "ProductId": {
            "type": "integer",
            "description": "Product ID"
          },
          "UserId": {
            "type": "integer",
            "description": "User ID"
          }
        }
      }
    }

実際に、SQL MCP Server 経由でストアドプロシージャが実行されて、データが更新されることも確認できました。ストアドプロシージャにしてしまえば、必ず同じ形で実行されることが保証されますし、AI エージェントに更新させるワークロードを作るなら、この形が良いんではないかと思いました。

感想

SQL MCP Server を使用することで、AI エージェントに DB を操作させる手段を、簡易に持たせられるようになってます。DB 管理してる側としては、「勝手にいじって欲しくない」という思いもあると思うんですが、その辺も更新系の DML ツールを公開しないといったことができるので対応できるかなと。ただ、複雑なクエリを要求した時にどうなるかとか、やっぱ心配は残るかなと思います。

ストアドプロシージャで、必要そうなものを実装しておいて、それを呼び出させるとかなら、その辺の心配も不要になるかなと(クエリがちゃんとかける前提)。なので、要件に関してはちゃんと確認した上で、必要なカスタム ツールを渡してあげるとかでいいんじゃないのかなーという気がしました。

Microsoft (有志)

Discussion