MCP 應用的雙層 iframe

概要

• UI 進入對話的方式MCP 應用的介面叫 view，是 tool call 結果的呈現層，本質上是一份含 JS 與 CSS 的 HTML。host 會建一個 iframe 顯示它，並把 tool result 注入進去。
• srcdoc 兩頭不討好用 srcdoc 灌內容，iframe 會與 host 同源、受同一份 CSP 管，腳本被擋；放寬 CSP 又會讓 app 讀到 host 的 local storage 與 cookie。
• sandbox 與 src 也走不通sandbox 之後是 null origin，用不了 local storage 與 cookie，補上 allow-same-origin 又回到原點。改用 src 指向各 app 的網址，則 host 得一直更新 frame-src，或自己代管所有第三方 UI。
• 雙層 iframe 的做法外層從獨立網域載入一支小腳本，由它取回資源，再開內層 iframe 用 srcdoc 放內容；外層還按 app 拆子網域，彼此讀不到對方的儲存資料。
• 開發者的功課把 app 依賴的網域都宣告在 MCP app 規格的 metadata 裡，否則內層的 CSP 不會放行。Fred 說 GPT app store 的送審退件，不少就是漏了這件事。

原話

• “deep diving into why the decision was made to do this kind of inception nesting of iFrames”

  深入看當初為什麼會決定做這種盜夢空間式的 iframe 巢狀結構

  ▶ 03:58

• “Doing so, you effectively need to put in motion an infrastructure where your domain hosts external third-party UI from all apps that will be submitted on your store, which is not a very good position to be into”

  這樣做等於得自己搭一套基礎設施，在自己的網域上代管所有送審 app 的第三方 UI，這不是個好處境

  ▶ 11:29

• “So you want app abc123 not to be able to access local storage from app abc456, for example.”

  所以你要讓 app abc123 讀不到 app abc456 的 local storage，舉例來說

  ▶ 12:56

• “This is the actual solution that I implemented into production.”

  這就是我實際上線的解法

  ▶ 13:28

• “we've seen a lot of rejection coming from the gpt app store submission because of missing csp and app not working in production because of missing csp domains”

  我們看到很多 GPT app store 送審被退，也有 app 在正式環境壞掉，原因都是漏了 CSP 網域

  ▶ 19:04

延伸

• MCP 應用的介面最早是用 MCP UI 做的，之後 OpenAI 在去年十月推出 apps SDK，再由 MCP 第一個官方 extension（app extension）統一成跨 client 的標準。
• 談 host 自己代管第三方 UI 的做法時，Fred 舉 OpenAI 實際用來放使用者內容的網域 openai-user-content.com 為例：要另外架一台伺服器，從 MCP server 下載 HTML 再用子網域分流到各個 app。