TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Supabase MCP 開放筆記本工具，AI 代理可局部重跑查詢
Supabase 於 11 月 5 日發布 MCP 伺服器 0.16.0，開放 create_notebook、run_notebook 與 delete_notebook 三個筆記本工具，run_notebook 可用 cells 參數只重跑修正過的儲存格，單次執行以 50 個查詢格與約 1MB 結果預算畫界。本文對回 GitHub 發布紀錄與官方文件，整理三種連線方式的差異、確認與唯讀規則，以及截至 11 月 7 日仍未確認的事項。
用 AI 摘要這篇文章：
讓 AI 代理幫你查一次 Supabase 資料很快，麻煩從第二輪開始：排錯往往連續好幾個查詢，修正其中一步之後，前面的結果不會自動留著，代理只能照著聊天紀錄把整串重拼一遍。查詢順序活在對話裡，換個人接手，同一個問題就要從零問起。
Supabase MCP 是把這些資料庫操作包成工具、讓 Cursor 或 Claude 這類 AI 用戶端直接呼叫的伺服器；能做多少，取決於連到的端點提供哪些工具、連線網址帶了哪些參數。這套規格這一年快速擴散，連 Google 都預覽了把 MCP 服務接進 Gemini 與搜尋；收錄各種 MCP 伺服器的目錄怎麼挑，我們在Awesome MCP Servers 的實測裡也聊過。Supabase 在 11 月 5 日發布的 MCP 伺服器 0.16.0，把筆記本相關工具對外打開：AI 代理可以建立筆記本、執行筆記本，刪除也有專屬工具，而且執行時能只挑修正過的那幾格重跑。隔一天的 0.16.1 再把這組工具放進預設功能群組，並在輸出補上筆記本網址欄位。
發布與生效是兩件事，這點值得放在最前面：套件 11 月 5 日就上了 npm，但這組工具目前只在代管連線（mcp.supabase.com）生效，自架與 Supabase CLI 的 MCP 端點沒有；就算走代管，也要伺服器端的筆記本功能旗標開了，工具才會出現。下面把兩個版本的原始變更、執行上限的實際語意，以及三種連線方式的差異整理清楚。
誰拿得到：代管連線限定，自架與 CLI 這版沒有
判斷自己拿不拿得到，先看連線方式。Supabase MCP 有三種入口：代管端點 mcp.supabase.com（MCP 用戶端設定好網址後登入 Supabase 帳號，選擇組織與專案）、Supabase CLI 的本機端點 http://localhost:54321/mcp，以及自架 Supabase 環境的 MCP 伺服器。官方文件在筆記本工具條目上寫得很直接：僅代管連線可用，本機或自架 Studio 的 MCP 伺服器（含 Supabase CLI）沒有這組工具；後兩種環境本來就只提供有限的工具子集，也沒有 OAuth 2.1 登入流程。
| 連線方式 | 筆記本工具 | 工具範圍 | 登入 |
|---|---|---|---|
| 代管端點 mcp.supabase.com | 有，伺服器端旗標開啟時 | 完整功能群組 | OAuth 2.1 登入 Supabase |
| Supabase CLI 本機端點 | 無 | 有限子集 | 無 OAuth 2.1 |
| 自架 Supabase MCP | 無 | 有限子集 | 無 OAuth 2.1 |
上表以 2026-11-07 的官方文件與 repo README 為準。連線網址上還有幾個會改變工具清單的參數：features 指定只載入某些功能群組，project_ref 把連線綁到單一專案並停用帳號層級工具，read_only=true 則以唯讀的 Postgres 使用者執行所有查詢、拿掉會改變資料的工具。文件頁提供互動式的網址產生器，在 Supabase 控制台的連線分頁也能直接產生自己專案的 MCP 網址。
套件版本是另一層。這個專案的發布節奏本來就不慢，前一版 0.15.0 是 10 月 29 日上的 npm，兩版相隔只有一週。0.16.0 把建立與執行工具從內部選項轉正時，筆記本還不算預設功能群組，連代管端都要在連線網址加上 features=notebooks 才會載入；隔天的 0.16.1 把 notebooks 加進預設功能群組，才算連上就有。但 0.16.1 的原始變更同時寫明：平台要提供筆記本轉接器，工具才會出現，而代管平台只在內部旗標 enableNotebooksV2Api 開啟時提供這個轉接器。換句話說，看到發布紀錄不等於自己連的端點已經有工具；最快的確認方式，是在自己的 MCP 用戶端重新連一次，看工具清單。
以前只能讀，現在能建、能跑、能刪
這裡的筆記本不是文章，而是把說明文字與查詢步驟放在同一份文件裡的工作本：每個儲存格是一段內容或一段操作，官方文件說 create_notebook 可以建立含 Markdown、資料庫與日誌三種儲存格的筆記本。追一筆訂單的付款狀態時，格子順序可能依序是查訂單表、查付款事件、再撈對應時段的日誌；保存成筆記本之後，代理沿同樣的順序重現結果，人也能看出每個數字經過哪些查詢。下一次條件變了，改其中一格再跑，不用把整份工作重講一次。
前後差異很明確。0.16.0 之前，notebooks 功能群組對外只有 list_notebooks 與 get_notebook 兩個讀取工具，能看見專案裡有哪些筆記本、讀到內容，但不能透過代理新增或改變任何東西；create_notebook 與 run_notebook 其實已經實作，但藏在內部的 unreleasedNotebookTools 伺服器選項後面，一般連線看不到。0.16.0 把這兩個工具正式註冊進功能群組、移除內部選項（PR #509，11 月 3 日合併），並補上 delete_notebook（PR #510，同日合併）。兩個 PR 在同一天內相隔一小時先後合併，11 月 5 日隨 0.16.0 一起發布，npm 上的發布時間是同日 13:52 UTC。
刪除值得單獨講，因為它帶著新的確認機制：delete_notebook 在刪除前會透過表單向使用者確認，與其他破壞性工具同一套；連線網址可以用 skip_elicitations=delete_notebook 跳過這項確認。反過來說，不支援表單確認的 MCP 用戶端，在確認開啟時會被直接拒絕，連呼叫都不成立。官方文件也把 run_notebook 列在可跳過確認的名單內，但這個參數只適用代管連線，而且在唯讀與本機連線的設定面板上根本不會出現。
0.16.1 那個看起來不起眼的修正也值得一提：建立、讀取與列出筆記本的輸出補上了 url 欄位，代理回報工作時可以直接給出可點開的筆記本網址，不用再自己拼。
五十個查詢格與約 1MB：單次執行的邊界
0.16.0 另一個重點是給 run_notebook 加上成本邊界（PR #511，11 月 5 日合併），規則可以拆成三條。
查詢格超過 50 個的筆記本，會在任何提示或查詢執行之前被拒絕，回給代理的訊息會要求拆分。50 是官方註明的起始值，而且網頁版 Studio 今天沒有格數上限，同一份筆記本在兩邊的待遇並不相同：在 Studio 能跑的長筆記本，交給代理時要先想想有沒有超過 50 個查詢格。
結果大小有約 1MB 的預算，而且這個預算現在會停損：花完之後，後面的查詢格不執行，狀態回 skipped；某一格的結果大到塞不進剩餘預算時，它會把剩餘預算全部花掉，連帶其後的格子一起跳過；其他錯誤不花預算。實際場景很好想像：一格忘了加 limit 的寬表查詢，可能把整份預算吃光，讓後面七八個輕量查詢全部變成 skipped。所以把結果量大的格子排在後面，是配合這套規則的排法。
日誌格也吃同一份預算，跟資料庫格一樣以剩餘額度作為單格上限，但實作有部署差異：代管端要等平台納入對應更新後才會遵守單格的 max_result_bytes 上限，本機伺服器則維持呼叫公開日誌 API、靠執行後的大小檢查。套件另外輸出了一個 ResultTooLargeError：自行架設端點的人，只要在讀到上限時丟出這個錯誤，run_notebook 會把它當成自己的大小檢查來對待。同一個版本號，代管與本機的行為可能不同，排查問題時先分清楚自己連的是哪一種。
容易誤讀的地方順帶釐清：50 格與約 1MB 限制的是單次呼叫能做多少、在哪裡停損，與帳號層級的額度或帳單上限無關。把一份長工作拆成多次執行，資料庫原本的用量與計費照舊。
讀取免提示、寫入要確認，還有一個已知的縫
查詢格的確認規則在這版定得更細。全部語句都是純讀取的格子，包括 select、values、table、show、explain，或不含 insert/update/delete/merge 的 with，免確認即可執行，而且以唯讀模式跑；其他格子，包括 call、do、交易控制與 set，一律走確認流程，接受之後以伺服器的正常模式執行。這是語句層級的自動分流，跟連線層級的 read_only=true 是兩件事：後者從網址就決定整條連線以唯讀使用者執行、拿掉所有會改資料的工具，前者是同一份筆記本裡逐格判斷。
縫在函式呼叫：一句 select 如果呼叫了會寫入的函式，仍然免提示執行，只會在資料庫端成功或失敗。官方在變更說明裡明寫這一點；把 select 當成一定無副作用的人，這條規則值得記住。同一版也把純查詢計畫的 explain 從破壞性確認名單拿掉，確認的負擔往真正會改變資料的操作集中。
cells 參數：只重跑修正過的儲存格
run_notebook 新增的 cells 參數，是這次更新裡對日常工作最直接的改變（PR #514，11 月 5 日合併）。傳入儲存格 id 清單就只跑那些格，不傳則照舊整本執行；修好一格之後不必把整本重來，這是筆記本從「保存查詢」變成「可接續工作」的關鍵一步。
選取的格子照筆記本順序執行，不做依賴解析，需要的前置格（例如建立暫存表的 setup 格）要自己放進選取；重複的 id 會自動去重。未知或非查詢格的 id 不會中斷整次執行，只會以 cell_id、status: skipped 加原因逐項回報，代理能從中看出是打錯 id 還是用了已經改過內容的過期 id，下一輪修正選取再跑。
格數上限、結果預算、確認提示與 notebook_run 計數，都只算選取的格子，被跳過的 id 不佔任何一項。批准也綁定該次選取：同意跑某幾格，不等於同意跑另一組格子，換了選取就要重新批准，所以「改一格、加一格」的操作每次都會回到確認流程。選取超過 50 個查詢格一樣被拒，訊息會提示改用下一批 50 個以內的 id 再呼叫一次；空清單，或選了半天沒有半個查詢格，會在執行前直接回工具呼叫錯誤。
現在要不要動
用 Cursor、Claude 這類用戶端連 mcp.supabase.com 的人，不用改設定：0.16.1 起筆記本屬於預設功能群組，重連後看工具清單有沒有出現 create_notebook，是最快的驗證；官方文件對 run_notebook 的一句話描述是「執行最多 50 個查詢格，或只跑選定的格子」，工具清單裡看到這句，代表連到的端點已經是新版。沒有出現，多半是所屬專案的伺服器端旗標還沒開，等官方推送即可，不需要在用戶端側折騰。用戶端這側怎麼程式化地接 MCP 伺服器，我們先前也實測過開源庫 mcp-use 的做法。用戶端不支援表單確認的人，要特別注意 delete_notebook 的行為，再決定要不要用 skip_elicitations。
自架與 CLI 使用者這版沒有筆記本工具，也沒有需要補的設定；想用這套流程，目前只有代管連線一條路。自己用套件架端點的人，倒是值得看一眼 ResultTooLargeError 那條路，讓大小檢查的行為與官方一致。
已經用 MCP 查詢 Supabase 的人，值得調整的習慣有兩個：把長查詢流程拆成查詢格 50 個以內的筆記本，避免整份被拒；局部重跑時把 setup 格固定放進選取，並把結果量大的格子排在後面，讓預算停損不會連累還沒跑的格子。
還沒確定的事，與這篇文章的保存期限
從發布紀錄與官方文件能確認的到這裡為止，剩下幾件事截至 11 月 7 日沒有公開答案：enableNotebooksV2Api 對個別專案的開啟時程、約 1MB 預算的精確位元組數（PR 原文就是約略值）、50 格上限未來會不會調整，以及整次執行的時間上限，官方把它列為後續工作；目前用戶端取消請求時，後續格子不會再跑，但已在執行中的那格會跑完。
0.16.0 的發布紀錄裡還有一個與筆記本直接相關的修正：因用戶端造成的拒絕（例如筆記本的更新時間對不上，或不支援表單確認的用戶端要求刪除）改回報為呼叫方錯誤，代理不會再把問題誤判成伺服器故障。這個專案最近的節奏很快，11 月 5 日與 6 日連發兩版，工具預設值與上限都還在移動。這篇文章的時效基準是 2026-11-07 的 0.16.1 與官方文件；下一次 minor 版本或官方工具清單變動時，上限數字與預設行為都需要重新核對。
