Enterprise assistants are still mostly text-only, which becomes a bottleneck for visual, multi-step work because every adjustment costs another slow chat turn. MCP Apps (SEP-1865) is an open Model Context Protocol extension that pairs a tool with a live UI. In Gemini Enterprise, that UI renders directly in the chat flow inside a sandboxed iframe and can expand to fullscreen or a side panel. Edits run locally while the workspace and assistant stay synchronized, and you do not have to rebuild identity or access foundations: Gemini Enterprise supplies workforce sign-in, governed data access, and the Default Assistant, while you host your MCP server on a private Cloud Run service.

The article frames MCP Apps as the third generation of enterprise assistant capabilities. Generation 1 is text chatbots that return static markdown, Generation 2 adds standard MCP tools that call live APIs but still output static text, and Generation 3 pairs each tool with a live workspace so adjustments happen in the widget without a model turn. The claimed benefits are a responsive user experience, purpose-built workflows such as redaction views for legal review and 3D viewers for CAD, enterprise security, human-in-the-loop governance for high-stakes actions, an open standard with automatic text fallback, and connectivity to BigQuery, Agent Platform, Cloud Storage, or internal ERP/CRM systems.

The architecture has three decoupled tiers. The client browser shows chat alongside the MCP App widget in the side panel. Gemini Enterprise is the middle tier: its default assistant calls tools, an AppBridge proxy relays widget messages, and the connector manages OAuth. Google Cloud is the backend tier where you deploy and host the MCP server on Cloud Run; the server exposes one JSON-RPC endpoint (/mcp), runs background jobs, and serves the single-file HTML widget. Each tier talks only to its neighbor, letting Gemini Enterprise enforce security and routing.

Authentication uses OAuth 2.0 with two independent layers. On every call, Gemini Enterprise sends its service agent token alongside the user’s OAuth token. Layer 1 is Cloud Run IAM, enforced at Google’s edge, which answers which service may call; public access is disabled and unauthorized callers receive HTTP 403. Layer 2 is in-app OAuth, enforced inside the application, which answers which user is calling; failed verification returns HTTP 401 and prompts the user to sign in again. Both layers are required because Cloud Run IAM cannot distinguish end users. Outbound calls use a least-privilege service account.

To build, you create a custom MCP server exposing POST /mcp and a bundled ui:// HTML widget using the MCP Apps SDK, or you can scaffold with Google Antigravity using the create-mcp-app skill. The generated server includes a Streamable HTTP backend with under-two-second async tool responses and get_app_state polling, plus Cloud Run deployment commands. The deployment path has seven steps: enable APIs for Cloud Run, Discovery Engine, Agent Platform, and Organization Policy; deploy with gcloud run deploy … –source . and flags –no-allow-unauthenticated, –no-cpu-throttling, and –min-instances=1; grant the run.invoker role to the Discovery Engine service agent; create an OAuth 2.0 web client with the redirect URI https://vertexaisearch.cloud.google.com/oauth-redirect; override the custom MCP server connector org policy constraint and register the connector with your service URL, Google OAuth endpoints, scopes, PKCE enabled, and HTTP Basic Auth unchecked; enable actions by reloading custom actions and selecting the model-visible tools; and connect the data store to your Gemini Enterprise app under Connected data stores rather than Add Agent.

The piece closes by emphasizing that you do not build a chat frontend or identity pipeline: one Cloud Run container attached as a data store is enough, and Gemini Enterprise is where enterprise work gets done.