MCP Toolbox for Databases：把 Agent 接資料庫這件事標準化

現在談 AI agent，大家很容易把焦點放在 model、framework 或 prompting。

但一進到企業場景，真正麻煩的地方通常不是「agent 夠不夠聰明」，而是「它要怎麼安全、穩定、可治理地碰資料」。

這也是我覺得 MCP Toolbox for Databases 值得注意的原因。

它不是另一個 agent framework。更準確地說，它比較像一層把 database access 工程化的 tool layer。上面可以接 IDE、CLI、agent framework 或自建應用，下面接各種資料來源，中間用一致方式定義工具、權限與暴露面。

如果把名詞拆開來看，差別會更清楚：

名稱	主要解的問題	在架構裡比較像什麼
MCP	client 和 server 怎麼標準化溝通	protocol
MCP Toolbox	怎麼把資料能力包成可重用、可治理的工具	server + tool framework

先講結論

如果要用一句話介紹它，我會這樣說：

MCP Toolbox for Databases 是一個開源的 MCP server，也是一個 tool framework。它把資料庫能力包成可重用、可治理的 tools，讓 AI agents、IDEs 和應用程式能用比較一致的方式接到企業資料。

這個專案早期叫做 Gen AI Toolbox for Databases，後來正式對齊 Model Context Protocol，repo 和文件也一起改名為 MCP Toolbox for Databases。

這個 rename 不只是品牌調整。它更像是在表態：這個專案的重點不是替某個 agent framework 做 integration，而是想成為 MCP 生態裡的資料接入層。

MCP 解的是協定，Toolbox 解的是落地

MCP 解的是 protocol 問題，例如：

client 和 tool server 怎麼溝通
tool manifest、參數 schema、呼叫流程怎麼標準化

但只靠 protocol，還不夠把 agent 真正接到資料庫。實務上你還要處理不少事情：

database connection lifecycle
connection pooling
authentication and authorization
query safety
observability
tool definition and reuse

如果這一層每個團隊都自己做，最後很常變成：

demo 可以跑
production 不好治理
換一個 client 或 framework 就得重包一次

MCP Toolbox 的價值，就是把這層收斂成現成的 server 與 tool framework。

flowchart LR
    A[Gemini CLI / Claude Code / Codex / Agent App] --> B[MCP Toolbox]
    B --> C[Postgres / MySQL / BigQuery / Cloud SQL / Spanner / Neo4j ...]

所以更精確地說，MCP 是溝通規格，MCP Toolbox 則是把這個規格變成可部署、可共用、可治理的資料接入實作。

它其實有兩種用法

官方文件目前把 MCP Toolbox 的角色拆成兩個面向：

模式	適合場景	你得到什麼
Ready-to-use MCP Server	想快速把 IDE 或 CLI 接到資料庫	用 `--prebuilt=<database>` 拿到現成 generic tools
Custom Tools Framework	想做 production-ready agent tools	用設定檔定義可治理、可重用的 domain tools

第一種用法很直觀，就是先把資料接進來。

{
  "mcpServers": {
    "toolbox-postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@toolbox-sdk/server",
        "--prebuilt=postgres",
        "--stdio"
      ]
    }
  }
}

配好 environment variables 之後，就能直接拿到像 list_tables、execute_sql 這類通用能力。這很適合 demo、PoC 或教學，因為你不用先寫一堆 server code 或 MCP wrapper。

第二種用法比較重要，也更接近真正落地。

當你知道 agent 常做的是「查詢訂單狀態」或「搜尋符合條件的飯店」，你通常就不會想一直把 generic SQL tool 直接丟給它。你會想把操作收斂成比較窄、比較穩、比較容易審計的 domain tools。

常見例子像是：

查詢某個訂單狀態
搜尋符合條件的飯店
只讀某些 schema 的分析工具
帶權限與參數限制的 NL2SQL tool

這時候，MCP Toolbox 的角色就不只是 MCP server，而更像一層 tool governance。

而且它不是非黑即白。現在的文件也明確支援把 --prebuilt 和自訂 config 混著用。你可以先用 generic tools 把流程跑通，再慢慢補成自己的 domain tools，不用一開始就把整套治理做完。

一個簡單例子就能看出差別

如果只是要先驗證 Claude Code、Gemini CLI 或其他 MCP client 能不能碰 PostgreSQL，prebuilt mode 就夠了：

{
  "mcpServers": {
    "toolbox-postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@toolbox-sdk/server",
        "--prebuilt=postgres",
        "--stdio"
      ]
    }
  }
}

再配上基本連線資訊：

export POSTGRES_HOST=127.0.0.1
export POSTGRES_PORT=5432
export POSTGRES_DATABASE=toolbox_db
export POSTGRES_USER=toolbox_user
export POSTGRES_PASSWORD=my-password

這樣的好處很直接：

不用先寫 server code
不用先包自己的 MCP tool
很快就能測 schema、查資料、驗證互動流程

但如果要進 production，通常就不該讓 agent 永遠拿著 execute_sql 到處跑。這時比較合理的做法會像下面這樣，用 tools.yaml 定義收斂過的 domain tool：

kind: source
name: my-pg-source
type: postgres
host: 127.0.0.1
port: 5432
database: toolbox_db
user: toolbox_user
password: ${POSTGRES_PASSWORD}
---
kind: tool
name: search-hotels-by-location
type: postgres-sql
source: my-pg-source
description: Search for hotels based on location.
annotations:
  readOnlyHint: true
parameters:
  - name: location
    type: string
    description: The location of the hotel.
statement: SELECT * FROM hotels WHERE location ILIKE '%' || $1 || '%';
---
kind: toolset
name: booking-agent
tools:
  - search-hotels-by-location

這段設定最重要的不是 SQL 本身，而是它把幾件事固定下來：

agent 只能做特定動作，不是任意查
參數結構是清楚的
tool 可以帶有 read-only 語意
不同 agent 可以用不同 toolset 切開能力範圍

也就是說，從這一步開始，你不再只是讓 agent 連資料庫，而是在定義它可以做什麼、不能做什麼。

如果你有自己的應用程式，也可以直接把這些 tools 載進去：

import { ToolboxClient } from '@toolbox-sdk/core';

const client = new ToolboxClient('http://127.0.0.1:5000');

const bookingTools = await client.loadToolset('booking-agent');
const searchHotels = await client.loadTool('search-hotels-by-location');

const result = await searchHotels({ location: 'Basel' });
console.log(result);

這點很實用，因為它代表同一個 Toolbox server 可以同時服務 MCP client 和你自己的 agent service。你可以先在 Claude Code 或 Gemini CLI 裡驗證工具，再把同一套東西接進正式系統，不用重做一遍。

它真正有價值的地方

如果只看新聞標題，這件事很容易被理解成「Google 也支援 MCP 了」。但我覺得真正值得看的，主要是下面三件事。

1. 它把 database access 從零碎實作拉成共用層

很多團隊做 agent，最後會在各自的 repo 裡長出一堆資料工具。有些包得很薄，有些直接把 SQL 暴露出去，有些權限和觀測幾乎沒有統一。

MCP Toolbox 的方向，則是把這件事往共享層拉。這代表工具可以被多個 agent 或 app 共用，也比較容易集中更新、集中治理，而不是每個專案各做各的。

2. 它的定位不只是一個 MCP adapter

目前文件提到的整合面，不只 MCP client，也包含 ADK、LangChain、LlamaIndex、自建應用，以及 Python、JavaScript、Go SDK。

這表示它想站的位置，不只是「幫 IDE 讀 mcp.json」，而是同時服務 MCP world 和 application SDK world 的資料工具層。

3. 它把安全、邊界和可觀測性提早放進設計裡

官方文件一直強調的，不只是「連得上資料庫」，還包括：

connection pooling
integrated auth
OpenTelemetry-based observability
restricted access
用 tool 與 toolset 控制暴露面

這些問題一旦走到真實資料場景，就不太可能只靠 prompt 解決。你最後一定還是要回到工具邊界、權限模型與可觀測性。

我認為比較合理的採用方式

如果今天真的要把它帶進團隊，我覺得最實際的路徑是三步。

第一步：先用 prebuilt tools 驗證需求

這個階段先不要急著談完整治理，而是先回答幾個問題：

agent 到底需不需要直接碰資料
最常見的查詢模式是什麼
哪些資訊不適合暴露給 generic tools

這時候 MCP Toolbox 比較像 discovery layer。

第二步：把高頻操作收斂成 custom tools

等你知道 agent 真的在做什麼，就不要讓它一直用泛用 query 能力。把高價值、高頻率的操作收斂成少數幾個 domain tools，才會有比較穩定的 contract、比較清楚的權限邊界，也比較容易審計。

第三步：再把 production concern 補完整

例如：

read-only 預設
write access 明確 opt-in
row limit 與 timeout
client-to-server auth
telemetry 與 trace
toolset 分群

這條 adoption path 比一開始就直接開一個 agent 去碰資料庫成熟很多。

它提醒我們的，其實是另一件事

很多 agent 討論都把重心放在 model、planning、memory、reasoning 或 multi-agent orchestration。

但一旦進到真實資料環境，瓶頸常常不是模型，而是更下面那層：

tool contract
permissions
data access
observability
operational boundary

MCP Toolbox 值得注意，不只是因為它掛著 Google 或 MCP，而是因為它把這些原本很零散、很容易被每個團隊重做一遍的東西，整理成一個比較一致的 product surface。

我覺得更準確的定位是：

它不是在跟 agent framework 競爭，而是在替 agent framework 補上一層可治理的資料接入能力。

結論

如果把 AI agent 看成「推理 + 工具 + 資料」的組合，那 MCP Toolbox 真正重要的地方，不是讓 agent 更會做事，而是讓資料接入這件事比較像工程，而不是 patchwork。

對團隊來說，這通常比「又多一個 agent framework」更有價值。

因為真正難 scale 的，往往不是 demo 裡那個 agent，而是 demo 成功之後，整個團隊要怎麼共享、限制、審計、更新那些 tools。

MCP Toolbox for Databases 給的一個很實際的答案是：

把資料庫能力收斂成標準化、可重用、可治理的工具層。