MCP and Double Iframes

MCP (Model Context Protocol) is a universal standard that lets your AI agent talk directly to external tools like a CRM, Gmail, or a database. Think of it as a bridge — instead of connecting each tool with custom code, MCP provides one shared language. When you add an MCP server, it automatically loads its tool definitions (a manual of buttons and actions) into the AI’s context, so the agent knows exactly how to draft an email, fetch data, or send a message without you programming each step.

One common setup detail is the “double iframe” nesting. A double iframe means a web page is embedded inside another iframe, which itself sits inside the host application. This nesting creates a sandbox — a secure, isolated environment that prevents the MCP app’s scripts from interfering with the host. The inner iframe can call back to its server for fresh data and receive updated UIs, all without exposing the host to security risks. This is the default delivery mechanism for third-party generative UI (AI-generated interfaces) because it enforces a content security policy, blocking unauthorized scripts or embedded content.

Double iframes matter because they let AI apps serve interactive, live experiences — like data exploration dashboards — safely inside tools like VS Code or ChatGPT. Every MCP connection you add eats into your token budget (tokens are cost units for AI processing), so you want to keep your setup lean. Over 1,500 MCP servers exist today, and they work alongside WebMCP (a separate front-end protocol for connecting agents directly to web pages). Together, MCP handles backend tool integration, while double iframes keep the front end secure and responsive.

When you build an app for ChatGPT using MCP (Model Context Protocol, a way for AI to connect to external tools), the app’s interface appears inside two nested iframes (inline frames, which load another webpage inside the current page). This “double iframe” setup exists because of security. ChatGPT uses a Content Security Policy (CSP) (a set of rules that controls what resources can load on a page). That policy lists only specific domains that are allowed to render iframes. If your app’s UI lived in a single iframe, OpenAI would have to update that CSP list every time a new app appeared — an impossible task.

To solve this, ChatGPT places your app inside a second iframe that is hosted on its own domain. That first iframe acts as a bridge: it loads a generic endpoint from OpenAI’s servers, and then that page uses a meta tag to point to your app’s actual URL. Your app gets loaded inside the second iframe, isolated from the main ChatGPT page. This nesting prevents your app from accessing ChatGPT’s cookies or sending data back to your server without permission. The outer iframe is sandboxed (restricted so it cannot share the parent origin) for extra safety.

When you build an app, you must declare every external domain your app depends on — for example, an API endpoint — inside the app’s metadata under the `connect-src` directive. If you omit a domain, the CSP will block the connection. The result is a live, interactive UI within the chat: a user can move a diagram or update text, and the app can call back to the MCP server to fetch fresh data. The double iframe keeps everything secure while allowing real-time interaction.

When building MCP apps (applications that let AI agents show interactive interfaces inside a chat), you will encounter a "double iframe" pattern. This means one iframe (an embedded web page) is nested inside another iframe. ChatGPT uses this structure for security and flexibility. The outer iframe acts as a sandbox (a restricted environment that prevents the app from accessing the host page). The inner iframe loads your actual app content. This double nesting exists because ChatGPT cannot list every possible third-party domain in its Content Security Policy (CSP — a security rule that controls which domains can be loaded). Instead, the outer iframe loads content from a single trusted domain, and that frame then loads your app in the inner frame. A common pitfall is forgetting to declare external domains your app depends on. If your app calls an external API, you must list that domain in the `connect-src` directive of your app's metadata. Otherwise, the browser will block the request inside the nested iframe. Another mistake is assuming the inner iframe shares the parent origin (the security context of the main page). It does not — the sandbox attribute forces a "no pack origin," meaning your app cannot access ChatGPT's cookies or data. This is intentional for security. The best practice is to always declare all required domains in your MCP app spec metadata. Also, design your app to communicate with the host through the official message-passing API rather than trying to bypass the iframe boundaries. This keeps the experience smooth and secure.