Google Connected Apps Platform: How to Put Your App Inside Gemini and AI Mode
On 28 October Google opened a preview that lets outside apps run inside the Gemini app and, soon, AI Mode in Search. The way in for a web service is a remote MCP server. Here is what Google's own documentation requires, the OAuth details that trip servers built for Claude and ChatGPT, and what to check before you apply.
Oct 29, 2026
To put your app inside Gemini and AI Mode in Search, you expose it as a remote MCP server on public HTTPS with OAuth 2.1 sign-in, then apply to Google's Connected Apps Platform preview and register, test and submit it in Google Connected Console. Google opened the preview on 28 October 2026: users link their account once, and Gemini can then read their data in your service and act there on their behalf. Android apps have a second path, AppFunctions, where the tools run on the phone. Below: what Google's MCP guide and OAuth guide actually require, and where a server built for Claude or ChatGPT needs changes.
What Google announced on 28 October
From Google's developer page and the launch coverage:
- One integration, two surfaces. Connected apps appear in the Gemini app, with Search to follow. Launch coverage says developers pick Search, Gemini or both before review.
- Two ways in. A cloud-hosted MCP server, signed in with OAuth 2.1, or Android MCP through the Jetpack AppFunctions SDK, with tools running locally on the device.
- Interactive UI is optional. Tool results can bind to custom UI through MCP Apps, which Gemini renders "in secure sandboxed iframes".
- A console for the whole lifecycle. Google Connected Console handles tool registration, testing with preview testers, usage analysis, review and publishing.
- Apps already live. Coverage reports more than 50 connected apps in Gemini, among them Adobe, Experian, Localiza and Peloton.
- Access is by application. You apply for the preview. Reports differ on who gets in first: one describes a beta for US developers with a waitlist, others say access opens in phases without naming markets. Google's own pages do not list regions.
For a software company, this is the third assistant marketplace in a year, after ChatGPT apps and Claude connectors. All three run on MCP. The one built for the first two is most of the way to the third.
What the MCP server must do
Google's MCP guide is short. The requirements it states:
- Host the server on a public HTTPS endpoint. Google's pages do not name a transport; the MCP specification's remote transport is Streamable HTTP, which is what Claude, ChatGPT and Gemini Enterprise use.
- Annotate every tool. Google asks you to "declare explicit protocol annotations for every tool":
readOnlyHint=Trueon queries,destructiveHint=Trueon anything that changes state. These are not decoration. Assistants use them to decide when to ask the user first. - Mark confirmations in the console. Operations that need a user's explicit yes are flagged in Google Connected Console, on top of the annotations.
- Test before you submit. Locally with the MCP Inspector (
npx @modelcontextprotocol/inspector), then live in Gemini Developer Mode, then with preview testers in the console. - Submit for review and publication in the console.
What the guide does not specify: a limit on the number of tools, timeouts, or support for MCP resources and prompts. Design for tools, keep each one doing one job, and paginate large results.
The OAuth details that trip existing servers
The OAuth 2.1 guide is where a server built for Claude or ChatGPT needs a second look.
- Discovery order is fixed, and errors count. Gemini tries
/.well-known/oauth-authorization-server, then/.well-known/openid-configuration, and uses "the first URL that returns a response, including an error". If the first path returns a 404 page with a 200 status, or a 500, Gemini stops there. Serve valid metadata at the first path. - Required metadata fields:
authorization_endpoint,token_endpoint, andresponse_types_supportedcontainingcode. Addscopes_supportedif you use scopes. - PKCE is mandatory. Advertise
code_challenge_methods_supported: ["S256"]and check the verifier at the token endpoint. - Dynamic Client Registration is the expected route. Your discovery document must include a
registration_endpoint, "even if your server supports Client ID Metadata Documents". Without it, you enter a client ID and secret by hand in the console. - Allowlist Google's redirect URIs:
https://oauth-redirect.googleusercontent.com/r/*and/a/*, plus the-sandboxand-testvariants while you test. A server that only accepts Claude's and ChatGPT's callbacks will refuse the link. - Do not rotate refresh tokens. This one runs against common practice. OAuth 2.1 encourages rotating the refresh token on every use, and many servers do. For what Google calls Persistent Linking, it asks you to return "the exact same Refresh Token" and extend its expiry on your side, so users are not asked to link again.
- Revocation is optional but worth it. If you implement it, Gemini calls it when a user unlinks, and the token must die for good.
Connected Apps vs Gemini Enterprise vs ChatGPT and Claude
| Connected Apps (Gemini app, Search) | Gemini Enterprise | ChatGPT apps, Claude connectors | |
|---|---|---|---|
| Who uses it | Consumers and professionals in the Gemini app, then Search | Employees of a company on Gemini Enterprise | ChatGPT and Claude users |
| Who adds your app | Google reviews and publishes it; users link their account | An administrator adds your server as a data store | Directory review, or a custom connector added by the user or an admin |
| Sign-in | OAuth 2.1, PKCE, DCR or manual client | OAuth 2.0, client ID and secret registered by you | OAuth with PKCE; clients can register themselves |
| Refresh tokens | Keep the same token (persistent linking) | Standard | Rotation accepted |
| Optional UI | MCP Apps in sandboxed iframes | Not documented | Apps SDK UI (ChatGPT), MCP Apps |
The tools are the same everywhere. The differences sit in sign-in and review, which is why one well-built server can serve all four. See what MCP OAuth is and remote MCP servers.
Should you apply now?
If your users already live in Google's products, yes, and early: the preview is the window when there are fifty apps in the directory, not five thousand. Apply if:
- your product holds data your users ask questions about (orders, bookings, accounts, tickets), or
- it has actions people would rather ask for than click through (book, reorder, update, approve).
Wait if your product has no per-user account to link, or if every action is destructive and nobody has defined who may do what. An assistant that can act needs permissions decided first. Our MCP security guide covers that part.
What we do, and what we don't do yet
What we run, checked in our code: MCP servers on the official Go SDK, stateless over Streamable HTTP. Our CRM's authorization server publishes metadata at /.well-known/oauth-authorization-server, the first path Gemini tries, with a registration_endpoint for dynamic registration, S256 PKCE and the refresh token grant. Every tool carries a readOnlyHint or not, and the scope a tool needs is derived from it: read-only tools need the read scope, everything else needs write.
What we don't do yet: we have not put one of our servers through Google's Connected Apps review, and we are not in the preview yet. Two changes stand between our CRM server and Google's requirements, both found while writing this. It rotates the refresh token on every refresh, which is the OAuth 2.1 default and the opposite of what Google asks for persistent linking. And its redirect allowlist would need Google's googleusercontent.com URIs. Neither is large. Both would break account linking if missed.