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

Three isometric platforms, a search bar, a chat bubble and a phone, linked by teal cables to a single server block with a key and a shield

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:

  1. 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.
  2. Annotate every tool. Google asks you to "declare explicit protocol annotations for every tool": readOnlyHint=True on queries, destructiveHint=True on anything that changes state. These are not decoration. Assistants use them to decide when to ask the user first.
  3. Mark confirmations in the console. Operations that need a user's explicit yes are flagged in Google Connected Console, on top of the annotations.
  4. 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.
  5. 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, and response_types_supported containing code. Add scopes_supported if 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 -sandbox and -test variants 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 EnterpriseChatGPT apps, Claude connectors
Who uses itConsumers and professionals in the Gemini app, then SearchEmployees of a company on Gemini EnterpriseChatGPT and Claude users
Who adds your appGoogle reviews and publishes it; users link their accountAn administrator adds your server as a data storeDirectory review, or a custom connector added by the user or an admin
Sign-inOAuth 2.1, PKCE, DCR or manual clientOAuth 2.0, client ID and secret registered by youOAuth with PKCE; clients can register themselves
Refresh tokensKeep the same token (persistent linking)StandardRotation accepted
Optional UIMCP Apps in sandboxed iframesNot documentedApps 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.