Developer’s guide to implementing MCP apps in Gemini
Google introduces MCP Apps in Gemini Enterprise to enable interactive, visual workflows within chat, reducing latency and improving real-time collaboration for complex tasks.
MCP Apps (SEP-1865) introduces an open Model Context Protocol extension that pairs tools with live user interfaces, rendering directly in Gemini Enterprise’s chat flow. The interface operates within a sandboxed iframe, allowing fullscreen or side-panel views while keeping edits local and synchronized with the workspace. This approach avoids rebuilding foundational elements, as Gemini Enterprise handles workforce sign-in, governed data access, and the Default Assistant, while developers host the MCP server on a private Cloud Run service.
The update introduces three generations of tooling: text chatbots return static markdown, standard MCP tools invoke live APIs but output static text requiring additional model turns for changes, and interactive MCP Apps pair tools with live workspaces. Adjustments in the widget occur without model turns, with the assistant remaining synchronized. Single-click actions execute directly in the panel without round-tripping through the chat, enabling responsive user experiences tailored to specific workflows.
Enterprise security is enforced through workforce OAuth sign-in, private Cloud Run ingress, and a sandboxed iframe, protecting every layer of interaction. High-stakes actions require human-in-the-loop governance, where experts inspect and approve before execution. The open standard ensures portability across compatible hosts, with automatic text fallback for compatibility, and broad connectivity to systems like BigQuery, Agent Platform, Cloud Storage, or internal ERP and CRM systems.
Developers deploy and host the MCP server on Cloud Run, exposing a single JSON-RPC endpoint (/mcp) and serving a bundled HTML widget. Each tier communicates only with its neighbor, allowing Gemini Enterprise to enforce security and routing. Users sign in via OAuth 2.0, with Gemini Enterprise sending its service agent token alongside the user’s token for layered verification. Layer 1 enforces service-level access at Google’s edge, while Layer 2 enforces user-level access within the application, both required for security.