任何網站都能做成 MCP 嗎？第一性原理拆解：五條路徑、三道牆、該不該做
直接回答
技術上幾乎任何網站的公開內容都能透過某條路接進 MCP，但『可以』是一個光譜不是是非題。難度從十分鐘一鍵搞定，到要一直修的脆皮工程，到根本不該做，差 100 倍。決定你落在哪一段的不是 MCP 這個協定，是這個網站有沒有 API、要不要登入、有沒有反爬牆、還有你有沒有權限。MCP 只是轉接頭，不爬網頁不登入不繞防護，真正的功夫在怎麼把資料乾淨弄出來。
有人問我一個好問題：任何網站都可以做成 MCP 嗎？
這題值得用第一性原理拆，因為大部分人問的時候，心裡對 MCP 有一個錯的想像。我研究了現在的 MCP 工具生態，把它拆清楚。先聲明這是研究跟評估，不是我把每個工具都跑過一遍。
—
先拆到底層：MCP 到底是什麼
很多人以為「做成 MCP」是一種魔法，能讓 AI 用任何網站。拆開看，MCP（Model Context Protocol）只是一個標準規格，規定一個工具怎麼把它的功能跟資料，用 AI 讀得懂的格式吐出來。
關鍵在這裡：MCP 自己不爬網頁、不登入、不繞過任何防護。它只是一個插座規格。
所以「網站能不能做成 MCP」這題，真正在問的是另一件事：你能不能把這個網站的資料或功能，用程式化的方式弄出來？弄得出來，接上 MCP 是十分鐘的事；弄不出來，MCP 幫不了你。
MCP（Model Context Protocol）是一個標準規格，規定工具怎麼把功能跟資料用 AI 讀得懂的格式吐出來。它自己不爬網頁、不登入、不繞防護，只是一個轉接頭。網站能不能做成 MCP，真正在問的是能不能把資料程式化弄出來。
—
一句話答案
技術上，幾乎任何網站的公開內容都能透過某條路接進 MCP。但「可以」是一個光譜，不是是非題。
難度從十分鐘一鍵搞定，到要一直修的脆皮工程，到根本不該做。決定你落在哪一段的，是這個網站有沒有 API、要不要登入、有沒有反爬牆、還有你有沒有權限。
—
五條路徑：同樣做成 MCP，難度差 100 倍
給你一個網站，先看它落在哪一階。越上面越乾淨，越下面越脆越貴。
第一階，網站已經有官方 MCP。越來越多大站直接出官方 MCP server，Notion、Linear、GitHub、Slack、Stripe 都有。你不用做，接上去就用，十分鐘的事。
第二階，網站有 API。只要有 REST 或 OpenAPI 文件，現在有一堆工具把規格一鍵轉成 MCP server，路徑變工具名、參數變輸入。像 FastMCP、convertmcp.com、Gram、Speakeasy 這些。MCP 出來一年內幾乎每個 API 廠商都出了這種轉換器。品質看你 API 文件寫得多清楚。
第三階，沒 API 但內容公開靜態。只能抓網頁。公開的靜態頁面可以用 Firecrawl MCP 這類工具抓成 markdown 餵給 AI。可行，但網站改個版面你的抓法就壞。
第四階，要登入、要互動、JavaScript 很重。資料藏在登入後、或要點按操作、或整頁靠 JS 動態長出來，就得用 Playwright MCP 這類工具開一個真的瀏覽器去驅動它。這是最脆的一條，選擇器一改就崩，還要自己養跑瀏覽器的機器。
第五階，有反爬牆、captcha、服務條款禁止。Cloudflare Turnstile、Akamai 這種進階反爬，加上驗證碼、明文禁止爬取的條款。技術上有人硬繞，但這是該不該的問題，不是能不能。繞了可能違約、封 IP、甚至法律風險。
網站做成 MCP 有五條路徑，難度差 100 倍：已有官方 MCP（Notion、GitHub、Slack）十分鐘搞定、有 API 用 FastMCP 一鍵轉、公開靜態頁用 Firecrawl 爬成 markdown、要登入互動用 Playwright 驅動瀏覽器最脆、有反爬或條款禁止的不該做。
—
三道真牆：擋住你的不是 MCP
用「為什麼不」的角度問：到底有什麼真的擋著？拆開看，大部分不是技術做不到，是這三道牆。
第一道，法律與授權牆。服務條款禁止爬取、robots.txt 擋、資料在登入牆後面、涉及個資。這是最硬的一道，因為它不是能不能，是該不該。技術能繞不代表你可以繞。尤其商業用途，違約跟個資風險是真的。
第二道，技術反爬牆。Cloudflare Turnstile、Akamai、captcha、行為偵測。這些是網站主動花錢裝的防護，專門擋自動化。有些真的打不進去，或打進去成本高到不值得。
第三道，維護牆。這道最容易被低估。爬蟲跟瀏覽器驅動是脆的，網站改版你的抓法就壞。不是做完一次就好，是你簽了一份長期維護合約。真實成本不在建，在建完之後每次它壞你都要修。
—
更該問的問題：不是能不能，是該不該
第一性原理最狠的一刀：很多時候你根本不需要建 MCP。Claude 內建的 web_fetch 已經能讀一個網址了。
花力氣建專屬 MCP，只有這幾種情況才划算。只是偶爾讀一個網頁的內容，不用建，用 web_fetch 就好。要反覆、結構化地存取同一個服務，值得建，優先找它有沒有 API。需要登入、或要執行動作而不只是讀，建，但先確認有沒有官方 API 或官方 MCP，有就用官方的。網站明文禁止、或有硬反爬，不建，改找授權管道。
所以「任何網站都能做成 MCP 嗎」的誠實答案是：公開內容幾乎都接得進去，但你該問的不是能不能，是值不值、該不該、撐不撐得住。MCP 只是轉接頭，真正的功夫在把資料乾淨地弄出來這件事上。