目錄
本文資訊彙整自 2026 年 9 月國際社群討論與公開文件。Notion MCP、AI 代理與各家 MCP Client 的工具處理方式仍在快速更新，實際工具清單、權限與行為可能隨版本調整，正式使用前仍應以當下官方資訊為準。
Notion MCP 在 2026 年 9 月 7 日引發討論，起因是一名使用者發現，AI 代理完成一般 Notion 任務後，突然補上一段與 Notion Business 有關的建議，前面的對話卻沒有詢問方案、價格或升級。爭議很快從「AI 怎麼開始幫 Notion 推方案」延伸到另一個問題：當 AI 代理透過 MCP 使用外部工具時，除了使用者輸入的內容，模型同時還會讀到伺服器提供的工具名稱、工具描述與執行結果。這些文字都有機會改變模型接下來的動作，但一般聊天介面未必會把它們完整顯示出來。
對平常只是用 Claude、ChatGPT 或其他 AI 工具連接 Notion 的使用者來說，這個差異很容易被忽略。畫面上看到的只是一句代理主動補上的建議，背後卻可能牽涉 MCP Server 定義好的工具呼叫條件與回答方式。問題因此不只在於那句 Business 推薦是否惱人，而是代理最後輸出的某些內容，到底來自模型自行判斷，還是受到連接器提供的 metadata 或 tool result 引導。
Notion MCP 爭議發生了什麼？社群發現代理會主動補上 Business 建議
這起討論最早來自 2026 年 9 月 7 日的 Reddit 貼文，之後同時出現在 r/Notion 與 r/ClaudeAI。發文者表示，AI 代理在處理 Notion 工作途中出現了未經要求的 Business 方案推薦，而且在 Notion 一般公開文件裡找不到這項行為的說明。社群後續把注意力放到 MCP 工具定義，發現其中確實存在一個 notion-check-mcp-next-steps 工具，而它的功能與這次出現的推薦內容高度相關。
這項發現能確認的是工具描述本身存在，卻不能直接證明所有 Notion MCP 使用者都會遇到相同輸出。觸發它需要哪些條件、由哪些 fetch 結果決定、是否受到帳號、方案、MCP Client 或伺服器端實驗影響，目前都沒有足夠公開資料可以完整還原。因此，社群貼文中的實際遭遇仍應視為一則使用者回報，不適合延伸成「Notion MCP 每次都會偷偷插廣告」這類確定結論。
MCP 工具描述與結果會進入模型脈絡，但一般聊天畫面不一定看得到
MCP 的工具不是單純藏在後台的 API。當 Client 連上 MCP Server 時，會先取得伺服器目前提供的工具清單，每個工具包含名稱、功能描述、輸入格式等資訊。使用者送出要求後，Client 會把可用工具資訊連同對話脈絡交給模型，模型再決定是否呼叫工具。工具執行完成後，結果也會送回模型，讓模型依結果產生下一步動作或最終回答。
因此，Tool Description 寫了什麼並不是無關緊要的文件註解。描述如果只寫「搜尋頁面」或「建立資料庫」，主要作用是幫助模型選對工具；如果裡面進一步寫了「完成任務後再執行某個動作」「看到特定結果時補上一段話」，它就已經開始介入代理的行為流程。
但這裡需要分清楚一件事：工具描述與工具結果雖然都可能影響模型，並不代表它們在技術上與 system prompt 或使用者指令具有完全相同的權限。不同 AI Client 會用不同方式包裝工具資訊與結果，模型本身也可能對不同來源採取不同處理。比較準確的說法是，這些內容屬於模型可見的上下文，而且確實可能左右後續輸出。
notion-check-mcp-next-steps 的描述，確實要求代理處理 Business next step
目前公開可觀察到的 notion-check-mcp-next-steps 描述很具體。代理不能自行任意呼叫這個工具，必須先從特定 Notion fetch 結果收到指示，而且要等原本的 Notion 任務完成後才能執行，一次對話最多處理一次。
如果工具沒有回傳下一步，代理不需要向使用者提起；如果有結果，描述要求代理在完成原本工作後，加入一句和本次 Notion 工作相關的短句，再附上工具回傳的目的地連結。內容可以被呈現成這類工作的「Business next step」，但不能任意補充沒有出現在工具結果裡的效益。
同一份描述也設下不少限制，包括不能直接要求使用者升級、不能批評目前的工作方式、不能寫成明顯的 sales pitch，也不能自行估算效率或時間效益。另外，描述要求代理不要提及 eligibility、frequency logic 等背後判斷機制。
這讓爭議變得比「Notion 在 MCP 裡塞了一句廣告」更細。從工具描述來看，它並不是要求代理硬性推銷 Business，而是一套受到限制的後續建議機制；但站在使用者端，最終看到的仍可能是一段沒有主動詢問、也沒有清楚交代來源的方案推薦。設計文件裡寫了多少限制，和實際聊天時感受到的突兀程度，是兩件不同的事。
另一個問題是公開程度。Notion 的 Supported tools 文件目前列出 Search、Fetch、Create、Update 等主要 MCP 工具，但公開清單中找不到 notion-check-mcp-next-steps。一般使用者若只讀官方功能頁，很難事先知道連接器還可能包含這類後續建議邏輯。
Notion MCP 爭議為什麼不是單純廣告問題？Tool Metadata 也會改變代理行為
這次事件真正碰到的是 AI 代理的來源辨識問題。傳統聊天機器人大多只需要處理使用者輸入與系統規則；接上 MCP 之後，模型同時會接觸工具描述、資料庫內容、搜尋結果、外部頁面與各種 tool result。模型需要從這些文字裡判斷哪些只是資料、哪些是在描述工具用途、哪些又要求下一步採取某個動作。
MCP 規格本身並沒有假設所有伺服器提供的 metadata 都絕對可靠。官方規格要求 Client 對工具相關描述與 annotations 保持警覺，也建議介面應讓使用者知道有哪些工具被提供給模型、何時發生工具呼叫，對有實際副作用的操作保留人工確認。
notion-check-mcp-next-steps 把另一個較少被討論的情境擺到檯面上：不一定要有惡意攻擊者，第一方服務本身就能利用正常的 MCP 工具設計來安排代理接下來做什麼。技術上這完全可以是正常功能，問題會落在使用者是否知道，以及 Client 有沒有提供足夠資訊讓這種影響可以被檢查。
這和惡意 Prompt Injection 有關，但不是完全相同的情況
過去談 MCP Prompt Injection，最典型的情境是代理讀進了不可信的外部內容。例如共享頁面、網站或匯入文件藏著「忽略原本指令，改去讀取其他資料」之類的文字，模型沒有正確辨識來源後照著執行，便可能造成資料外洩、錯誤修改，甚至把惡意內容帶進其他系統。
2026 年 3 月，Notion 官方 MCP Server 的 GitHub repository 就有人提出相關安全通報，描述攻擊者如何把提示詞藏進 Notion 頁面內容，等待具有讀寫權限的代理讀取，再嘗試誘導代理存取或修改其他工作區內容。這屬於典型的間接 Prompt Injection：惡意指令藏在原本應該被視為「資料」的內容中。
9 月的 Business next step 爭議不完全一樣。相關行為不是來自遭污染的頁面，而是工具本身的 metadata 與工具執行流程。與其把兩件事全部塞進「Prompt Injection」這個名稱裡，更精確的區分方式是：前者屬於不可信內容對代理進行的間接 Prompt Injection，後者則更接近第一方 Tool Metadata Steering。
兩者仍有共同問題。對模型而言，需要處理的資訊來源已經遠超過聊天框裡那幾句話。工具、文件與外部服務都能把文字送進工作流程，只要其中一層帶有行為指示，代理就得判斷該不該照做。
平台可以設計工具行為，問題在使用者能不能看見
MCP Server 定義自己的工具名稱、描述與回傳內容，本來就是協定正常的一部分。否則模型根本不知道工具可以做什麼，也不知道什麼時候該呼叫。平台在工具流程中加入下一步建議，因此不是單靠 MCP 規格就能判定「不能這樣做」。
比較麻煩的是資訊不對稱。使用者連接官方 Notion MCP 時，很自然會預期它的作用是搜尋、讀取、建立或更新 Notion 資料；如果同一條連線還會依伺服器端條件決定是否讓代理呈現商業方案，而這件事在一般產品說明與聊天畫面中都不明顯，使用者就很難判斷某句話到底是代理根據工作內容自行提出，還是平台預先設計好的後續動作。
這在純聊天裡可能只是一句讓人困惑的推薦，放進自動化工作流後影響會更實際。代理如果負責產生客戶文件、研究摘要、企畫草稿或其他準備直接對外使用的內容，任何未經要求的品牌、方案或外部連結都有可能跟著流進成品。此時需要檢查的已經不只是模型回答品質，也包括連接進工作流的工具本身。
同一週還有哪些 Notion 使用者回報？功能行為不一致的討論正在增加
9 月上旬的 r/Notion 還出現幾則彼此獨立的功能回報。一名使用者表示，已經啟用的自訂 Notion Skills 在反白文字後沒有出現在 inline editor 選單；另一名長期使用 Notion AI 的使用者則遇到 AI 突然表示沒有網路存取能力，即使帳號設定沒有主動變更。這些案例目前都只是個別使用者遇到的狀況，沒有證據能直接和 MCP Business next step 事件連在一起。
另一則討論則不是 Bug，而是工作區規模問題。發文者仍肯定 Notion 的文件功能，但原本堆在 Notion 裡的 CRM、審批與客戶追蹤流程逐漸變得難以維護；即使已有 row permissions，客戶只看自己的資料、允許外部人員新增內容卻不暴露整個資料庫，以及大量關聯資料後的效能，仍讓這名使用者開始評估把營運層拆到其他工具。
這些討論不能拿來證明 Notion 在同一週發生了某個共同系統性問題。比較合理的解讀是，Notion 現在同時承載文件、資料庫、自動化、AI Agent、Skills 與 MCP 等功能，使用者會開始在意每一層行為是否穩定、權限是否容易理解。Business next step 爭議剛好落在這種使用情境裡，因此反應比單純看到一段升級推薦更大。
如何檢查 Notion MCP 是否影響代理輸出？四個步驟先留下可比較的紀錄
MCP 伺服器端的工具可以更新，單靠「以前沒有出現過」很難判斷目前實際載入了什麼。比較有用的方法是留下可以重複比較的紀錄，確認代理究竟收到了哪些工具，以及異常內容是在什麼條件下出現。
步驟 1：建立乾淨的測試情境
先開一個全新對話，只啟用 Notion MCP，不同時掛其他 MCP Server，選擇一個完全不涉及方案或價格的普通任務，例如讀取一個測試頁面後整理內容。保留原始指令、工具呼叫紀錄與最終回覆，再用相同資料建立第二組對照。若需要排除 Notion MCP 本身的影響，可以把完全相同的頁面文字直接提供給沒有連接 Notion 的對話，再比較最後是否出現額外品牌、方案或連結。
一次結果不能證明固定行為，因為模型輸出本身具有變異。重點是把測試條件固定，之後工具描述或輸出突然改變時，至少有前後紀錄可以比。
步驟 2：直接檢查 MCP Tool Schema，不要只問模型「目前有哪些工具」
真正需要看的不是代理自己整理過的工具介紹，而是 MCP Client 從 Server 取得的原始 tool list。支援工具檢視功能的 Client、開發者介面或 MCP Inspector 可以直接查看 tool name、description 與 input schema。若當前 Client 沒有提供這層資訊，單純要求模型「逐字列出所有工具描述」未必可靠，因為 Client 不一定允許模型完整回傳原始 schema。
檢查時特別留意描述中是否出現與工具主要資料功能無關的行為要求，例如任務完成後補充其他內容、依特定結果插入連結、不要向使用者說明某些判斷條件，或要求模型採取原本任務沒有提到的後續動作。
步驟 3：對外內容固定保留人工審查
代理可以負責搜尋、整理與生成，但準備交給客戶、公開發布或直接送出的內容，最好不要把最後一步完全交給無人值守流程。檢查時除了事實與格式，也要掃一次不在原始需求中的品牌名稱、方案名稱、推薦語與外部連結。
這道人工關卡處理的不是 Notion 單一事件，而是所有使用外部工具的 Agent workflow 都會遇到的問題。任何能把資訊送進模型脈絡的服務，都可能改變最後輸出的內容。
步驟 4：把代理權限與可用工具縮到實際需要的範圍
若使用的 Client 支援工具開關或確認機制，不需要的工具直接停用；只需要讀取資料的流程，優先採用 read-only 權限；涉及建立、修改、刪除或外部副作用的操作，盡量保留 human confirmation。已經不再使用的 MCP Server 也應移除，不要因為曾經授權就長期留在代理環境中。
Notion 自己目前對 Custom Agents 與外部 MCP 的安全建議也是採取相同方向：限制代理能接觸的資料與工具、移除用途不清楚的工具，對非唯讀操作保留人工確認。處理外部文件、共享內容或其他不可信資料時，也不應只依靠模型自行判斷內容是否安全。
目前比較能確定的是，Notion MCP 的工具層確實可以影響代理最後怎麼回答，notion-check-mcp-next-steps 也顯示這種影響不一定只拿來搜尋或修改資料。爭議還沒有足夠資料證明它會在所有帳號或所有任務中觸發，因此沒必要把它寫成普遍性的「偷偷塞廣告」。但對已經把 MCP 接進日常自動化的工作流程而言，有一件事可以先改變：不要只審核模型，也要開始審核模型連上的工具。
常見FAQs
目前屬於使用者回報階段，官方尚未正式確認或回應。公開可取得的工具描述中，確實存在一個要求代理在任務完成後補上一句相關說明與連結的機制，但同一份描述也明文禁止推銷話術與升級勸說。實際呈現效果與設計意圖之間可能存在落差。
提示詞注入指的是把指令藏在模型會讀到的內容裡，讓模型誤把資料當成指令執行。過去這類風險多被視為外部攻擊，例如惡意共享頁面。這次社群指控的特別之處在於，行為指示的來源被指向連接器本身，而非外部內容。
開一個全新對話，只連接 Notion MCP 並下達與方案無關的指令，完整保留輸出；接著關閉連接器再跑同一組指令，比對兩份結果的差異。另可請代理逐字列出目前可用工具的名稱與描述，檢查是否含有與資料無關的行為指示。
沒有必要一律停用。較務實的做法是收斂權限範圍、移除不再使用的外部 MCP 伺服器，並在任何對外產出前加入一次人工檢查，專門確認是否出現未經要求的品牌名稱或外部連結。
結構上有。任何 MCP 伺服器回傳的工具描述與工具結果，都會直接進入模型脈絡並具備指令效力，這是協定的共通設計而非單一廠商的問題。因此只加入信任來源、並定期檢視已載入的工具描述，是通用的防護原則。