你的服務 Agent Ready 了嗎？MCP 了解一下

看到 MCP 熱潮，很多團隊第一個反應是：「我們是不是也該做一個 MCP server?」

這個問題太早。

更好的問題是：如果一個 agent 今天代表你的客戶、員工或合作夥伴來到你的產品，它到底能不能完成一件有價值的工作？

不是看懂你的首頁。不是讀完你的 API docs。也不是在聊天框裡答幾句 FAQ。是它能不能找到正確資訊、知道有哪些能力可以用、在被授權後執行動作，並在出事時留下可追的紀錄。

這才是 MCP、llms.txt、A2A、remote tool endpoint 真正共同指向的事：產品正在多出一層新的商業介面。

過去你設計產品介面，大概分三種：

介面	主要使用者	典型產物
UI	人	網頁、app、dashboard
API	工程師	REST / GraphQL / SDK / docs
SEO / structured data	搜尋引擎與 crawler	sitemap、schema.org、robots.txt

現在多出第四層：agent entrypoint。

這層不是給人點的，也不只是給工程師接的。它是給 AI agent 發現、理解、呼叫、授權、交付結果的入口。

MCP 不是重點，入口才是重點

Anthropic 在 2024 年 11 月 open-source Model Context Protocol，把它定位成連接 AI assistant 與 data sources、business tools、development environments 的新標準。MCP 官方文件也把它說成 AI application 連接外部 systems 的 open-source standard。

這些說法都正確，但如果只停在「MCP 是 AI 工具的 USB-C」，很容易走錯方向。

因為企業真正要做的不是「把 API 全部包一層 MCP」。

真正要做的是判斷：

哪些產品能力值得被 agent 代理？

Shopify Storefront MCP 是一個好例子。它不是把 Shopify 所有功能都塞進 agent，而是把 product discovery、cart management、store information、order management 這幾類購物任務變成 AI assistant 可以處理的能力。

Stripe MCP 也是同一個訊號。它讓 agent 可以使用 Stripe API 與知識庫，但官方文件同時強調 restricted API keys、OAuth sessions、不要把 secret key 寫進 code。這不是「讓 agent 什麼都能做」，而是把付款、客戶、帳務這些高風險能力放進可授權、可限權的入口。

Cloudflare 的 remote MCP server 文件則把另一層補上：部署與授權。remote MCP server 可以走 Streamable HTTP，也可以加 authentication / authorization，控制 agent 能呼叫哪些 tools。

這三個例子放在一起，我看到的不是「MCP 很紅」。

我看到的是：agent 已經開始被當成一種新客戶端。

agent-readable 不是只讓 AI 讀，還要讓 AI 做

llms.txt 解的是 read layer。

它的提案很單純：在網站根目錄放一份 /llms.txt，用 Markdown 給 LLM 在 inference time 讀網站結構、重要背景與相關檔案。這不是取代 sitemap，也不是 robots.txt 的翻版。它更像是對 agent 說：「如果你要理解這個網站，請先讀這份導覽。」

但只做到這裡還不夠。

Agent-readable business infrastructure 至少有四層：

層級	問題	例子
Read	agent 能不能讀懂你的真實內容？	llms.txt、Markdown docs、清楚的 source / claim
Discover	agent 能不能知道你有哪些能力？	MCP tools list、A2A Agent Card、capability metadata
Act	agent 能不能安全地做事？	cart、checkout、create customer、query account、run job
Govern	agent 做事時能不能被授權、限權、撤銷、審計？	OAuth、restricted keys、approval UI、logs、policy layer

很多團隊現在只做到第一層，然後以為自己已經 agent-ready。

沒有。

如果 agent 只能讀你的內容，它只能幫使用者理解你。如果 agent 能發現你的能力，它可以開始把你放進工作流。如果 agent 能安全行動，它才可能替使用者完成交易、設定、查詢、交付。如果 agent 能被治理，企業才敢讓它碰真實系統。

這四層缺一層，都會卡在 demo。

A2A 補的是「誰可以被找到」

A2A 不該跟 MCP 混成同一件事。

MCP 比較像 agent 對工具與資料的接口。A2A 則處理 agent-to-agent interoperability:不同 agent 系統如何發現彼此、描述能力、交換任務。

在 A2A spec 裡，Agent Card 是很關鍵的概念：一份 metadata 文件，描述 agent 的 identity、capabilities、skills、service endpoint、authentication requirements。

這個概念值得放進商業判斷裡。

如果 MCP 問的是「agent 可以呼叫哪些工具」，A2A 的 Agent Card 問的是「這個 agent 或服務要怎麼被其他 agent 發現與理解」。

今天這還很早，不該寫成成熟市場。但方向很清楚：未來的企業 interface 可能不只是一組 API docs，而是一組可被 agent 發現的能力宣告。

你不是只把文件寫給工程師。你是在替自己的產品寫一張機器可讀的名片。

哪些公司現在就該做

不是每家公司都該立刻做 MCP server。

我會先看三個條件。

第一，你的產品是否有高頻、可結構化、可代理的工作。

電商查商品、加購物車、查訂單，很適合。付款、開 invoice、建立 customer，也有明確結構。文件查詢、雲端資源操作、內部資料查詢，也可能適合。

但如果你的產品價值主要來自高度情境化的顧問判斷，或每次服務都需要大量人類協商，那第一步可能不是 MCP，而是把知識、案例、限制條件整理成 agent-readable docs。

第二，你的風險邊界是否清楚。

MCP 規格自己就提醒：這類 protocol 會引入 arbitrary data access 與 code execution paths，所以 consent、data privacy、tool safety、sampling control 都是必要問題。

如果你還不知道哪些 action 需要人工確認、哪些只能 read-only、哪些要 sandbox，那做 agent 入口只是在放大事故面。

第三，你的入口是否真的能縮短使用者的工作流。

做 MCP server 不是為了展示技術立場。它應該讓使用者少開一個 dashboard、少貼一次 CSV、少查一次文件、少切換一個工具。

如果 agent 接上後只是把原本三步變成七步，那它不是入口，只是另一層摩擦。

一個簡單的 readiness check

我會用這張表判斷一家公司該不該現在做 agent 入口。

問題	還不用急	可以開始做
Read	文件散在 HTML、PDF、客服 FAQ	有清楚 Markdown docs、claim、policy、pricing、狀態頁
Discover	只有人類知道產品能做什麼	有 capability list、tool schema、Agent Card 或類似 metadata
Act	所有操作都要人開 dashboard	有少數高頻 action 可以被安全抽象成 tool
Govern	權限只有 admin / non-admin	有 scoped permissions、OAuth、restricted keys、approval、logs

這張表比「我們有沒有 MCP server」更重要。

因為 MCP 只解其中一段。它讓工具與資料可以用標準方式被 AI application 連接，但它不會替你決定產品能力邊界，也不會自動替你處理商業風險。

真正的 agent-readable infrastructure 是產品、工程、資安、文件與商業流程一起重做。

我的判斷

我不相信「每家公司都要做 MCP server」這種說法。

我相信另一件事：每個需要被 AI agent 理解或代理的公司，都要開始設計自己的 agent 入口。

對有些公司，第一步只是 /llms.txt、乾淨 Markdown docs、穩定 URL。對有些公司，第一步是把最常被客服問的流程做成 read-only tool。對少數公司，才是 remote MCP server、OAuth、restricted keys、approval flow、tool audit logs 全部一起上。

這不是一個 protocol migration project。

這是一個 product interface project。

所以先不要問「我要不要支援 MCP」。

先問：

如果一個 agent 今天代表你的客戶來到你的產品，它能不能讀懂、找到、執行，並在出事時被追責？

答不出來，你的產品就還不是 agent-ready。

林子睿（編輯：廖玄同），《你的服務 Agent Ready 了嗎？MCP 了解一下》，矽基前沿 [Si]gnals，2026-04-26。https://signals.tw/articles/mcp-and-agent-readable-business-infrastructure/