Google Connected Apps Platform: Gemini + Search (2026)

How Google's Connected Apps Platform works, who should build for it, and the exact steps from MCP server to a live app in AI Mode and the Gemini app

On October 28, 2026, Google opened one door into two products that each count around a billion users. The Connected Apps Platform lets any developer register a single integration (a remote MCP server or an Android app built with AppFunctions) in a new Google Connected Console, and choose whether it goes live in AI Mode in Search, the Gemini app, or both - Google. The same week, Alphabet reported that the Gemini app "is now at one billion users" - Alphabet. Three months earlier, it had said AI Mode "surpassed 1 billion monthly active users" - Alphabet.

The catch is that almost nobody has read the rules yet. The platform is a US-only, waitlisted preview, its documentation is spread across a dozen pages on two Google developer sites, and several requirements (a pinned MCP protocol version, an OAuth server that must not rotate refresh tokens, a domain token with no file extension, a ban on third-party ads) are easy to miss and expensive to discover at review. Meanwhile the old route into Google, ranking a page and earning a click, keeps getting narrower: one 2026 study of 300,000 keywords found an AI Overview now correlates with a 58% lower click-through rate for the top-ranking page - Ahrefs.

This guide covers what Google actually launched, the first-principles case for (and against) building a connected app, how a request flows from a user's prompt to your server, the choice between MCP and AppFunctions, a working server, OAuth account linking, every console step, testing in Gemini Developer Mode, the policy lines that get apps rejected, and how Google's door compares with ChatGPT plugins, Claude connectors, Meta's Muse and the organic route. Everything here was checked against Google's live documentation on November 2, 2026, five days into the preview.

Contents

1. What Google Launched on October 28, 2026
2. Why This Matters: From Ranking Pages to Being Called
3. How a Connected App Works Inside Gemini and AI Mode
4. Who Should Build One (and Who Should Not)
5. MCP Server or Android AppFunctions: Choosing Your Path
6. Building the MCP Server: A Working Example
7. Account Linking: OAuth 2.1 the Way Google Checks It
8. Registering in Google Connected Console, Step by Step
9. Testing in Gemini Developer Mode and Passing Review
10. The Rules: Policy, Commerce and What Gets You Rejected
11. The Other Doors: ChatGPT, Claude, Muse, WebMCP and Organic Search
12. Risks, Failure Modes and the Control Question
13. A 30-Day Plan to Get In During the Preview
14. The Outlook: Where Search, Gemini and Apps Are Heading
15. The Decision, in One Page

The 2026 Scorecard: 8 Ways Into AI Answer Surfaces

A connected app is one of several ways to put a product in front of people who now ask an AI instead of browsing. The table scores the eight that matter in November 2026 on the same five criteria, from the point of view of a product team deciding where to spend its next month. Every row, including Google's two paths, is scored on the evidence linked in the sections below, and the table is sorted by the weighted result.

How the criteria are weighted. Reach (25%) is the audience the surface can put you in front of today, using each company's own reported metric. Open Today (15%) is whether a team without a partnership can get in now. Build Effort (15%) scores higher for less work. Depth of Action (25%) is the heart of the matter: whether the integration can read a signed-in user's state and change it, rather than just being quoted. Commercial Control (20%) covers who owns the customer, the checkout and the data, and what the platform's rules forbid. ChatGPT ranks first on reach and openness; Google's MCP path is a close second and the only one that reaches two billion-scale surfaces with one build. The more useful reading, which section 11 develops, is that rows 1, 2 and 5 accept the same MCP server, so the real decision is less "which platform" than "in what order".

1. What Google Launched on October 28, 2026

The announcement itself was short. In a post signed by Chips Mistry, Group Product Manager for Search, and Mai Lowe, Group Product Manager for the Gemini app, Google described the Connected Apps Platform as a single system for developers to build and manage apps that run in Search and the Gemini app: developers "integrate with a cloud-hosted MCP server or Android MCP using the AppFunctions APIs, then use the Google Connected Console to register, test, and submit their app", choosing before review whether it goes live "in Search, the Gemini app, or both" - Google. After launch, developers can track traffic, latency and error rates, and manage brand identity through verified logos and authenticated accounts.

What changed is not that Gemini can call third-party services. That has been true for months. What changed is who can get in. Until now, 9to5Google noted, the creation process "has required working closely with Google" - 9to5Google. The console turns a business-development relationship into a self-service submission, the same shift that turned search ads from a sales-led product into an auction anyone could join. TechCrunch's framing is that this could be an early step for businesses seeking visibility on the "agentic web", and that the preview is open to "U.S. developers who sign up for the waitlist" - TechCrunch.

The image Google chose says a lot about the intended use. On the left, AI Mode shows "Checking connected apps" and returns a list from a meditation service; on the right, the Gemini app shows "Connecting to" a restaurant app and renders a Dinner Reservation card with a Confirm reservation button. Both examples are signed-in, stateful tasks, not information lookups, which is exactly the line Google's quality rules draw (section 4).

1.1 The road to the launch

The October announcement is the end of a year-long build-up rather than a surprise, and the sequence explains why the platform looks the way it does. Google introduced the Universal Commerce Protocol in January for agentic shopping - Google. Its background agent, Gemini Spark, arrived at Google I/O on May 19 with MCP connections to Canva, OpenTable and Instacart, and a macOS beta on June 30 added Dropbox, Zillow Rentals and custom MCP connections - PPC Land. On July 16, connected apps reached AI Mode in Search with Instacart, Canva and YouTube Music - Google.

The pace then picked up. On September 23 Google added fourteen third-party apps to Gemini, including Adobe and Experian - PPC Land. On October 15 it launched Universal Cart across Search and Gemini - Google. Thirteen days later, the developer platform opened.

The pattern is a classic platform sequence: prove the experience with hand-picked partners, standardize the interface (MCP on the server side, AppFunctions on Android, UCP for commerce), then open self-service. Android's own Dev Summit recap the same day spelled out the builder's version: "You can build natively using Android MCP or remote MCP, prototype using Gemini dev mode, and register through the Google Connected Console preview program" - Android Developers Blog.

1.2 What Google did not say

The gaps in the announcement matter as much as the content, because each one is a risk you carry during the preview. Google published no fees and no revenue share, which in practice means the platform is free to join. It published no ranking logic for how the model chooses between competing apps, beyond the help page's note that AI Mode "may default to the last app you used for a certain task" - Google Search Help. It published no review time, no developer count and no date for availability outside the US.

On scale, the post says Google has launched "more than 50" connected apps across Search and Gemini, and that access is opening in phases, with more developers, markets and Google products to follow - Google. On the Search side today, the live list is short (Instacart, Canva, YouTube Music, Yahoo Fantasy Football and Sleeper), and it is "currently available in AI Mode in the US, in English" - Google Search Help. Google's own Search advocate John Mueller called it "still extremely early" in a personal post quoted by Search Engine Roundtable - Search Engine Roundtable. Read that as both a warning and an opening.

2. Why This Matters: From Ranking Pages to Being Called

The surface question is "should we add another integration?" The structural question is what a search engine actually sells, and what happens to everyone downstream when that changes. For twenty-five years Google sold the shortest path from intent to outcome, and the shortest path was a ranked list of documents. Businesses competed to be the document, because the document was where the click went, and the click was where the customer was won. SEO, content marketing and most of the modern web's economics are built on that one fact.

A model that can complete the task changes what "shortest path" means. If a user says "reserve the 7:30 table for four", a list of restaurant pages is no longer the shortest path; a booking is. The document becomes an intermediate artifact the model reads on the way to an answer, and what the engine needs from a business stops being a page and becomes a capability: live availability, the user's account, the ability to act. A web page is an interface designed for humans to read. An MCP tool is an interface designed for a model to call. The Connected Apps Platform is Google formally asking businesses for the second kind.

2.1 What the click data says

The evidence that the document channel is narrowing is now broad and consistent, even though individual studies measure different things. The most careful independent behavior study, from Pew Research, found that users who saw an AI summary clicked a traditional result in 8% of visits, against 15% when no summary appeared - Pew Research Center. A randomized field experiment with 1,065 Chrome users, reported in April, measured outbound organic clicks falling 39.8% - PPC Land. Across Chartbeat's publisher network, Google Search referrals fell 40.2% year over year from July 2025 to July 2026 - Search Engine Journal.

The longest-running query-level dataset adds nuance rather than contradicting the trend. Seer Interactive's 2026 update, covering 53 brands and 5.47 million queries, found organic CTR on queries with an AI Overview fell to a floor of about 1.3% in December 2025 before recovering to about 2.4% in February 2026, still well below the 3.82% on queries without one - Seer Interactive.

There is a fair counter-argument, and it should be taken seriously. Google has said total organic click volume to websites has been "relatively stable year-over-year" - Google. Its Search leadership also says AI features alone send "billions of clicks to websites every week" - Search Engine Roundtable. Both can be true at once: more searches, longer searches, and a smaller share of each one ending in a click. Alphabet's own Q3 remarks note that AI Mode queries are "on average three times longer than traditional searches" - Alphabet. Longer queries are more task-like, and tasks are exactly what a page cannot complete and a tool can.

2.2 The reach on the other side of the door

The audiences behind these surfaces are now comparable to the open web itself, which is why the integration decision has moved from "experiment" to "channel". The figures below use each company's own metric, so they are not perfectly comparable (weekly, monthly and "users" are different things), but the order of magnitude is the point.

The Gemini and AI Mode figures come from Alphabet's Q3 and Q2 letters cited above. OpenAI cites "1.2B weekly users" of ChatGPT - OpenAI. Google said at I/O that AI Overviews reach more than 2.5 billion users - Fortune. And Mark Zuckerberg said more than 10 million people in the US and Canada have set up Muse accounts - AP via KPRC.

2.3 Three structural forces, and the one that decides timing

Reasoning from those facts, three forces make connected apps more than another integration checkbox. The first is cost asymmetry: Google pays for the model's reasoning on every request, and you pay only for the server that answers (section 6.3 puts numbers on it), so the marginal cost of being present is close to zero. The second is that the account link is the moat. A user who has linked your service has done the hardest thing in the funnel, and every future request in your category can route to you without another decision. The third is that routing is sticky: because AI Mode may default to the last app used for a task, early adoption compounds.

The force that decides timing is the third one, and it is worth pressure-testing. It would be wrong to conclude that every business must rush in: if your value is public information, the platform's own rules exclude you, and if your product has no account state, there is nothing to link. And the preview is US-only, waitlisted and English-only in Search, which caps the upside today. But for a product whose value lives behind a login, the asymmetry runs one way. The cost of building is a few weeks; the cost of being second in a category where the model already defaults to a competitor is much harder to recover. That is the same lesson app stores taught in 2008 and search taught before that, and the dynamics here are, if anything, stronger, because users do not even see the list of alternatives.

3. How a Connected App Works Inside Gemini and AI Mode

Before writing a line of code, it helps to see the request from Google's side, because almost every design decision in the rest of this guide follows from it. A connected app is not a page Google crawls or a widget it embeds. It is a set of tools that Google's model can decide to call in the middle of a conversation, plus an account link that tells your server which of your users is asking. Google's own description is that the platform "analyzes a user's query" and "checks the available tool schemas to find the right ones", then sends the command and its parameters to your server for execution - Google for Developers. Your server does the work against your real systems and returns a result, and Gemini writes the answer around it.

That sequence has three consequences that matter more than any API detail. First, the model is your interface: it reads your tool names, descriptions and parameter schemas, and decides from those alone whether you are the right tool. Second, the user never sees your product unless you return a card or they click out, so your brand lives in a small header and in whatever UI resource you supply. Third, Google pays for the reasoning. Every token Gemini spends planning, calling you and writing the reply runs on Google's infrastructure; your bill is the server that answers the call. That last point is the quiet economic engine of the whole platform, and we return to it in the cost section.

3.1 How users reach your app

There are two ways a request lands on your server, and they behave very differently. The explicit path is the @mention: Google's docs say a connected app "can be explicitly triggered with @<connected appname> or mentioning the <connected app name> in the query", and the app then stays in context for relevant prompts in the same session - Google for Developers. This is why the console forces you to write example prompts that begin with @YourAppName: it is the one path where you are chosen by name rather than by the model's judgment.

The implicit path is the one that scales. A user asks for something ("reserve the 7:30 table for four") without naming anyone, and the model decides which linked app, if any, should handle it. Google's Search help page adds a detail every builder should read twice: AI Mode "may default to the last app you used for a certain task", and the user can switch by naming another app - Google Search Help. In plain terms, the first app linked for a job tends to keep that job. That makes the preview period a land grab inside each task category, which is the strongest argument for moving now rather than waiting for general availability.

Linking is the gate on both paths. In Search, the help page describes the flow: name the app or pick it from a list, click "Link", and complete the steps in AI Mode, after which the connection is managed under the Google Account's linked apps page - Google Search Help. Search Engine Roundtable adds that a searcher will not see an app at all until they add it in their Search settings - Search Engine Roundtable. In the Gemini app, testers and users find apps by typing @ or under Settings & help, Connected apps - Android Developers. Every one of those steps is friction, so the first link is the real conversion event, and everything after it is retention.

3.2 What the user sees

The default output of a tool call is text that Gemini paraphrases. The richer option is a UI resource: you bind a tool's output to an HTML resource through metadata, and the client renders a branded, interactive widget in a sandboxed iframe inside the conversation - Google for Developers. This is the MCP Apps extension, and Google is explicit that "MCP Apps for Connected Apps is in beta" and that detected UI resources may be ignored - Google for Developers. Build the text path first and treat the card as an upgrade.

Google's design guidelines are strict about when a card is warranted. Inline cards are for "quick confirmations, structured data inspection, or single-step actions", and full screen is for multi-step, data-heavy work; carousels hold 3 to 8 cards, footers allow one primary call to action, brand color belongs on buttons and logos rather than backgrounds, and the platform supplies its own error component so you never build one - Google for Developers. The guidelines also forbid automatic redirects out of the host surface: leaving must always be an explicit click. That rule is the hinge of the commerce story later, because it means checkout handoffs are always a user decision.

The model can also receive context you did not ask the user for, if you justify it. In the console, each tool can request the user's locale, an approximate location (an area of at least 3 square kilometers) or a precise location (within 50 meters), with Google's caution that "You shouldn't request additional context unless there is a clear requirement and purpose" - Google for Developers. For local services, ticketing and delivery, approximate location is the difference between a useful first answer and a clarifying question, so request it for the tools that need it and nowhere else.

Google published a short official session on the whole lifecycle at Android Dev Summit, presented by Kateryna Semenova and Mai Lowe (one of the two product managers who signed the launch post). It is the best twenty-four minutes you can spend before building, because it shows the console, a remote MCP demo and the testing loop end to end.

The chapters map neatly onto this guide: the platform overview starts at 3:57, trust, privacy and user control at 7:31, the remote MCP server demo at 12:56, custom UI at 14:42, and the testing and validation workflow at 17:15. If you only watch one segment, watch the testing workflow, because it is where most first submissions will fail.

4. Who Should Build One (and Who Should Not)

The single most useful page in Google's documentation is not a technical one. It is the quality page, which defines what Google wants on the platform and, more bluntly, what it does not. The platform exists for services that get better after sign-in or that let users get live context and complete actions: Google asks that an app meet at least one of those two pillars, and ideally deliver all three foundations of live data, personal context and taking action without switching apps - Google for Developers.

The same page lists what a connected app is not, and this list should decide whether you build at all. It is not a replacement for an existing Google data feed (moving the same read-only data to a live tool call "is a transport change, not a connected app"), not a way to get a more prominent UI for general information, and not a source of generic, signed-out information that does not change the answer users could already get from Gemini or Search - Google for Developers. In other words, content publishers are not the target. If your value is articles, reviews or reference pages, your channel remains organic search and citations, which we covered in depth in our guide to getting your site cited by ChatGPT and Claude.

4.1 The first-principles test: does your value live behind a login?

Strip the platform down and ask what Gemini cannot do without you. It already knows public facts, can read the open web and can summarize anything indexed. What it cannot do is see the state inside your product: this user's cart, their saved playlists, their pipeline, the open slots on Friday at 8 PM, the inventory in the store two kilometers away. Nor can it change that state: book, order, save, update, cancel. A connected app is valuable in exact proportion to how much of your product's value is state plus actions rather than information. That is why the first wave is dominated by productivity tools, marketplaces and booking services, and why a recipe blog gains nothing by wrapping itself in MCP.

The test is simple enough to run in a meeting. Write down the five most common things your users do in your product. For each, ask whether a stranger with web access could do it without an account. If the answer is yes for most of them, the platform will treat you as a feed and your review will be hard. If the answer is no, because each task needs the user's data or changes something on their behalf, you are exactly what Google is recruiting, and the account link becomes a durable asset.

4.2 The nine categories Google has defined so far

Every connected app is created inside a category that "defines baseline capability requirements and can't be changed later" - Android Developers. Google's vertical journeys page lists nine, each with expected user journeys and an example prompt, and says more categories are "coming soon" - Google for Developers. The table below condenses them.

Two details in that page carry more weight than they appear to. The grocery category is the only one with a hard technical requirement: "For Groceries we require developers to follow the Universal Commerce Protocol spec" - Google for Developers. And the baseline capabilities in most categories end in a handoff, not an in-chat payment: carts link to your checkout, ticket holds lead to checkout in your service, bookings that need a deposit are handed to you. Google is building the conversation layer and leaving the money layer with you, at least for now.

4.3 What is already live: our count of Google's own list

Google's launch post says it has launched "more than 50" connected apps across Search and Gemini - Google. The Gemini help center keeps a table of every connected app, and on November 2, 2026 it listed 86 entries - Gemini Apps Help. We classified each one by who built it. 14 are Google's own (Workspace, Photos, YouTube Music, Google Home, Google Ads and others), 18 are on-device apps from phone makers (Samsung, Xiaomi, OPPO, HONOR, TECNO, vivo, Lenovo and OnePlus notes, calendars and galleries), and 54 are third-party services, which squares with Google's "more than 50".

The distribution tells you where the competition already is and where it is not. Productivity is crowded (Airtable, Dropbox, GitHub, Linear, Miro, monday.com, Shopify, Xero, the Zoho suite and more), so a new productivity app is competing for the model's attention against names it already trusts. Health has three (Peloton, Strava, Zocdoc) and finance has one (Experian), which says less about demand than about how cautious both Google and partners are in regulated categories. And geography is narrow: by our count 27 of the 54 third-party apps are US-only, six are Brazil-only, six are India-only, and only 12 run in every country where Gemini does. For a builder outside the US, that is a signal that local players can still be first in their market, once Google opens the console beyond its US waitlist.

5. MCP Server or Android AppFunctions: Choosing Your Path

Google offers two connection types, and you must pick one per connected app; "you can only choose one connection type per connected app, and you can't change it later" - Android Developers. The choice is less about technology preference than about where your product's state lives and which surfaces you need. Getting it wrong means rebuilding the registration from scratch, so it deserves a deliberate decision rather than a default.

The MCP server path is a remote server on the public internet that speaks the Model Context Protocol. Google calls it the recommended default for "foundational, cross-platform capabilities", reaching Gemini and Search users on Android, iOS and the web - Google for Developers. The Android MCP path uses AppFunctions, an Android platform API that lets your installed app "behave like on device MCP servers", with tool execution happening locally on the phone - Android Developers. It is the path for experiences that need on-device content or system UI, and it currently reaches Gemini on Android only.

The table draws on three pages. Google's prerequisites page requires an MCP server "publicly reachable over HTTPS using the Streamable HTTP transport" with one global endpoint per app - Google for Developers. The Android guide ties availability to "the countries and languages targeted by your Play app" and reviews the connected app alongside the Play release - Android Developers. And the Jetpack release notes show 1.0.0-beta01 shipping on October 21, 2026 - Android Developers. Android's own Dev Summit post the same week put it in one line: "AppFunctions is now in beta" - Android Developers Blog.

5.1 The decision, reasoned from where your data lives

Most products should start with the remote MCP server, and the reason is structural rather than technical. A remote server reaches both destinations (Search and Gemini) on every platform, while AppFunctions reaches one destination on one operating system. If your product's state already lives on your servers (accounts, carts, bookings, documents), the remote server is a thin wrapper over APIs you already run, and it is the only path into AI Mode at all.

AppFunctions wins in a narrower but real set of cases. If your value lives on the device (a notes app whose content is local, a camera or gallery app, an offline-first tool), a remote server would have to sync that state upward first, which is both work and a privacy cost. The official FAQ frames the trade-off well: AppFunctions are OS-level hooks that "execute locally", while a standard MCP server "relies on cloud execution and network round-trips" - Android Developers. That is why the current Gemini list is full of phone makers' notes and calendar apps: their data is on the phone. Many teams will eventually run both as two connected apps, since each Play app links to only one Android MCP connected app, but a server-first launch is the faster route to both surfaces.

5.2 The protocol-version trap

There is a detail in Google's integration standards that will catch teams who build with the newest tooling. Google's platform supports MCP "up to version 2025-11-25" - Google for Developers. But the latest MCP specification is 2026-07-28, and its headline change is to "remove the initialize / notifications/initialized handshake" and remove protocol-level sessions from the Streamable HTTP transport - Model Context Protocol. Google's own console still relies on the old handshake: its troubleshooting page warns when your server "did not return an instructions field in its initialize response" and flags gateways that reject Google's clientInfo in the initialize request - Google for Developers.

The practical rule is to build on an SDK that serves both revisions from one endpoint. The official Python SDK's version 2 does exactly this: it "implements the 2026-07-28 revision, and it serves both revisions at once", answering a 2025-era client's initialize with nothing to configure - MCP Python SDK. A hand-rolled server written only to the 2026 spec, by contrast, would fail Google's tool sync on day one. The same changelog history explains another console behavior: the 2025-11-25 revision added OAuth Client ID Metadata Documents as a recommended registration mechanism - Model Context Protocol, which is why Google's console "checks for CIMD first and falls back to DCR".

6. Building the MCP Server: A Working Example

The server itself is the smallest part of the project, which surprises most teams. If your product already has an internal API, a connected-app server is a few hundred lines that translate model-shaped requests into calls to that API. The hard parts are elsewhere: deciding which handful of tools to expose, writing descriptions the model routes on correctly, and getting authentication right. We wrote a broader primer on the protocol, SDKs and hosting options in our guide to shipping an MCP server for your product; this section focuses on what Google specifically checks.

Google's integration standards boil down to a handful of rules that shape the code. Server instructions are added to the model's system prompt, so keep them "clear, directive, and token-efficient" and never relist tool names. Tool names should be explicit verb-noun pairs (publish_draft, not handle_content). Schemas need explicit types, enums for fixed values and IDs as strings. Outputs must be pre-aggregated: "Never dump raw database rows or complete unindexed logs into the tool return payload." And servers "exposing dozens of tools or deeply nested 'mega-tool' schemas will be flagged during review" - Google for Developers.

6.1 The code

Here is a complete server for a hypothetical restaurant-booking service, written against the current official Python SDK (version 2, where the server class is MCPServer and annotations are snake_case). It exposes two tools: a read-only search and a state-changing booking, each annotated the way Google's review expects.

# server.py  (pip install "mcp [cli]" uvicorn ; Python 3.11+)
import json
from typing import Annotated, Literal

from pydantic import Field

from mcp import MCPError
from mcp.server import MCPServer
from mcp.types import INVALID_PARAMS, ToolAnnotations

mcp = MCPServer(
    "Harbor Tables",
    instructions=(
        "Harbor Tables books restaurant tables. Use it to find open tables "
        "for a date and party size, and to book or cancel a reservation on "
        "the user's linked Harbor Tables account."
    ),
)


@mcp.tool(
    title="Find open tables",
    annotations=ToolAnnotations(read_only_hint=True, open_world_hint=False),
)
def find_open_tables(
    city: Annotated [str, Field(description="City name, for example 'Austin'.")],
    date: Annotated [str, Field(description="Date as YYYY-MM-DD.")],
    party_size: Annotated [int, Field(ge=1, le=12, description="Number of guests.")],
    meal: Literal ["lunch", "dinner"] = "dinner",
) -> str:
    """Find restaurants with an open table for a date and party size."""
    slots = inventory.search(city, date, party_size, meal)  # your existing backend
    # Google does not support structuredContent yet: serialize JSON into text.
    return json.dumps({"slots": [s.summary() for s in slots [:5]]})


@mcp.tool(
    title="Book a table",
    annotations=ToolAnnotations(read_only_hint=False, destructive_hint=True),
)
def book_table(
    slot_id: Annotated [str, Field(description="A slot_id returned by find_open_tables.")],
) -> str:
    """Book a table slot for the signed-in user and return the confirmation."""
    slot = inventory.get(slot_id)
    if slot is None:
        # Recoverable: tell the model what to do next.
        return "That slot is no longer available. Call find_open_tables again."
    if not slot.bookable:
        raise MCPError(code=INVALID_PARAMS, message="This slot cannot be booked online.")
    booking = bookings.create(slot, user=current_user())  # from the OAuth token
    return json.dumps({"confirmation": booking.code, "time": booking.time})


app = mcp.streamable_http_app()  # serve with: uvicorn server:app --port 8080

Three choices in that code come straight from Google's standards rather than from MCP itself. The booking tool carries destructive_hint=True, which makes the console pre-select "User confirmation required", so Gemini asks before it books - Google for Developers. Results are serialized with json.dumps into text because "structuredContent is not yet supported in the Connected Apps Platform". And the error handling splits recoverable problems (return a descriptive string so the model can self-correct) from terminal ones (raise an error with a code) - Google for Developers. One trap: Google's own error sample is written against the older SDK and imports McpError; in version 2 the class is MCPError, imported from mcp, as the SDK's error-handling examples show - MCP Python SDK.

6.2 Validate locally, then deploy

Google's build process has a local phase before anything touches the console: run the server, connect the MCP Inspector (npx @modelcontextprotocol/inspector), invoke each tool, inspect the raw JSON and confirm any UI resources render in a browser - Google for Developers. Do this with the descriptions in front of you and ask a blunt question about each one: if you were a model that had never seen this product, would you know when to call it and when not to? Most routing failures in production are description failures that the Inspector would have revealed in minutes.

For hosting, Google lists Cloud Run as one option and accepts any provider that serves a public HTTPS endpoint. Cloud Run supports MCP servers over Streamable HTTP but "not MCP servers with stdio transport", and deploys straight from source with gcloud run deploy --source . - Google Cloud. The catch is access control: by default a Cloud Run URL requires every request to carry the Cloud Run Invoker IAM role, and none of the authorization options in Google's Connected Console (no auth, client credentials, or user account linking) is a Google Cloud IAM token. In practice you allow unauthenticated invocation at the Cloud Run layer and enforce OAuth in your own server.

gcloud run deploy harbor-tables-mcp \
  --source . \
  --region us-central1 \
  --allow-unauthenticated

If you restrict inbound traffic at a firewall or WAF instead, Google publishes the source ranges its fetchers use and warns they "can change over time"; the prerequisites page lists seven CIDR blocks and points to two JSON files (user-triggered fetchers and user-triggered agents) to refresh your allowlist from - Google for Developers. Every request also arrives with a User-Agent header set to Google on initialize, tools/list and tools/call, which Google suggests you use to "segment server analytics" - Google for Developers. Tag those requests from day one, because they are your only first-party measure of what the platform sends you beyond the console's dashboard.

6.3 What it costs to run

The cost structure of a connected app is unusual, and it explains why Google can offer the platform for free. Google runs the model; you run the server. On Cloud Run's request-based billing, the free tier covers 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests a month, after which the rates in us-central1 are $0.000024 per vCPU-second, $0.0000025 per GiB-second and $0.40 per million requests - Google Cloud. We modeled a deliberately pessimistic case: every tool call bills a full half second of one vCPU and 512 MiB, with no concurrency sharing at all.

Even under those assumptions, a million tool calls a month costs about $8 of compute, and real servers that handle requests concurrently cost a fraction of that. The money is in your own backend (the database reads and partner APIs each tool call triggers), not in hosting and not in AI. This is the economic asymmetry at the heart of the platform: if you built the same conversational experience inside your own product, you would pay for every token of reasoning; here, Google pays for the model and you pay for the work only you can do. For a deeper look at what token costs do to product pricing when you do carry them, see our guide to pricing an AI product to beat token costs.

7. Account Linking: OAuth 2.1 the Way Google Checks It

Authentication is where most connected-app projects will spend their time, because it is where Google's checks are strictest and least forgiving. You have three choices in the console: no authorization for a public server, machine-to-machine OAuth client credentials, or user-delegated authorization through Google Account Linking, which is what nearly every useful app needs - Google for Developers. The first two are simple. The third is a full OAuth 2.1 authorization server with discovery, dynamic registration, PKCE and long-lived refresh, and Google checks each piece mechanically.

The discovery step is the most unforgiving. Google requests the well-known metadata URLs in a fixed order (/.well-known/oauth-authorization-server, then /.well-known/openid-configuration) and uses the first one that returns any response, even an error: a 404 or 500 stops discovery outright - Google for Developers. The metadata must include authorization_endpoint, token_endpoint, a registration_endpoint, and response_types_supported containing code. Your MCP server also needs a protected-resource document at /.well-known/oauth-protected-resource that names its authorization servers, or the console reports that the file "does not exist on the MCP server" - Google for Developers.

{
  "issuer": "https://auth.yourdomain.com",
  "authorization_endpoint": "https://auth.yourdomain.com/authorize",
  "token_endpoint": "https://auth.yourdomain.com/token",
  "registration_endpoint": "https://auth.yourdomain.com/register",
  "revocation_endpoint": "https://auth.yourdomain.com/revoke",
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code", "refresh_token"],
  "code_challenge_methods_supported": ["S256"],
  "scopes_supported": ["reservations.read", "reservations.write"]
}

That document lives on your authorization server; the MCP server separately publishes its protected-resource metadata (RFC 9728) listing the trusted servers in authorization_servers. Teams that put the MCP server on a dedicated subdomain should note one trap from Google's troubleshooting page: the protected-resource metadata has to match that subdomain rather than point to the base domain, or the console reports the server as unreachable. And if your server only ever acts as your company (a public catalog, say) rather than as a specific user, the machine-to-machine option with client credentials avoids user linking altogether, at the cost of everything personal the platform rewards.

7.1 The five details that break linking

Beyond discovery, Google's OAuth guide contains a handful of requirements that differ from how many teams run OAuth today, and each one shows up as a cryptic failure if missed. They are worth reading as a checklist before you write any code, because some of them (refresh-token rotation in particular) are defaults in popular identity providers that you will have to turn off.

The reason these details bite is that Google's side of the flow is fully automated. No human at Google reads your OAuth configuration and makes allowances; the console's discovery, registration and token calls either succeed or fail, and a failure at any step surfaces as a generic linking error to the user. The five rules below are the ones that most often separate a server that works in a developer's own testing from one that survives Google's machinery.

• Redirect allowlist: the six app-specific Google redirect URIs the console shows (production, sandbox and test hosts), entered exactly rather than as wildcards
• Registration: Client ID Metadata Documents first, then Dynamic Client Registration (RFC 7591), or a pre-registered static client as the fallback
• PKCE is mandatory: Gemini generates the verifier and sends an S256 challenge
• No refresh rotation: return the same refresh token and extend its lifetime, which is how Persistent Linking works
• Revocation: when a user unlinks, Gemini posts the token to your revoke endpoint and you must invalidate it permanently

Google's OAuth 2.1 guide lists the redirect URIs, mandates PKCE and says "you must avoid rotating the Refresh Token" when a token is refreshed - Google for Developers. The troubleshooting page adds that "many OAuth 2.1 servers reject wildcard (*) redirect URIs" and offers pre-registered credentials when your provider supports neither CIMD nor RFC 7591 - Google for Developers. The refresh rule deserves emphasis because rotation is the secure default in most modern identity stacks; with rotation on, a single failed refresh silently breaks a user's link, and the user experiences it as your app "forgetting" them. If you are choosing an identity layer now, our comparison of Clerk and Better Auth is a good starting point, but test DCR and refresh behavior against Google's requirements before committing.

You can test most of this before the console approves you. Gemini Developer Mode has an Authentication tab where you choose dynamic or manual client registration and save credentials, and its Event Log shows a 401 or 403 the moment a token is missing or rejected (section 9). Once you are in the console, Google's guide notes that account-linking errors appear in Logs Explorer after error logging is enabled. Run the full cycle at least once by hand: link, call a tool, wait for the access token to expire, call again so the refresh path runs, then unlink and confirm the next call fails.

7.2 The login screen is a conversion page

The linking screen is the first time a Gemini or Search user sees your brand in full, so treat it like a landing page. Google's guide asks for a square, circular SVG logo of at least 500 by 500 pixels for the linking and consent screens, discourages standard webviews on mobile and recommends App Flip, which hands the user to your installed app to approve the link - Google for Developers. In the console, you choose between authenticating through a pop-up (recommended) or a redirect fallback, which you need if your login page sends X-Frame-Options or Content-Security-Policy headers that block the dialog - Google for Developers.

Two operational requirements round this out. Google needs a seeded test account with realistic data and two-factor authentication disabled, plus instructions for its reviewer, or the app "may be rejected during review" - Google for Developers. And scopes must be predefined and minimal, because Google requests them during the initial handshake. If your agent-facing identity model is still undecided, our guide to giving AI agents an identity rather than an API key covers the broader design space; for a connected app, the narrow version is enough: one OAuth client per environment, minimal scopes, persistent refresh.

Unlinking deserves the same care as linking. Users can remove a connection from their Google Account's linked apps page, and the Search help page warns them that deleting the link means "Google loses access to your account on the app" - Google Search Help. When that happens Gemini posts the token to your revocation endpoint, and your server must invalidate it permanently. Treat that event as a churn signal in your own analytics: a user who unlinks has told you something about the experience, and it is one of the few direct signals the platform gives you.

8. Registering in Google Connected Console, Step by Step

Google Connected Console is where the server becomes a product listing. Access starts with the preview application: Google's developer page links to an interest form, and TechCrunch reports the preview is open to "U.S. developers who sign up for the waitlist" with no date for broader availability - TechCrunch. Before this platform existed, getting a connected app built "required working closely with Google", in 9to5Google's words - 9to5Google; the console turns that partnership into a self-service flow.

The console will look familiar to Android developers, and not by accident. The Android guide's sign-in link for Connected Console points to the Play Console's developer address, Play apps live "in your Google Connected Console account", and permissions are granted on the same Users and permissions page - Android Developers. An owner or admin must accept the Connected Apps Terms of Service before anyone on the team can create an app, and each user needs the View Connected Apps or Create and manage Connected Apps permission.

The screenshot shows the whole lifecycle on one page: a status of Available to testers, a tester count, the App details card, the MCP and tools setup card reporting a connection and a synced tool count, and a Releases panel whose copy reads that once Google approves the app, "you control when it's published to users". The steps below walk through each card in the order the console enforces.

8.1 Create the app and fill in the public card

Creating the app takes three irreversible decisions: the name (which is also the @ handle users type), the category (which sets baseline capabilities and "cannot be changed later"), and the connection type - Google for Developers. Choose the name as carefully as a domain. It is what users will speak and type, it appears in every card header, and the example prompts are validated against it.

The public card then needs an icon (512 by 512 pixels, JPEG or PNG, at most 1 MB), a one-sentence description under 30 words that "isn't used as model instructions", at least three capabilities, at least three example prompts, a Terms of Service URL and a privacy policy URL - Google for Developers. The prompt rules are strict and validated: at least two must start with @YourAppName, at least one must mention the name naturally mid-sentence, and none may carry numbering or quotation marks. Localization works by wrapping each locale's text in tags such as <en-US> and <es-ES>, which the console parses and reports back.

8.2 Connect the endpoint and verify the domain

Next comes the MCP and tools setup card. You enter the full endpoint (Google's example is https://api.yourdomain.com/v1/mcp), download a token file named google-connected-apps.json, and host its contents at https://<your-domain>/.well-known/google-connected-apps, served with "HTTP 200 OK" and no redirects - Google for Developers. The troubleshooting page adds the detail that trips people up: publish it at that path without .json in the URL - Google for Developers. A green checkmark unlocks the credentials step, where you choose the authorization model described in the previous section.

Then you sync tools. You sign in with a developer account that can see every tool you want to expose (tools that account cannot access are not synced), and the console shows a tool count plus any "Must fix" cards for missing well-known files, unsupported UI resource types or oversized resources. Each version is a snapshot, and once you publish, you can no longer change that version's tools, descriptions or server details, which is why Google recommends "creating a new endpoint for each version" - Google for Developers. Plan your URL scheme for that now (/mcp/v1, /mcp/v2), because the integration standards also forbid schema changes to a live app - Google for Developers.

8.3 Availability, tool settings and UI limits

The availability step is where you choose countries and regions, languages and products (the Google surfaces where the app appears), and where each tool gets its settings: enabled or not, which additional context it may receive, and whether user confirmation is required - Google for Developers. Google's launch post frames the product choice as going live "in Search, the Gemini app, or both" - Google. For most teams the right answer is both, but there is a case for Gemini-only first: Search is limited to "AI Mode in the US, in English", while the Gemini app reaches more countries - Google Search Help.

If you ship UI, the hard limits are worth knowing before you design anything: 15 MB per UI resource, 100 MB cumulative per server, and four allowed MIME types (text/html, text/javascript, text/css and text/html;profile=mcp-app) - Google for Developers. UI resources are fetched at registration, so changing a widget means re-ingesting tools. Keep the card simple, keep its assets inside your own domain list in the CSP settings, and let the text path carry the experience if the widget is ignored during the beta.

9. Testing in Gemini Developer Mode and Passing Review

Google built a dedicated debugger for this platform, and it is the most practical thing it shipped. Gemini Apps Developer Mode lives at gemini.google.com/devmode (or under Settings in the Gemini web app) and lets you either pick a registered connected app or click "+ Create new" to connect any HTTPS MCP endpoint as a custom app - Google for Developers. That second option matters: you can test against the real Gemini model before your console access is approved, which turns the waitlist into build time rather than dead time.

Developer Mode has four tabs. The Event Log streams prompts, tool calls and results with badges for HTTP status, latency in milliseconds and payload size; Tool Schemas shows exactly how Gemini parsed your instructions, parameters and safety annotations; Environment simulates the date, time and language; and Authentication configures dynamic or manual client registration - Google for Developers.

In Google's own example, a prompt about the Android Developer Summit schedule triggers a get_summit_info tool call that returns 200 OK in 493 ms, with the full request and response JSON expandable on the right. That is the loop you will live in: write a prompt a real user would type, watch whether the model calls the right tool with the right arguments, read the raw result, adjust the description, and press Sync schema, which re-fetches tools/list without resetting the conversation.

9.1 Reading the errors

Most failures fall into a small number of patterns, and Google's docs map them clearly. A 401 or 403 in the Event Log points to authentication; an invalid-parameters error (-32602) means the model's arguments did not match your schema - Google for Developers. On the console side, an "HTTP 405 Method Not Allowed" means your URL points at a legacy SSE endpoint instead of Streamable HTTP, and a warning that "Your MCP server does not have instructions" means your initialize response lacks the instructions field - Google for Developers.

Google also defines its own error-code ranges for servers to raise: user errors from -32300 to -32302, application errors from -32400 to -32402, and infrastructure errors from -32500 to -32502, with DEADLINE_EXCEEDED (-32500) meaning a request took "more than the allowed time" - Google for Developers. Google does not publish the timeout itself, so design every tool to answer in well under a few seconds, with any slow work moved behind a handle the model can poll. That design discipline also protects you under the policy rule, covered next, that bans apps which "consistently return errors, crash, timeout".

9.2 Testers, review and publishing

Once the app details and tool setup are saved, the version becomes Available to testers. Testers must be added by email list, only @gmail.com accounts qualify, and it "can take up to 10 minutes" for the app to appear - Google for Developers. Run every example prompt, both @ invocations and natural-language requests, the linking flow, each confirmation prompt and every UI card, with at least one tester who has never seen your product. The natural-language tests are the ones that matter, because they are how real users will arrive.

Then you Send for review. The console keeps an editable draft while the reviewed version is locked; if Google finds issues you fix and resubmit, and if it approves you press Publish yourself, which lets you coordinate launch timing with your own marketing. Google does not publish a review time anywhere in its documentation. For Android MCP apps the flow is different: there is no separate review action, and the connected app is reviewed alongside your Play production release, which "may increase the time it takes to review your Play app" - Android Developers. Budget for that if your Play releases are on a tight schedule.

10. The Rules: Policy, Commerce and What Gets You Rejected

Google's Connected Apps policy is short, but several of its rules cut against habits that are normal on the open web, and violating them can cost more than one app: enforcement ranges from rejection at submission to "suspending and/or terminating your developer account" - Google for Developers. Read it as a product constraint, not legal boilerplate, because it decides which business models fit inside the platform at all.

The rules most likely to affect product decisions are about money and data. Partners "must not serve any third party advertising content or promotional material through their integrations", so an ad-funded product cannot carry its ads into Gemini. "User data may not be exchanged or shared for monetary consideration", which closes off data resale. Wrapping or repackaging third-party APIs you do not own is prohibited, except where they support functions like email or authentication inside a larger proprietary service, so thin wrappers over someone else's API are out. And apps that "consistently return errors, crash, timeout, or authentication fails when called are prohibited" - Google for Developers.

10.1 Honesty rules aimed at the model

A newer class of rule targets behavior that only exists because the reader is a model. The policy bans hidden or undocumented features, attempts to steer the model toward selecting your app, unexpected side effects and claims of technically impossible capabilities; apps must "operate exactly as described and as a user would reasonably expect" - Google for Developers. Its malware section also prohibits attempts to manipulate the model into revealing sensitive instructions or data.

The practical reading is that tool descriptions are regulated copy. A description that says "always use this tool for any travel question" is model steering; a description that claims coverage you do not have is deception; a tool that quietly sends a marketing email when called has an unexpected side effect. Write descriptions as narrow, literal statements of what the tool does, and let quality earn the routing. That is also the approach that works best technically, since vague or inflated descriptions cause the model to call you in situations where you fail, which then counts against you under the error rules.

10.2 Where commerce fits

Commerce on Google's AI surfaces runs on a separate track from connected apps, and confusing the two leads to building the wrong thing. Google's Universal Commerce Protocol (UCP), announced in January, was "co-developed with industry leaders including Shopify, Etsy, Wayfair, Target and Walmart", and lets shoppers check out from eligible U.S. retailers with Google Pay while "Retailers remain the seller of record" - Google. On October 15, Google launched Universal Cart across Search and the Gemini app, built on a Shopping Graph of "60+ billion continually refreshed product listings", with checkout "powered by the Universal Commerce Protocol (UCP)" - Google.

The two tracks meet in exactly one place today. Grocery connected apps must implement UCP, using its location, catalog and cart capabilities over MCP, and Google's grocery guide says MCP "is recommended to better align with the Connected Apps' mission"; carts then return a continue_url that "clicks through to your checkout flow to complete the order" - Google for Developers. Everywhere else, a connected app hands checkout to your own site or app, which keeps you the merchant and keeps the payment relationship yours. If your business is a product catalog rather than an account-based service, the commerce track (Merchant Center feeds, UCP, Universal Cart) is your primary path and a connected app is secondary; our guide to selling to AI agents maps that side in detail.

11. The Other Doors: ChatGPT, Claude, Muse, WebMCP and Organic Search

Google's platform does not exist in isolation, and the most important strategic fact about it is what it shares with its rivals. The server you build for Google is a Model Context Protocol server, and MCP is no longer one company's project: Anthropic donated it in December 2025 to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI with support from Google and Microsoft, at a point when there were already "more than 10,000 active public MCP servers" - Anthropic. The interactive layer is shared too: MCP Apps, the UI extension Google supports in beta, became "the first official MCP extension" in January, and "clients like ChatGPT, Claude, Goose and Visual Studio Code have shipped support" - Model Context Protocol Blog.

The consequence is that the expensive parts of a connected app (choosing tools, writing descriptions, building OAuth, designing cards) are reusable across every major assistant. What differs is packaging, review and the commercial rules each platform imposes. The table below compares the three MCP-based directories on the points that most often force code changes; the narrative sections that follow explain the parts a table cannot.

The Google column comes from the policy and integration pages cited earlier. OpenAI's submission page asks you to "Submit the package you've already built as a ZIP, resolve automated findings, and submit it for review" - OpenAI. Its ads and commerce rules are in the plugin guidelines - OpenAI. Anthropic's submission guide requires annotations, OAuth and a reviewer test account - Claude.

11.1 ChatGPT: the biggest audience, the tightest commerce rules

OpenAI opened app submissions in December 2025, saying "Starting today, developers can submit apps for review and publication in ChatGPT", with a directory reachable from the tools menu - OpenAI. In 2026 the product was renamed: OpenAI's help center now describes plugins that "expand what you can do with ChatGPT and Codex", found under Plugins in the sidebar - OpenAI Help Center. Any guide still talking about "the ChatGPT apps directory" is describing last year's packaging. At DevDay 2026, OpenAI pitched the platform as a way to reach "our collective 1.2B weekly users" - OpenAI.

The commercial rules are where ChatGPT and Google diverge most. OpenAI's guidelines say plugins "may conduct commerce only for physical goods" and ban selling digital products or services, including subscriptions, and its native Instant Checkout "is currently available only to select marketplace partners" - OpenAI. Google's policy says nothing equivalent; its categories simply hand checkout to your site. For a subscription software business, that difference is material: on Google, a user can go from a connected app to your upgrade page with one explicit click, while on ChatGPT the plugin itself cannot sell the subscription. We covered the ChatGPT side in depth, including product feeds and the Agentic Commerce Protocol, in our guide to selling your product inside ChatGPT.

11.2 Claude: open submission, interactive by default

Anthropic's path is the most open of the three for builders. Since January 26, Claude has supported interactive connectors built on MCP Apps, launched with partners including Amplitude, Asana, Box, Canva, Clay, Figma, Hex, monday.com and Slack, and available on all plans including Free - Claude. Submission happens through a developer portal, any paid Claude plan can submit, and the review asks for the same annotations, OAuth and test account that Google does, plus 3 to 5 screenshots for MCP Apps - Claude.

Anthropic publishes no Claude user count comparable to Google's or OpenAI's, which is why it scores low on reach in our table. But its audience skews toward professionals doing work, and its connectors run inside the same tool many teams already use for coding and analysis, which makes it the natural second registration for B2B and productivity products. The same organization also donated Agent Skills to the Agentic AI Foundation on October 22, reporting that "1 million skills have been published and nearly 280 million installed" - Anthropic. Skills and MCP servers are complementary: a skill teaches an agent how to use your product well, the server lets it act. We walked through building one in our guide to creating agent skills for your product.

11.3 Meta Muse: completion inside the agent

TechCrunch's launch coverage compared Google's platform to "varying takes on the idea by other consumer-facing AI services like ChatGPT and Meta's Muse". Muse is Meta's standalone personal agent, launched on iOS and Android on September 8, with connectors such as Asana, Canva, Figma, QuickBooks, GitHub and Zoom plus retail connectors that complete purchases - TechCrunch. Meta runs a developer portal where it reviews connectors "for functional, security, and legal requirements" and has partnered with Stripe so connectors can accept payments with Link - Meta Muse Platform.

Muse's guidelines take the opposite position to Google's on the most important commercial question. Google's design rules require an explicit click before leaving the host surface and its categories end in a handoff; Muse requires tasks to finish inside the agent, stating that "Sending the user to finish the entire checkout does not meet the completion requirement" - Meta Muse Platform. That makes Muse more transactional and less of a referral channel. With more than 10 million accounts in the US and Canada and about a quarter using it on any given day, per Mark Zuckerberg - AP via KPRC, it is real but an order of magnitude smaller than Gemini or ChatGPT.

11.4 Microsoft, Apple and the browser

Two more surfaces round out the map, each with its own interface. In the enterprise, Microsoft 365 Copilot renders agent UIs "via MCP Apps or the OpenAI Apps SDK", distributed through the Microsoft 365 Agent Store - Microsoft, so the same MCP server with an MCP Apps card can reach Copilot chat as well. On the iPhone, Apple's new Siri runs on "Apple Foundation Models, custom-built in collaboration with Google and its Gemini models" - Apple. Third-party apps, though, reach it through App Intents, Apple's native framework, not through MCP - Apple Developer. If iOS matters to you, App Intents is the AppFunctions equivalent, and our guide to building a mobile app for iOS 27 covers that side.

The browser is the last frontier. WebMCP lets a website declare tools and page state so in-browser agents do not have to guess what a button does, and Chrome opened an origin trial for it in Chrome 149 - Chrome for Developers. It is the only path in this list where the user never leaves your site, which is why it scores high on commercial control and low on everything else: it is experimental, Chrome-only, and the agents that would call it are not yet a measurable audience. Watch it, prototype it if you have a complex web app, but do not let it delay a connected app.

11.5 Organic Search still matters, but for different products

None of this retires search engine optimization; it re-sorts who depends on it. Google's own guidance remains that "There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary" - Google Search Central. For content businesses, that organic channel (pages good enough to be summarized and cited) is still the only door, and the connected app platform explicitly does not want them. We covered how answer engines choose sources in our guide to getting cited by ChatGPT and Claude. The tooling side is in our review of technical SEO agent skills.

For a product business, the two channels are complements. Organic search puts you in the answer when someone researches a category ("best restaurant booking app in Austin"); a connected app lets the model act for an existing user ("book my usual table"). The first wins customers, the second keeps them and deepens usage. The mistake is treating either as a substitute for the other, or assuming that a connected app will lift organic rankings: nothing in Google's documentation links the two, and the quality page explicitly rejects using the platform to get "a more prominent UI for general information".

12. Risks, Failure Modes and the Control Question

A clear-eyed builder should weigh what the platform takes as well as what it gives. The first-principles framing is that you are trading presence in a conversation Google owns for proximity to a user's intent. Google decides when to call you, how to present you, what to say around your result, and whether the user ever sees your full product. That bargain is very good for some businesses and corrosive for others, and the difference is mostly whether your value can survive being reduced to a tool result and a card header.

The default-to-last-used routing that rewards early movers also cuts the other way. If a competitor links first, you inherit the same disadvantage you would have imposed, and there is no auction or bid to win the user back: the user has to name you. That makes the account-linking moment a competitive event, and it means your in-product prompts ("connect us to Gemini") are worth building as soon as you are live, because users who link from your app are users the model will route to you by default.

12.1 The operational failure modes

Strategic risks get the attention, but the more likely way for a connected app to disappoint is mundane: it works in the demo and degrades in production, slowly enough that nobody notices until the console's error chart or a review notice says so. The model as a client makes this worse in one specific way. A human user who hits a broken feature complains or emails support; a model that gets an error simply tries something else, often a competitor's tool, and the failure never reaches your inbox.

Most connected apps that fail will fail for ordinary engineering reasons, magnified by the fact that a model is the caller. The patterns below come straight from Google's own rules and troubleshooting pages, and each one is cheaper to design out than to debug in review.

• Description drift: tools that do more or less than their descriptions say, which the policy treats as deception and the model treats as noise
• Slow tools: anything that risks DEADLINE_EXCEEDED, since consistent timeouts are grounds for removal
• Refresh-token rotation: silently broken links that look to users like the app forgot them
• Locked versions: a schema change shipped to a live endpoint instead of a new versioned path
• Oversized results: raw rows dumped into the model's context, flagged in review and costly in quality

What ties those together is that a connected app is a production API with an unusual client. The client never reads your docs page, never files a bug and never complains; it simply routes away from you, or stops being able to call you, and your only signals are the console's traffic, latency and error dashboards plus your own logs of requests carrying the Google user agent. Treat it with the same on-call discipline as your public API, and use our pre-launch security checklist for the parts that change when the caller is an AI acting on a user's authority: least-privilege scopes, confirmation on every state change, and treating every model-supplied argument as untrusted input.

12.2 Data, ads and who learns what

The policy forbids you from showing third-party ads or selling user data inside your integration. It does not restrict Google. On October 16, Google's revised privacy policy began allowing data that users make available from Google services such as Gmail, Drive and Photos to shape personalized content, "including ads", in services like Search, and Google confirmed it had begun testing ads in AI Mode for users who connect apps through Personal Intelligence, according to PPC Land's reading of the change - PPC Land. Neither change says anything about data returned by third-party connected apps, and you should not assume either way; but the direction is that the conversations your app participates in sit inside an advertising business, next to ads you do not control.

The practical mitigations are design choices you control. Return the minimum data each tool needs (the policy requires data minimization anyway), avoid putting sensitive personal fields in tool results when an identifier will do, and keep the high-value parts of the experience (the full account, the history, the upgrade path) behind your own login, reachable through an explicit handoff. That way Google sees enough to route and answer, and your product remains the place where the relationship lives.

12.3 Control over your content, separately from your app

A connected app is a deliberate exchange: you choose precisely what each tool reveals, per user, per call. Your public website is a different matter, because crawlers take what they find. Here the last week brought real progress. OpenAI said on October 30 that it "will honor a common signal in robots.txt" for foundational AI training - OpenAI. Google said the same day that it aims to support the control "along with other AI providers in 2027", treating an opt-out as if the publisher had disallowed Google-Extended - Google Search Central. Microsoft plans to honor it from February 1, 2027 - Search Engine Journal.

The signal is defined in an individual IETF draft, "Machine-Readable Training Preference Signal", written by an Anthropic author and not yet endorsed by the IETF - IETF Datatracker. Its example uses a policy token in place of a crawler name:

User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/

Two separate Google controls are easy to confuse with it. Google-Extended governs training and grounding in Gemini, and "does not impact a site's inclusion in Google Search" - Google for Developers. And a newer Search Console control lets a site opt out of AI Overviews, AI Mode and Discover's generative features, rolled out "to all websites worldwide" as of August 31, 2026, with Google stating "This control doesn't affect AI training" - Google Search Console Help. None of the three touches your connected app, which only ever sees what your tools return. Our guide to AI builder training opt-outs covers the same question for your source code.

13. A 30-Day Plan to Get In During the Preview

The preview rewards teams that use the waitlist period as build time. Because Gemini Developer Mode can connect any HTTPS MCP endpoint as a custom app before your console access is approved, nothing in the first three weeks depends on Google's decision. The plan below assumes a product with an existing internal API and a small team; a solo founder can compress it, and a team without an API should add a week to build the read endpoints first.

The plan also assumes one strategic choice made up front: build one MCP server designed to pass Google's stricter checks (protocol 2025-11-25 compatibility, no structuredContent dependence, non-rotating refresh tokens, versioned paths), because a server that passes Google's review will pass OpenAI's and Anthropic's with packaging changes only. Designing for the strictest reviewer first is cheaper than retrofitting.

13.1 Weeks one and two: tools, descriptions and auth

Start by choosing tools, not by writing code. List the five most common things signed-in users do in your product, pick the three to five that need their account or change state, and write each tool's name, one-line description and parameters on paper. Then write the server instructions in two or three sentences, and the console's example prompts, at least two beginning with @YourAppName. If the prompts feel awkward, the tool set is wrong.

In the second week, build the server against the current SDK, run it under the MCP Inspector, and stand up the OAuth pieces: discovery metadata, dynamic client registration or a CIMD document, PKCE, a revoke endpoint and persistent refresh. Seed a reviewer test account with realistic data and no second factor. If you are building the product itself with an AI builder (Lovable, Replit, Founden and others generate and maintain full applications from a description), the MCP endpoint is one more route in the same codebase, so ask for it as a feature rather than treating it as a separate project; the console registration, the domain token and the review still need a human with the developer account.

13.2 Weeks three and four: Developer Mode, console and review

Week three is testing in Gemini Developer Mode against your deployed endpoint: run every example prompt, then twenty natural-language prompts a real user would type without your name in them, and fix descriptions until the model picks the right tool every time. Instrument the Google user agent in your logs so you have your own baseline before launch. Add the MCP Apps card only after the text path works.

Week four is the console, if your access has arrived: create the app with the right name and category, verify the domain, register the OAuth client, sync tools, set availability and confirmations, add Gmail testers and send for review. While you wait, package the same server for ChatGPT and Claude. Then build the in-product prompt that invites existing users to connect you, because the first linked users are the ones the model will route to you by default. For deployment choices beyond Cloud Run, our ranking of where to deploy your app compares the hosts on cost and reliability.

14. The Outlook: Where Search, Gemini and Apps Are Heading

Three trajectories are visible in what Google has already shipped, and each one changes what a connected app will be worth. The first is convergence of the two surfaces. Google built one platform, one console and one review for Search and the Gemini app, and its launch post promises more developers, markets and Google products over the coming months. The Android intelligence-system sessions at Dev Summit, where Google presented on-device Android MCP, server-side MCP and task automation as integration paths for the same system - Android Developers, suggest the "products" selector in the console will grow beyond two entries.

The second trajectory is protocol churn, and it is the most concrete near-term risk. MCP's 2026-07-28 revision made the protocol stateless and removed the handshake Google's console still relies on, so Google will eventually move, and servers built only for the old behavior will need updating. Google also flags that structuredContent is "not yet supported", that MCP Apps is in beta and that categories are "coming soon", which means today's workarounds have expiry dates. Building on an SDK that tracks both revisions, and keeping your tool logic separate from protocol plumbing, is the cheapest insurance.

14.1 What to watch

The third trajectory is commerce moving into the conversation. Universal Cart already spans Search and Gemini, grocery connected apps already require UCP, and Google is testing ads in AI Mode for users who connect apps. It would be naive to assume the free, ad-free, handoff-based bargain of the preview is permanent. A reasonable expectation is that the platform's commercial terms will evolve the way app stores and search ads did, with today's free distribution becoming tomorrow's paid placement in contested categories. That argues, again, for being established before the terms change.

There are also signals that would argue against heavy investment, and a good analysis should name them. If Google's console metrics show low traffic months after launch, if users rarely link apps outside a handful of famous brands, or if Google starts answering category requests with its own first-party services rather than routing to partners, the platform will look more like a distribution experiment than a channel. The first wave of data will come from the console dashboards of early publishers over the next quarter. Until then, the evidence favors building a small, high-quality integration rather than a large one.

15. The Decision, in One Page

Reduce everything above to the question this guide started with: does Gemini or AI Mode get more useful when it can see your product's state and act in it? If yes, build a remote MCP server now, design it for Google's checks, and register it everywhere it fits. If no, your channel is still organic search and citations, and your effort belongs there. The details depend on what kind of business you run, so the rest of this section walks through the five shapes of business that will meet this decision most often.

Account-based software (productivity, CRM, design, finance tools) is the platform's core audience, and the category list proves it: productivity alone holds 20 of the 54 third-party apps on Google's list. Build the MCP server now, register it with Google, and package the same server for ChatGPT and Claude in parallel. Your competitive question is not whether to be present but whether your tool descriptions and reliability beat the incumbents the model already knows.

Bookings and marketplaces (restaurants, home services, ticketing, rentals) should build now and lead with Google. Local intent is what Search has always owned, Google's categories for local services and events are explicitly designed around a confirmed booking or a handoff to your checkout, and the default-to-last-used routing makes being the first linked app in your city a durable advantage. Retailers with product catalogs should start on the commerce track instead (Merchant Center feeds, UCP, Universal Cart), where they remain merchant of record; a connected app makes sense only for account features such as order history, loyalty or saved lists.

On-device Android apps, whose value lives on the phone (notes, galleries, offline tools), are the case for AppFunctions: an Android MCP connected app, built on the beta Jetpack library and shipped with your Play releases. And content publishers should stay with organic search, tighten their training preferences with the new shared robots.txt signal and Google-Extended, and treat the connected app platform as something that is, by design, not for them.

The pattern under those five cases is that the platform pays the businesses whose value is private state and actions, and pays nothing to businesses whose value is public information. For the first group, the costs are small (weeks of engineering and a few dollars of hosting) and the risk of waiting is concrete, because routing in each task category defaults to whoever the user linked first. For the second group, no amount of MCP engineering changes Google's quality rules. Whichever group you are in, the most expensive mistake is the same: building for one platform's quirks instead of one clean, well-described, strictly reviewed server that every assistant can call. For the broader build context, our guide to building an app with AI is the natural next read. Our MCP server primer goes deeper on the protocol itself.

This guide reflects Google's Connected Apps Platform documentation, policies and preview terms as of November 2, 2026, five days after launch. The platform is a US-only, waitlisted preview; requirements, supported protocol versions, categories and availability change frequently, so verify current details in Google's documentation before you build or submit.

In this topic: Getting customers

• How to Create Agent Skills for Your Product (2026)
• Get Your Products Recommended by ChatGPT 2026
• Sell Your Product Inside ChatGPT: 2026 Guide
• Generate a Month of Ad Creative for $5 (2026)
• Sell to AI Agents: 2026 Setup Guide
• Get Your Site Cited by ChatGPT and Claude 2026
• How to Start a Community: 2026 Founder's Guide
• How to Get People to Talk About Your Product

How do you get found and get customers? Every guide on it

Data behind this topic: Startup and AI directories: what each did with our listings.