MCP tools gain a live user interface
Google has detailed how developers can build Model Context Protocol apps that run interactively inside Gemini Enterprise. The design follows the MCP Apps extension, known as SEP-1865, which lets a tool return both structured information and a user interface resource. Instead of receiving only prose or a static card, a user can inspect and manipulate a live interface without leaving the conversation.
This changes the role of an enterprise agent. A travel tool might present selectable itineraries, a data tool could expose filters and a support workflow could show a form with validated fields. Local interface changes do not need a fresh model turn every time, reducing latency and token use. The model remains useful for intent and orchestration while deterministic interface code handles direct interaction.
The interface runs inside a sandbox
Gemini Enterprise renders the app in a sandboxed iframe, either in a side panel or full-screen view. Isolation limits the interface’s access to the host application and gives the platform a place to enforce presentation and communication rules. Developers still need to treat every message crossing the boundary as untrusted input and validate it on the server before performing an action.
A richer interface can make approval more meaningful. Before a tool sends a message, changes a record or starts a costly job, it can display the exact parameters and request confirmation. That is better than hiding an irreversible action inside a conversational sentence. The confirmation must remain bound to those parameters so an agent cannot substitute a different target after the user approves.
Cloud Run hosts the MCP endpoint and bundled widget
Google’s example packages the server for Cloud Run and exposes an MCP endpoint at POST /mcp. The tool metadata refers to a ui:// resource containing the HTML application, allowing Gemini Enterprise to retrieve and render the widget associated with the call. A text response remains available as a fallback for clients that do not understand MCP Apps, which preserves portability across different hosts.
Bundling the interface with the service helps keep the tool contract and presentation in step, but it also creates a release-management duty. Teams should version tool schemas and UI resources together, test older clients and avoid assuming that a visual control is present. The text path should be complete enough for accessibility, automation and incident recovery rather than acting as a decorative afterthought.
Authentication has two distinct layers
The guide separates service access from end-user authorisation. Gemini Enterprise can use its service agent to obtain a token accepted by a private Cloud Run service, while the app can use OAuth to act for the signed-in user. Cloud Run IAM protects the infrastructure boundary; user OAuth determines what the person is allowed to do inside the connected business system.
Keeping those layers separate avoids turning one broad service credential into a universal user identity. Tokens should be short-lived, audience-restricted and requested only for the scopes needed by the current tool. The MCP server must enforce the user’s entitlements even when the request arrives through an approved Gemini service. A trusted caller does not make every requested business action authorised.
Registration turns the server into an enterprise data source
Developers register the service in Gemini Enterprise as a Custom MCP Server data store. Administrators can then make the capability available within an environment already governed for enterprise search and agent work. Before rollout, organisations should verify region support, connector access, logging, data residency and how the app behaves when a user loses permission during a session.
The guide shows why MCP is becoming more than a catalogue of callable functions. An app can combine model reasoning, a portable protocol and a purpose-built interface in one workflow. The strongest implementations will keep the model away from tasks that normal interface code performs more reliably, expose clear approval points and preserve a usable fallback. Interactive MCP apps can make agents easier to supervise, but only if identity and policy are enforced behind the attractive surface.
What teams should test next
Teams should also test the interface as a product rather than assuming the protocol guarantees usability. Keyboard navigation, screen-reader labels, error recovery and narrow displays all matter when the widget becomes the approval surface for a business action. Security review should cover content security policy, dependency integrity and attempts to inject instructions through data displayed inside the app. A signed version record linking the MCP tool schema, widget bundle and backend release would make incidents easier to reconstruct. The result should be an interaction that remains clear and safe even when the model, network or connected service behaves unexpectedly.
Procurement and engineering teams should record the source date, product version, supported region and evaluation conditions before relying on the result. They should then repeat the same representative tests after a model, compiler, connector or policy changes. Published performance and capability claims are useful starting points, but production confidence comes from evidence collected in the organisation’s own environment. A named owner, measurable acceptance threshold and documented fallback turn a promising technical release into a service that can be governed over time.