Google has announced a developer preview of its Connected Apps Platform, expanding the route for businesses to bring their services into Search and the Gemini app.
Announced on 28 October 2026, the platform supports integrations through cloud-hosted Model Context Protocol servers or Android AppFunctions. Developers can register, test and submit integrations through Google Connected Console, choosing Search, the Gemini app or both before review.
The announcement is an opening for broader developer participation, not immediate worldwide availability or automatic acceptance of submitted apps. Google says it will expand access across developers, markets and products over the coming months.
From answering questions to using services
Connected Apps let users link a service and access authorized account information or perform supported actions from applicable Google products. Instead of only describing how to complete a task, an assistant can call tools exposed by the connected service.
Our MCP explainer covers that distinction: connecting an agent to a tool gives it a defined interface for retrieving information or requesting an operation.
For a business, that could mean exposing availability checks, account functions or booking operations rather than relying entirely on an agent navigating its website. These are illustrative possibilities, not capabilities every submitted integration automatically receives.
Google already had Connected Apps before this announcement. The new development is a more standardized onboarding and management route for additional developers.
Two integration paths, with different execution models
Google describes remote MCP servers and Android AppFunctions as complementary approaches.
Its MCP guide recommends a remote server as the default for foundational cross-platform capabilities. An existing web API or MCP server can provide a starting point, subject to Google’s integration requirements.
AppFunctions target deeper Android experiences, including actions that depend on an app’s current state or on-device context. The two paths should not be treated as proof of identical behavior across every device and Google surface.
One useful detail for infrastructure teams is that remote MCP hosting is not restricted to Google Cloud. Google’s guide allows any preferred cloud provider or infrastructure, with a public HTTPS endpoint required for remote testing.
Registration does not mean an app is live
Connected Console provides a management layer for integration details, testing, review and publication. Google says developers can monitor traffic, latency and error rates after an integration goes live.
TechCrunch reports initial access for U.S. developers.
For developers elsewhere, a public documentation page should not be mistaken for confirmed admission to the preview. Likewise, selecting a target surface does not establish that an app is immediately available to all its users.
Google also separates the platform preview from partner rollout plans. It says integrations already live in Gemini will come to Search in the following weeks, alongside a forthcoming Calm integration. Those are rollout statements, not confirmation that every announced connection is available everywhere today.
Permission controls are documented, but still need testing
Google’s implementation guidance includes explicit tool annotations for read-only and destructive operations. Developers can also mark operations requiring confirmation in Connected Console. These are documented configuration mechanisms, not independently verified enforcement results.
Its OAuth guide describes user consent and delegated access. It also documents an optional revocation endpoint through which a service can invalidate tokens when a user disconnects an integration.
Google’s platform policies require minimum necessary data and permissions, prohibit undisclosed functions and unsolicited actions, and allow rejection or removal of non-compliant integrations. These are developer obligations, not guarantees that an approved app cannot fail.
Our coverage of the AWS MCP authorization flaw illustrates why tool access and authorization need separate scrutiny. That incident concerns a different implementation and is not evidence of a vulnerability in Google’s platform.
The business opportunity needs an outcome test
AgentsCalling’s analysis is that this creates another potential distribution channel for services: users may complete a task inside an AI conversation rather than begin on a business’s website.
But registration alone does not prove discovery, customer adoption or commercial value. A useful evaluation would measure whether the correct tool is selected, the intended action succeeds and the user understands what changed.
Our proposed test would use a synthetic booking service with separate availability, reservation and cancellation operations. Across accessible surfaces, we would examine tool discovery, confirmation before a booking, duplicate-action handling and behavior after access is revoked.
No such testing has been performed by AgentsCalling. The substantive announcement is a broader developer integration route. Its practical value will depend on admission, reliable execution and permission boundaries that work beyond a demonstration.
About Puneet Sharma
Puneet Sharma · Freelance Writer
Puneet Sharma is a freelance writer covering AI agents, automation and the software changing how we work. His coverage at AgentsCalling starts with the questions a reader might ask over a conversation: What does this tool actually do? Where does it fall short? And is it useful beyond the demo? His articles explore new launches, practical workflows and the trade-offs behind giving software more responsibility, with explanations that make room for readers who are still getting familiar with AI.
