# Google previews a shared app integration route for Search and Gemini > Google’s Connected Apps preview offers a remote route to Search and Gemini and an Android route to Gemini. By BIGCHANGE.AI Editorial Published: 2026-10-29T00:33:39.134Z Updated: 2026-10-29T00:33:39.134Z Canonical: https://bigchange.ai/blog/google-connected-apps-preview ![Conceptual illustration of a hand using the trackpad of a laptop displaying generic code-like marks.](https://bigchange.ai/api/media/file/connected-apps-integration-hero-v1.png) AI-generated conceptual illustration by BIG CHANGE; no actual Google interface or tested integration is depicted. Google opened a preview of its Connected Apps Platform on October 28, giving developers a shared place to register and manage integrations for Search and the Gemini app. ## The big change - Google's shared console gives developers one place to manage integrations for Search and Gemini. Each service still decides which tool operations and results it exposes. - Account authorization and tool behavior are separate decisions. Permission to read an account does not by itself define which changes a tool can make. - A working integration still needs testing and review before it can be published. Developers cannot promise a launch merely because their endpoint responds. ## Choose a connection Google's [developer guide](https://developers.google.com/connected-apps/gpc/perform-the-steps) describes two choices. A remote MCP server can serve Gemini and Search across web, Android and iOS. Android MCP exposes on-device app capabilities to Gemini on Android; the guide does not present that route as a Search integration. In the [MCP specification](https://modelcontextprotocol.io/specification/2025-11-25/server/tools), a client discovers tools with `tools/list` and calls one by name with arguments. The server describes expected inputs in a schema and returns a result. That division gives a team concrete places to investigate a failed interaction: discovery, the arguments supplied and the service's response. The specification distinguishes protocol errors, such as a malformed request, from execution errors returned by a tool. Both can interrupt a task, but they point the developer toward different repairs. ## From endpoint to review For a remote server, Google's console guide requires a public HTTPS endpoint and domain verification using a hosted challenge token. The verification URL must return the token with HTTP 200 without redirecting. Developers configure credentials, sync tools, add testers and submit the app for review. Google says the console can then report traffic, latency and errors. For delegated account access, Google's [OAuth guide](https://developers.google.com/connected-apps/mcp/oauth) recommends OAuth 2.1 with PKCE. The [PKCE standard](https://www.rfc-editor.org/rfc/rfc7636.html) describes a verifier and challenge that help protect an intercepted authorization code from being exchanged by another client. Authentication establishes whose account is involved; the service still needs to define what each exposed tool can read or change. The underlying [OAuth authorization framework](https://www.rfc-editor.org/rfc/rfc6749.html) distinguishes the person who grants access, the client requesting it and the service that protects the resource. In an authorization-code flow, the client obtains a temporary code and exchanges it for an access token. The token is the credential used to request protected resources; it is not a substitute for deciding which permissions the service should grant. The framework also permits an authorization server to issue a refresh token for obtaining a new access token; issuing one is optional, and it is intended for the authorization server rather than the resource server. The IETF's later [OAuth security guidance](https://www.rfc-editor.org/rfc/rfc9700.html) recommends restricting tokens to the privileges and resource servers needed for the task. That gives the developer a practical review question for a connected tool: whether its token can reach more data or perform more operations than the tool needs. A narrow tool description is useful to the caller, but the service must enforce the token's actual permissions. Google says developers choose destinations before review and that preview access will expand in phases. A successful test on one account does not establish approval or availability in every market. BIG CHANGE reviewed the documentation; it did not build an integration or test Google's review process. ## Sources - [Build and manage Connected Apps in one place](https://blog.google/innovation-and-ai/technology/developers-tools/connected-apps-one-place/) — Google announces the preview, destination choice and phased access. - [Connected Apps Platform](https://developers.google.com/connected-apps) — Remote and Android integration overview. - [Build Connected Apps for Google products](https://developers.google.com/connected-apps/mcp/quality) — Quality guidance on useful app capabilities. - [OAuth 2.1 implementation guide](https://developers.google.com/connected-apps/mcp/oauth) — OAuth authorization guidance, including PKCE. - [Register, test and publish your connected app](https://developers.google.com/connected-apps/gpc/perform-the-steps) — Console setup, testers and review. - [RFC 7636: Proof Key for Code Exchange](https://www.rfc-editor.org/rfc/rfc7636.html) — IETF standard describes PKCE and the authorization-code interception threat. - [MCP specification: Tools](https://modelcontextprotocol.io/specification/2025-11-25/server/tools) — MCP specifies tool discovery, schemas and invocation; it does not establish Google approval. - [RFC 6749: OAuth 2.0 Authorization Framework](https://www.rfc-editor.org/rfc/rfc6749.html) — IETF framework defines the roles and authorization-code token flow. - [RFC 9700: OAuth 2.0 Security Best Current Practice](https://www.rfc-editor.org/rfc/rfc9700.html) — IETF security guidance discusses restricting access-token privileges.