Websites are built for human eyes. We scan a page, spot the form field, and click the button that finishes the job. AI agents navigating the same site don't perceive it that way — and a new proposal called WebMCP wants to give them a proper interface. For web teams in Hong Kong planning next year's roadmap, the practical starting point isn't adopting anything yet. It's an audit: how much of your traffic, and how much of your revenue risk, is already arriving via agents rather than people?

That question frames an essay originally published on the Agentic AI Foundation blog and reposted by O'Reilly Radar, which argues that the web's next interface isn't a browser at all. It's software acting on a user's behalf — booking, comparing, purchasing, filing.

What WebMCP actually is

WebMCP is a proposal, not an adopted standard. It is attributed to the Agentic AI Foundation, an industry body that the Foundation describes as Linux Foundation-backed and formed in late 2025, with a founding roster reported to include OpenAI, Anthropic, Microsoft, Mozilla, Cloudflare, and Shopify. Mozilla, per the Foundation's materials, has signalled an intent to ship WebMCP support in Firefox. Those details rest on the Foundation's own announcement as relayed through the O'Reilly repost (source) and should be treated as claims by an interested party until broader ratification follows.

The technical lineage matters. WebMCP builds on the Model Context Protocol (MCP), Anthropic's now-widely-integrated mechanism for connecting AI applications to external tools and data. Where MCP connects agents to backend tools, WebMCP proposes exposing a site's actions and state directly to agents visiting the front end — so an agent doesn't have to reverse-engineer a page the way a human reads it.

The convergence argument

The essay's strongest point is also the most reassuring one for busy teams: designing for agents and designing for humans mostly converge. A site with honest information architecture — clear labels, explicit states, well-documented actions — is already the site easiest to wrap in WebMCP tooling. The same habits that serve screen-reader users and third-party integrators serve agents. Teams that have done accessibility work are, without knowing it, closer to agent-readiness than teams that haven't.

Where it gets uncomfortable

Two open problems will decide whether WebMCP matters. The first is incentive: there is currently no traffic or revenue reason compelling a site to implement it. Adoption of any interface standard follows demand, and demand is thin. The second is security. Allowing third-party agents to invoke actions on a user's behalf creates a substantial new attack surface spanning authentication, authorization, rate limiting, and consent. Neither problem is fatal to the proposal; neither is solved by its current design.

The open-source angle

One part of the Foundation's case deserves separate attention. The specification process is described as public, conducted under Linux Foundation backing — the arrangement that produced successful standards in the past. Firefox, if Mozilla follows through on its stated intent, is the likely first proving ground, and its market position would give web teams a concrete compatibility target long before any other browser moves.

Just as importantly, the tooling layer is expected to emerge from open source before commercial vendors build it. Agent-friendliness crawlers, action-exposure libraries, and audit utilities of the kind this article recommends are the kind of infrastructure projects open-source ecosystems produce early and cheaply. Hong Kong teams watching this space should be monitoring those projects, not vendor roadmaps, for the first usable measurement tools.

Vertical guidance: proceed, wait, or defer

  • E-commerce: Proceed with the audit and experimental implementation. Catalogues, availability states, and checkout actions are the natural fit, and agent-facing competitive pressure is arriving faster than the standard is maturing.
  • Banking and financial services: Hold. Consent and authorization questions are acute where transactions and regulated data are involved. Audit your agent traffic exposure; don't expose actions.
  • Government and public services: Defer. Procurement cycles, accessibility mandates, and the obligation to human users first make early adoption impractical.

Build or wait?

The recommendation is a split decision: don't build on WebMCP yet — it isn't a standard — but do build the properties that make WebMCP trivial to add later. Clean information architecture, machine-readable state, and explicit, documented actions are investments that pay off in accessibility, integration, and search visibility regardless of whether the proposal is ratified. The agents are already arriving; the interface they'll expect is still being written.


網站是為人眼而設計的。我們掃視頁面、找到表單欄位、按一下完成按鈕。但 AI agent 導覽同一個網站時,感知方式完全不同——一個名為 WebMCP 的新提案,正想為 agent 提供一個正式介面。對於正在規劃明年路線圖的香港網頁團隊來說,實際起點不是立即採用任何東西,而是先做一項審計:你的流量中,以及你的收入風險中,有多大比例已經來自 agent 而非真人?

這個問題貫穿一篇最初發表於 Agentic AI Foundation blog、並由 O'Reilly Radar 轉載的文章。文章主張網絡的下一個介面根本不是瀏覽器,而是代表用戶行動的軟件——預訂、比較、購買、遞交申請。

WebMCP 到底是什麼

WebMCP 是一項提案,不是已獲採納的標準。它由 Agentic AI Foundation 提出,該組織自稱獲 Linux Foundation 支持、於 2025 年底成立,創始成員據報包括 OpenAI、Anthropic、Microsoft、Mozilla、Cloudflare 和 Shopify。根據基金會自身資料,Mozilla 已明確表態有意在 Firefox 中加入 WebMCP 支援。以上資訊均源自基金會自身的公告,經 O'Reilly 轉載(原文),在更廣泛的標準批准落實前,應視為利益相關方的說法。

技術淵源同樣重要。WebMCP 建基於 Model Context Protocol(MCP)之上——Anthropic 開發、目前已廣泛整合的機制,用來將 AI 應用連接到外部工具和數據。MCP 將 agent 連接到後端工具,WebMCP 則進一步提議把網站的動作和狀態直接暴露給到訪前端的 agent,使 agent 不必像人類閱讀頁面那樣反向工程整個頁面。

「為人設計」與「為 agent 設計」的交匯

文章最有說服力、也最令忙碌團隊安心的一點:為 agent 設計和為人類設計,大方向是一致的。一個資訊架構清晰的網站——標籤明確、狀態顯性、動作有文件說明——本來就最容易套上 WebMCP 工具。同樣的功夫既能服務螢幕閱讀器用戶和第三方整合商,也能服務 agent。做過無障礙設計的團隊,其實已經在不知不覺中比其他團隊更接近 agent-ready。

棘手的兩個問題

兩個未解的難題將決定 WebMCP 能否真正落地。第一是誘因:目前網站並沒有流量或收入上的理由去實作它。任何介面標準的採用都跟隨需求,而需求尚且薄弱。第二是安全。允許第三方 agent 以用戶名義觸發動作,會帶來一大片全新的攻擊面,涵蓋認證、授權、流量限制和用戶同意等範疇。這兩個問題都不足以否定提案,但提案本身的設計也尚未解決它們。

開源角度值得留意

基金會的一項主張值得單獨注意:規格制定過程公開進行,由 Linux Foundation 支持——正是過往孕育成功標準的安排。若 Mozilla 落實其明確表態,Firefox 將是首個測試平台,其市場地位會為網頁團隊提供一個具體的相容性目標,遠早於其他瀏覽器有所動作。

同樣重要的是,工具層(agent-friendliness crawler、動作暴露函式庫、審計工具等)預計會先從開源專案中出現,而非由商業供應商建造。密切留意此領域的香港團隊,應監控這些開源專案而非供應商路線圖,以取得第一批可用的測量工具。

各行各業的建議:推進、觀望、還是擱置

  • 電子商務: 推進審計及實驗性實作。商品目錄、庫存狀態和結帳動作最適合 agent 介面,而面向 agent 的競爭壓力正比標準成熟速度更快到來。
  • 銀行及金融服務: 觀望。涉及交易和受監管數據時,用戶同意和授權的問題尤為尖銳。應審計 agent 流量帶來的暴露風險,但不要暴露動作。
  • 政府及公共服務: 擱置。採購流程、無障礙設計法定要求,以及對人類用戶的首要責任,使過早採用並不實際。

建還是等?

建議是拆開處理:暫時不要建基於 WebMCP 之上——它還不是標準——但要建好那些令日後加入 WebMCP 變得輕而易舉的特質。清晰的資訊架構、機器可讀的狀態、有明確文件的動作,這些投資無論提案最終是否獲批准,都會在無障礙設計、系統整合和搜尋能見度上回報。Agent 已經在路上;它們期待的介面,仍在編寫當中。

新聞來源 / Original News Source