目錄
一套原本正常運作的 Notion AI MCP 流程，8 月底突然在第一個 Tool Call 就停下來。畫面顯示某個工具自上次管理員核准之後改變了 operation type，必須重新取得管理員核准才能繼續；更麻煩的是，不少碰到問題的工作區根本找不到錯誤訊息所說的重新核准入口，有人把 MCP 完整移除再重新連線，結果照樣失敗。
一開始看起來很像 Notion 上線了一套新的 MCP 權限治理機制，只是前端介面還沒跟上，但後續資訊證明不能這樣解讀。Notion 在 8 月 30 日正式承認部分 Notion AI MCP Tool Calls 發生失敗，工程團隊介入處理後，同一天晚間宣布恢復正常；整起事故持續約 6 小時 36 分。8 月 29 日的 r/Notion 討論裡也能看到相同現象，有人的 Connections 和 Tool List 都正常，真正執行時才出現 operation type 錯誤，甚至發生同一個 MCP 在 Agent 可以跑、Notion AI 卻失敗的情況。
所以這次事件本身比較接近平台端的 MCP 執行事故，不是使用者突然漏做了一次管理員核准。不過錯誤訊息也不是完全沒有參考價值，因為 Notion 現在確實正在把外部工具依讀取、寫入與執行風險做更細的控制。真正需要分清楚的是兩件事：這次錯誤為什麼發生，目前沒有公開的技術 RCA；Notion 正在增加 MCP 與 Agent 權限控制，則有正式產品文件可以確認。
本文資訊以 2026 年 8 月 31 日為準，Notion MCP、Custom Agents 與 Connections 管理介面仍可能隨版本更新。
Notion AI的「operation type已變更」錯誤到底發生了什麼？
8月29日開始出現大量相同回報，8月30日Notion正式承認MCP Tool Call異常
8 月 29 日，r/Notion 接連出現使用者回報，Notion AI 原本正常使用的 MCP Connections 突然全部無法執行，錯誤內容都是工具的 operation type 自上一次 Admin Approval 後發生改變，需要管理員重新核准。有一則案例直接點名 whoami，另一則則表示所有 MCP Tool 都出現相同問題，而且移除再重新加入 Connection 仍然沒有改善。
到了 8 月 30 日，Notion Status 正式刊出事故通知，表示部分 Notion AI MCP Tool Calls 正在失敗，工程團隊已確認問題並處理，最後在當天 22:49 宣布恢復。這個時間線很重要，因為它表示使用者看到的「請管理員重新核准」並不一定真的代表某個管理員漏做設定；至少這一波大量發生的案例，最終是由 Notion 端修復，而不是所有使用者各自找到一個 Approval Button 後解決。
因此，碰到相同訊息時第一個動作不應該是立刻重建整套自動化，而是先確認 Notion Status 與社群是否有同時間的大量回報。如果多個互不相關的 MCP Server 同時失敗，而且 Authentication、Tool Discovery 都正常，問題通常就不適合先歸因到單一 Connection。
operation type到底是什麼？不能直接等同於MCP的Read／Write欄位
MCP確實有工具行為標記，但Notion沒有公開這個錯誤對應哪一個欄位
MCP Tool Definition 除了工具名稱、描述與 Input Schema，也可以帶上 annotations，其中包含 readOnlyHint、destructiveHint、idempotentHint 與 openWorldHint。這些資訊可以告訴 MCP Client，某個 Tool 是否只讀、是否可能修改或破壞資料，以及是否會接觸外部世界。
但 MCP 規格本身特別提醒，這些 Annotation 是 Hint，不是安全保證，Client 也不能對不可信的 Server 無條件相信這些描述。更重要的是，Notion 目前沒有公開文件說明錯誤訊息裡的 operation type 就等於 readOnlyHint，也沒有文件指出 Tool Annotation、Input Schema 或其他 Tool Definition 發生哪些變動時一定會觸發重新核准。
所以原稿裡「伺服器從 Read 改成 Write，舊 Approval 就會失效」可以當成理解風險的例子，不能寫成這次事故已確認的技術原因。whoami 被擋也不能用來證明 Notion 只是在比對宣告是否變動，因為這次事故期間本來就出現大量 False Blocking，Notion 最後也是從平台端修復。
Notion確實已經把MCP工具分成Read與Write，而且Write預設更嚴格
Custom Agent的MCP Tools現在可以逐一控制
雖然這次事故不能拿來證明 operation type 的內部實作，但 Notion 現在的 Custom Agents 的確已經把 MCP Tool Risk 做成使用者看得到的設定。打開 Custom Agent 的 Settings → Tools & Access，展開一個 MCP Connection 後，可以看到 Server 提供的 Tools，也能逐一啟用或關閉。
Notion 把這些工具分成 Read Tools 和 Write Tools。Search、Fetch、List、View 這類主要取得資料的工具屬於 Read；Create、Update、Delete、Send、Post 等會改變外部資料的則屬於 Write。Read Tool 可以設定成自動執行，Write Tool 預設則需要使用者確認，避免 Agent 在沒有人工確認的情況下直接修改或刪除外部系統資料。
這才是目前有官方文件支持的「Operation Risk Control」。它的概念和錯誤訊息確實很接近：Tool 能不能改動資料，會影響系統是否需要 Human Confirmation；但不能再往前推成「8 月 29 日事故就是 Notion 發現所有 Tool Operation Type 變更，所以正確地把它們全部擋掉」。
Read Tool和Write Tool為什麼需要分開？
AI Agent和固定自動化最大的差別，是Tool Call可能由模型自己選
傳統 Automation 的流程通常事先寫死，例如收到 Form 後建立一筆 Database Record，再發一封 Email，每一步在部署以前都已經知道會做什麼。Agent 不太一樣，使用者給的是目標，模型可能依當下 Context 自己選擇 Search、Fetch、Create、Update 或 Send 等 Tools。
如果一個 Agent 只有 Search 與 Fetch，就算判斷錯誤，主要風險通常停留在讀錯資料、取錯 Context 或把不該使用的資訊帶進回答；一旦同一個 Agent 同時擁有 Update、Delete、Send、Post 之類的 Tool，錯誤就可能直接變成外部 Side Effect，例如修改正式 Database、寄出 Email 或刪除資料。
這也是 Notion 自己在 Prompt Injection 安全文件裡反覆要求採最小權限的原因。官方建議 Sensitive Workflow 盡量只提供真正需要的 Page、Database 與 Tool，外部 Tool 沒必要寫入時就維持 Read-only，非 Read-only Tool 則保留 Human Confirmation。AI 能做更多事情之後，安全控制自然也必須從「這個 Connection 能不能連」往下細到「這一個 Tool 能不能自動跑」。
Notion MCP的OAuth權限到底有多大？
Hosted Notion MCP基本上跟著登入者在該Workspace裡的權限走
Notion 對 Hosted MCP 的官方說法很直接：MCP Tools 會以登入使用者本來擁有的 Notion Permissions 運作，AI Tool 可以讀寫該使用者在已連接 Workspace 裡原本能存取的內容。這和傳統 Notion API Integration 常見的 Page-level Sharing 模式差很多，因為 Hosted MCP 是 User-based OAuth，主要目標就是讓 Claude、Cursor、ChatGPT 等 AI Client 以目前使用者身分操作 Notion。
因此，「連上 Hosted Notion MCP」本身就不適合被理解成只開一個小 Database 給 Agent。如果 OAuth 使用者能存取 Projects、Clients、Meeting Notes 與其他 Private Pages，接上 Notion MCP 的 AI Client 原則上也能在相同權限範圍內工作。
這也是為什麼真正需要狹窄資料邊界的 Workflow，不能只靠 Prompt 寫一句「不要看其他頁面」。如果需求是固定程式只處理幾張特定資料庫，傳統 Notion API Integration 反而可能更容易建立清楚的 Page／Database Access Boundary；如果使用 Hosted MCP，就要把登入身分本身的權限也列進風險評估。
Enterprise的MCP Governance管的是AI App與Client，不是這次錯誤裡的單一Tool Approval
Enterprise可以建立Approved AI Apps清單
Notion Enterprise 現在可以在 Settings → Connections 管理哪些外部 AI App 與 MCP Client 可以連上工作區。管理員可以把模式切成 Approved List，明確允許 Claude、Cursor、ChatGPT 或其他支援 MCP 的 Client，未被核准的工具即使曾經取得 Token，Notion 也會阻擋後續 Call。
管理員還能使用 Disconnect All Users 讓既有 Notion MCP Connections 全部失效，之後使用者必須重新 Authentication，而且只能透過目前核准的 AI App 重新連線。如果企業使用支援的 Identity Provider，例如 Okta，還能由管理員建立 Enterprise-managed Connection，減少成員各自完成 OAuth 的流程。
這些能力處理的是「哪一個 AI App 可以接進 Notion MCP」；Custom Agent 裡的 Tools & Access 則處理「某一個 Agent 能使用哪些 MCP Tools，以及執行時是否需要確認」。兩層都叫 Approval，很容易被混在一起，但它們不是同一件事。
目前官方公開文件裡沒有一個 Enterprise 頁面寫著「當 Tool Operation Type 改變時，到這裡重新 Approve 單一 Tool」。因此，8 月底那句叫管理員到 Module Settings 重新核准的錯誤訊息，不能直接拿現有 Enterprise Connections 文件來補上一個官方沒有寫過的操作流程。
Custom MCP Server又是另一套權限
Business與Enterprise可以讓Custom Agent接自訂MCP，但要先由Admin決定能不能裝
Notion Custom Agents 現在支援預先整合的 MCP Connections，也能連接自訂 Hosted MCP Server。若要使用 Custom MCP，Workspace Admin 必須先允許 Custom MCP Servers，之後還能決定成員可以自由安裝 Connection，或只能從 Approved Connections 清單選擇。
真正建立 Connection 時，每一個 Custom Agent 都有自己的 MCP Connection，而且使用的是當初執行 Authentication 那名使用者在外部服務上的 Credentials。Connection 不會自動在不同 Agent 之間共用，Agent A 已經登入 Figma，不代表 Agent B 自動取得同一條 Connection。
另外有一個很容易被忽略的權限效果：只要某名使用者對 Custom Agent 擁有足夠權限，就可能透過 Agent 使用已經接好的 MCP Tools，即使那個使用者本人沒有另外登入該外部服務。因此，MCP Connection 的 Authentication 身分、誰能使用 Agent，以及 Tool 本身能做什麼，三層都需要一起看。
8月底這次事故為什麼會讓人誤以為是治理機制更新？
錯誤訊息寫得太像一個真的可操作政策
使用者看到的是非常具體的一句話：Tool 的 operation type 改變了，需要 Admin 重新核准。問題在於畫面沒有對應的重新核准入口，而且重新 Authentication 也未必有效。這種錯誤訊息很容易讓人以為系統只是比過去更嚴格，實際上當時連真正沒有發生風險變更的 Tool Call 也可能被一起攔下。
後續時間線把這件事說得比較清楚。Notion 最後不是發布一篇「MCP Governance 更新說明」，而是在 Status 系統建立 Incident，標題直接寫著部分 Notion AI MCP Tool Calls 正在失敗，並由 Engineering Team 處理後恢復。因此，這次最合理的定性就是服務事故。
不過它也意外讓平常看不到的安全層浮出來：Notion AI 的 Tool Runtime 顯然不是「Server 說有 Tool，模型想叫就直接執行」。至少在 Client、Connection、Tool Risk 與 Confirmation 之間，還存在額外的 Policy Check，只是這次其中一層發生錯誤，把合法 Tool Call 一起擋掉。
Hosted Notion MCP正在取代舊的Local MCP Server嗎？
Remote版本是官方主力，舊Open-source Server已停止積極維護
Notion 最早推出的是可以自行下載與部署的 notion-mcp-server，本質上是把既有 Notion API Endpoint 轉成一組 MCP Tools。後來 Notion 改推出自己 Hosted 的 Remote MCP Server，使用 OAuth 連線，而且 Tool Interface 不再只是 API 的一對一包裝，而是另外做成適合 Agent 使用的 Search、Fetch、Create Pages、Update Page 等操作。
官方 GitHub Repository 現在已經明確標示，團隊只積極支援 Remote Notion MCP，舊的 Local Server 未來可能 Sunset，Repository 的 Issues 和 Pull Requests 也不再積極處理。官方 Developer Docs 同樣把 Local Server 列成 Last Resort，只有像 Headless Workflow 必須使用 Bearer Token、又無法完成 User OAuth 時，才可能還有使用理由。
Hosted Server 的另一個差別是更新由 Notion 控制。Notion 可以直接修改 Server 提供的 Tool、Descriptions 與底層實作，不需要每個使用者自行更新 npm Package；Notion-flavored Markdown 也讓 Agent 讀寫頁面時不用一直處理階層很深的 Block JSON，常見操作能用更少 Tool Calls 與 Tokens 完成。
但這個優點也代表 Tool Surface 由服務端持續演進。8 月底事故是否真的由某次 Hosted Tool Definition Change 引起，目前沒有官方 RCA，因此不能寫成已知原因；只能說 Hosted Model 確實讓 Tool 更新速度變快，而依賴這些 Tools 的工作流也更需要把服務狀態與 Schema Change 當成外部依賴管理。
Notion MCP突然報operation type錯誤時，可以怎麼排查？
第一步先看Notion Status，不要先拆掉整套Connection
如果 Tool List 還在、Authentication 也正常，但每一個 Tool Call 突然同時出現相同 Policy／Approval Error，先確認 Notion Status 是否有 Notion AI、MCP 或 Connections 事故。8 月 30 日這一波就是典型例子，當時重新連線並不能解決所有案例，最後需要 Notion 從平台端修復。
第二步確認是所有Tool失敗，還是只有特定Connection或特定Tool
如果只有一個 Custom MCP Server 失敗，其他 MCP 都正常，才比較像 Server Authentication、Tool Definition 或 Credential 問題；如果 Search、Fetch、Whoami 等不相關 Tool 一起失敗，甚至不同 Server 同時出現一樣訊息，就比較不像單一 Tool 真的突然改變行為。
第三步在服務正常後重新Authentication
Notion 官方 MCP Troubleshooting 本來就建議 Authentication 發生問題時，先 Disconnect／Clear Authentication，再重新完成 OAuth。這一步適合在 Status 已正常、問題仍只發生在單一 Connection 時做，而不是平台事故期間不停重建 Connection。
第四步是Custom Agent的話，直接檢查Tools & Access
Custom Agent 可以從 Settings → Tools & Access 查看 MCP Server 提供哪些 Tools、哪些目前 Enabled，以及每一個 Tool 是 Run Automatically、Always Ask 或 Always Allow。真正會寫入、刪除、發送資料的 Tool，不確定時先保留確認步驟，比為了讓流程完全無人值守直接全部設成 Always Allow 安全很多。
第五步把正式寫入流程留下可恢復點
需要更新正式資料庫、寄送對外訊息或執行刪除的 Workflow，不一定要全部禁止 Agent 寫入，但至少要留下能發現與恢復錯誤的設計，例如讓 Write Tool 保持 Human Confirmation、限制 Agent 只能處理指定 Database，或把大批量修改拆成先產生 Draft／Suggested Edits，再確認後套用。
8 月 28 日 Notion 才剛替 Agent 增加 Suggest Edits，讓 Agent 可以先提出逐行修改，再由人逐項接受。對需要品質控制的文件型 Workflow，這種設計通常比先讓 Agent 直接改完，再靠 Audit Log 找錯更容易控制。
自己開發MCP Server，Tool Definition要怎麼改才比較安全？
Breaking Change最好明確版本化，但不能保證永遠不觸發Client重新確認
MCP Tool Name 是 Client 用來辨認 Tool 的重要識別，如果既有 Tool 從單純查詢改成會修改外部資料，繼續沿用完全相同的名稱與描述，很容易讓既有 Prompt、Agent Policy 或 Approval Assumption 全部失真。因此，自訂 Server 在遇到明顯 Behavioral Breaking Change 時，可以考慮建立新的 Tool Name，或至少同步調整 Version、Description 與 Annotation，讓呼叫端有機會重新評估。
但這不能包裝成「只要換名字就不會再碰到 Notion 的 operation type Error」。Notion 並沒有公開那套內部 Approval Cache 的規則，所以 Tool Name、Schema 或 Annotation 哪一種改動會要求重新確認，目前沒有可以依賴的正式契約。
真正能確定的是 MCP 規格本身已經提供 readOnlyHint、destructiveHint、idempotentHint 與 openWorldHint 等行為描述，Server Author 應該正確填寫；Client 端則仍然需要把它們當成 Hint，不該只靠 Server 自我宣告建立真正的安全邊界。
Notion MCP和直接用Notion API有什麼差別？
MCP適合讓AI自己選工具，API適合固定、可預測的程式流程
Notion MCP 的核心優勢是 Agent-friendly。AI Client 可以先 Discover Tools，再依自然語言需求自行組合 Search、Fetch、Create Pages、Update Page 等操作；Remote MCP 還能使用 Notion-flavored Markdown 與 Notion AI Semantic Search，讓大量頁面操作比直接處理 Block JSON 更適合 LLM。
Notion API 則比較適合確定性的 Backend Workflow。程式直接呼叫明確 Endpoint，Authentication、輸入輸出與錯誤處理都由開發者控制，也能使用 MCP 目前還沒有的能力，例如 File Upload API。Remote Notion MCP 使用 User-based OAuth，而且目前不支援 Bearer Token，因此不一定適合沒有任何人在場的 Headless Automation；固定的 Server-to-server 工作流通常仍然需要評估 API Integration。
所以兩者不是誰取代誰。如果需求是「讓 AI 根據 Context 自己找資料、判斷接下來要做哪一個操作」，MCP 比較自然；如果需求是「每天早上八點固定把 A Database 的三個欄位同步到 B」，傳統 API 或 Worker 通常更容易測試，也比較不需要把 Agent Decision 放進流程。
這次事故真正需要改的，不是把所有Write Tool拿掉
8 月底的 operation type Error 最後證明是一場 Notion AI MCP 服務事故，不是個人工作區突然少按一個 Approval Button，也沒有證據顯示所有受影響的 MCP Server 都真的在同一天修改了 Tool 行為。這部分如果寫錯，後面整篇「Notion 正把 MCP 全部改成重新核准制」的推論都會跟著偏掉。
但錯誤訊息之所以會讓人信以為真，也和 Notion 現在的產品方向有關。Enterprise 已經有 AI App Allowlist，Custom Agents 可以逐 Tool 設定 Read／Write 與 Confirmation，Prompt Injection 文件又一直把 Least Privilege 與 Human Confirmation 放在主要防線裡。AI Agent 開始有能力真的改資料之後，Tool Permission 變細是已經發生的事，只是這次 Incident 不是那個趨勢的正式發布。
對依賴 Notion Automation 或 MCP 工作流的人來說，接下來更實際的準備不是記住這一串 Error Message，而是把 Workflow 分清楚：哪些只是 Read、哪些會 Write、哪些一定需要人在場、哪些完全不能因單一 MCP Service Failure 就停掉。這樣下一次碰到平台更新或服務事故時，至少知道該等供應商修復，還是真的需要回頭改自己的 Connection。
常見FAQs
不一定。2026 年 8 月 29～30 日大量出現這則訊息時，Notion 最後正式確認是部分 Notion AI MCP Tool Calls 發生故障，並從平台端修復，因此那一波案例不能用「管理員沒核准」解釋。若之後單一工作區再次看到相同訊息，仍應先確認 Status 與 Connection 狀況，再判斷是否真的存在設定變更。
不一定。Notion 官方一般 Troubleshooting 確實建議 Authentication 異常時 Disconnect 後重新 OAuth，但 8 月底事故期間已有使用者回報完整移除並重建 Connection 仍然失敗。平台 Incident 尚未修復時，反覆重新授權通常不會解決 Server-side Error。
目前官方文件沒有公開一套和這次錯誤訊息完全對應的「單一 Tool Operation Type Re-approval」流程。Enterprise 有 AI App／MCP Client Approved List，Custom Agent 也能控制每個 Tool 是否啟用與是否需要 Confirmation，但這兩者都不能直接當成錯誤訊息所說的 Module Re-approval 頁面。
在已連接的 Workspace 裡，Hosted Notion MCP 會依使用者本身的 Notion Access 運作，官方也直接提醒 MCP Tools 能存取使用者原本能存取的內容。因此它不是一個預設只開某幾張 Page 的低權限 Integration。需要更小資料邊界時，必須另外設計 Authentication 或使用更適合固定 Page Scope 的 Integration 架構。
Read Tool 主要取得資訊，例如 Search、Fetch、List、View；Write Tool 會對外部系統產生變更，例如 Create、Update、Delete、Send、Post。Notion 預設會要求 Write Tool 在執行前取得確認，而 Read Tool 比較適合在風險可接受時設成自動執行。
大多數一般使用情境現在應優先使用 Hosted Notion MCP。官方已經表示 Remote Server 是目前積極維護的版本，舊的 Open-source notion-mcp-server 不再積極維護，未來也可能退役。不過 Remote MCP 目前依賴 User OAuth、不支援 Bearer Token；完全無人值守的 Headless Workflow 如果需要 Token-based Authentication，仍可能要改走 Notion API 或自行管理其他整合方式。
需要讓 AI 根據自然語言自行搜尋、讀取與決定下一個 Tool Call 時，MCP 比較適合；固定排程、資料同步、精確權限或 File Upload 這類確定性流程，Notion API 通常比較容易控制。兩者可以同時存在，不需要把所有 Automation 都改成 Agent Workflow。