Supabase MCP 讓 AI 直連專案
Supabase MCP 讓 AI 透過標準協定連到專案、資料庫、日誌與 Edge Functions，還能用 read-only 與專案範圍控管權限。
說真的，這功能很實用。Supabase MCP 讓 AI 工具直接查你的專案。官方文件提到，主機端點是 https://mcp.supabase.com/mcp，而且可以把權限鎖在單一專案。
這件事不只是方便。它還把風險攤開來看。AI 可以查表、跑 SQL、看日誌、產生 TypeScript types，甚至部署 Edge Functions。講白了，就是把 AI 拉進資料庫工作流裡。
你可能會想問，這跟一般聊天有什麼差。差很多。一般聊天是你貼一段 schema，AI 猜半天。MCP 是讓 AI 直接用工具查真實資料。準度高很多，失誤也更容易爆。
Supabase MCP 到底接了什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
MCP 是 Model Context Protocol。它是一套讓 LLM 連外部工具的標準。像 Cursor 這類 MCP client，可以登入你的 Supabase 帳號，再用自然語言呼叫工具。
Supabase 把功能切得很細。資料庫工具預設開啟。Storage 預設關閉。若用 project-scoped 模式，還能直接拿掉帳號層級工具。這個預設很有意思，代表官方知道權限不能亂開。
文件列出的能力不少。它不是玩具 connector。它比較像 AI 的控制台。你可以拿它做日常開發，也可以拿它做除錯，只是前提是你知道自己在開什麼門。
- 資料庫：列出 tables、extensions、migrations，還能執行 SQL
- 除錯：讀 service logs，拿 advisor 建議
- 開發：抓 project URL、publishable keys、產生 types
- Edge Functions：列出、檢查、部署 functions
- 文件與分支：搜尋 docs、建立 branch、merge、reset、rebase
另外，Supabase CLI 也有本機 MCP。端點是 http://localhost:54321/mcp。這對團隊很實際。你可以先在本機測流程，再決定要不要碰 hosted 專案。
設定很簡單，預設才是重點
安裝流程很直白。選平台、選專案、選 client、連線。對 Cursor 來說，文件甚至有一鍵安裝，也有手動 JSON 設定。
真正值得看的是登入流程。Supabase 說 hosted server 用了 dynamic client registration。很多情況下，你不用自己先做 personal access token，也不用手動建 OAuth app。瀏覽器會跳出來，你登入後授權就好。
這比以前那種 token 塞滿設定檔的流程乾淨很多。但手動模式還是保留著。像 CI 系統，文件就提供 bearer token 流程。像某些只吃 OAuth 的 client，也能走組織內的 OAuth app。
- Hosted server：
https://mcp.supabase.com/mcp - Local CLI：
http://localhost:54321/mcp - Read-only：
read_only=true - 專案範圍：
project_ref=abc123 - 功能篩選：
features=database,docs
這裡有個細節很重要。你如果不選專案，帳號底下所有專案都可能打得到。對開發測試來說很方便。對正式環境來說，這種預設就該先皺眉。
我覺得這也是 Supabase 文件寫得好的地方。它沒有假裝安全是自動發生的。它直接把權限選項攤給你看，逼你自己做決定。
安全才是這套系統的核心
Supabase 花很多篇幅講安全，這很合理。最大風險是 prompt injection。也就是資料裡藏了惡意指令，LLM 讀到後跟著做。像 ticket、log、甚至資料表欄位，都可能塞進奇怪文本。
文件舉了一個很實際的例子。某個 ticket 裡寫著要模型忽略前文，然後去跑 SQL。你如果叫 Cursor 透過 MCP 去看那張 ticket，模型可能就被帶偏。這種事不是科幻。這是現在就會發生的坑。
Supabase 也提醒，像 Cursor 這種 client 通常會在每次 tool call 前跳出人工確認。這個設定最好別關。真的，別手滑把確認拿掉。那不是效率問題，那是事故問題。
“Prompt injection is the primary attack vector unique to LLMs.”
這句是 Supabase 文件裡的原話。很直白，也很刺耳。它提醒你，LLM 不是只會算錯。它還會被內容騙。
文件也有一些實用建議。這些建議很土，但很對。你如果想認真用 MCP，就得照做。
- 先用 development project，不要直接碰 production
- 測試資料最好是非正式或已去識別化資料
- 不要把 server 直接給客戶或終端使用者
- 需要碰真資料時，先開 read-only mode
- 盡量把權限鎖在單一專案
- 功能群組只開必要項目
這類安全建議看起來很保守，但我反而覺得這才像工程。AI 工具越強，權限就越該縮小。這不是唱衰，是基本功。
跟其他 AI 開發工具比，差在哪
Supabase MCP 的定位很清楚。它不是通用聊天機器人。它是讓 AI 直接碰 Supabase 工具的入口。這代表它能拿到更準的資料，也代表它能做更具體的事。
跟一般 chat workflow 比，MCP 的優勢是上下文真實。它可以問 tables、查 migrations、看 logs、產 types。你不用一直複製貼上。AI 也不用靠猜。
跟那種 shell 權限很大的 agent 比，Supabase 的作法又保守很多。它可以 project-scoped，可以 read-only，也能只開某些 feature group。這些限制不是麻煩，是保險絲。
- Supabase MCP：直接接 Supabase 專用工具，像 migrations、logs、Edge Functions
- 一般聊天助手：多半靠你手動貼資料
- 廣權限 agent：彈性高，但風險也高
- 本機 CLI MCP：先在
localhost:54321測流程，再碰線上環境
Supabase 的社群 repo 也開著。你可以看 supabase-community/supabase-mcp。如果你想知道實作細節，這比只看文件更有料。
再拿同類工具比一下。像 Postman 偏向 API 測試。Prisma 偏向 schema 和 migration。Supabase MCP 則是把 AI 拉進操作層。它不是替代這些工具，而是把它們的部分工作接到 LLM 上。
對團隊來說，最有用的是哪裡
我覺得最實際的場景，是把 AI 當 junior pair programmer。請它列 tables、看 migrations、整理 logs、產 types。這些工作很碎。AI 做起來剛好。
但如果你要它在 live environment 大改資料，那就是另一回事了。那不是助手。那是賭運氣。Supabase 自己也很明白，權限如果沒收好，問題會很快出現。
對團隊來說，最好的玩法是先從 branch 和非正式資料開始。Supabase 本來就有 branching。再加上 read-only 與 feature filter，AI 工作流就能先在小範圍內跑。
這裡也可以看一下產業脈絡。過去兩年，開發工具都在往「工具可呼叫」走。從 IDE 外掛、到 agent、到 MCP，方向都一樣。差別只在於誰把權限收得比較好。
我自己的判斷很簡單。凡是能讀真資料的 AI，都該先被當成半自動工具，而不是全自動代理。這句話聽起來很保守，但很符合現場。
這波變化代表什麼
Supabase MCP 代表一件事。AI 開始不只會回答問題。它開始能進到資料庫工作流裡。對工程師來說，這會省掉很多重複操作。
但它也提醒我們，工具越方便，權限就越要收緊。最好的使用方式，不是把它丟進 production。是先拿 dev 專案測，先開 manual approval，再慢慢加範圍。
如果你團隊本來就用 Supabase，這套東西值得試。先挑一個非正式專案，讓 AI 只看資料庫和 docs。等你確認流程穩，再考慮 logs 或 Edge Functions。這樣比較像工程，不像賭博。
我的預測很直接。接下來 12 個月，會有更多開發工具把 MCP 當標配。問題不是要不要接，而是你要把權限切多細。這題你現在就可以開始想。