Getting your app into Gemini and Search: pick two actions first

What Google opened on Wednesday

If you own an app or an online service, someone on your team has probably already forwarded you this one with a question mark.

On October 28, at Android Dev Summit, Google launched the preview of its Connected Apps Platform. It's one place for developers to put their own app's actions inside Google's products. A user connects your app once, and after that they can ask Gemini, or Search, to look something up or get something done in your service without opening it.

Google's pitch is that you can "build once and reach high-intent users across both Search and the Gemini app." You connect either a cloud-hosted MCP server or your Android app, register it in a tool called Google Connected Console, test it, and choose whether it goes live in Search, the Gemini app or both. Once it's live, Google says you can track traffic, latency and error rates and keep your brand on it, with verified logos and authenticated accounts.

It isn't empty. Google says more than 50 Connected Apps are already live between Search and Gemini. Adobe, Experian, Localiza and Peloton are live in Gemini and coming to Search in the coming weeks, and Calm is launching across both.

So the question we expect to hear this week is simple: should we be in there, and what would it take? Here's how we'd work through it with you, in the order we'd actually ask. (If what you want is the opposite, Gemini reading your business tools, that's a different product. We looked at it in our Gemini small business hub review.)

Which one or two things do people already ask you for?

Don't start with the platform. Start with your support inbox, your search logs and the top three things people open your app to do.

The best first action is usually boring. Where's my order. When's my next class. What's my balance. Book the usual table. These are things people already say out loud, they're easy to describe and they don't hurt anyone if the answer comes back slightly wrong and the person checks.

Google's own guidance points the same way. Its AppFunctions quality guidelines say to "Perform only safe, non-destructive tasks that the user would normally do in your app," and to focus on tasks that are easier to say in a conversation than to tap through. They also warn against breadth: "Don't create multipurpose AppFunctions, or expose many AppFunctions for the same use case." When several functions sound alike, the agent is more likely to pick the wrong one.

You'll still need to describe more than one thing. The listing in Connected Console asks for at least three capabilities and at least three example prompts, at least two of which start with your app's name. That's fine. Three capabilities can all sit on top of one honest action: search your orders, check a delivery, see your order history.

Our rule of thumb for the first version: one action people can read, and at most one action that changes something small and reversible. Ship that, watch the error rates Google now shows you, then add the next one.

What has to wait for the customer to say yes?

This is the question that matters most, and it's the one teams skip because it feels like a detail.

Anything that spends money, cancels, deletes, sends a message to someone else or changes an account should wait for a clear yes from the person. The platform gives you two places to say so. On the hosted-server path, Google's MCP server guide asks you to mark read-only tools with readOnlyHint and state-changing or destructive ones with destructiveHint, and Connected Console has a per-tool User confirmation required setting. It's switched on for you when a tool is marked destructive. On the Android path, Google's AppFunctions guide says that for destructive actions "your app should include its own confirmation step," and suggests more than one.

Some things shouldn't go through the agent at all. The quality guidelines are blunt: "Don't design AppFunctions that require or return passwords, financial details, private keys, or other highly sensitive personal information." Android Central's write-up of the launch describes how Instacart already handles this inside Google's AI Mode: the assistant fills the cart, then stops at payment and sends you into Instacart to finish. That's a good pattern to copy. Let the agent do the tedious part and keep the moment of commitment in your own app.

Watch what you ask for, too. Each tool can request extra context from Google, like the user's locale, approximate location or precise location. Google warns, "Your connected app may not pass review if tools request more context than required." If the store finder works on a city, don't ask for a pin.

We've argued before that some approvals should never be automated. This is the same idea with a new front door.

Hosted server or the Android app?

There are two ways in, and they reach different places.

A hosted MCP server. Google calls this "our recommended default path for foundational, cross-platform capabilities." It's the route for web services and for anyone who wants Search as well as Gemini. Connected Console describes it as the way to provide your services "to Gemini and Search users across web, Android, and iOS." The prerequisites are mostly plumbing: a public HTTPS endpoint (one global endpoint per connected app), allowlisting Google's IP ranges if you filter by IP, a verification file under /.well-known/ on your domain, OAuth if people sign in to use the tools, and privacy policy and terms URLs.

Android MCP, through AppFunctions. Here your Android app itself becomes the tool, and the work runs on the phone. AppFunctions needs Android 16 or higher, a project with compileSdk set to 36 or above and the Jetpack library, currently 1.0.0-alpha10. Google labels the whole thing experimental and subject to change. According to the Connected Console guide for Android, you need an existing Play app in the same developer account with a default store listing, an icon and supported languages, plus an Android App Bundle (.aab) with your AppFunctions in it. Your Play listing's languages and country targeting decide where the connected app is available, and the guide describes the destination as Gemini on Android. It doesn't mention Search for this path.

So, roughly: if you're a web service, or you want Search, plan on the server. If your best action depends on what's already on the phone, look at AppFunctions, knowing it's earlier.

Plan for the review, not just the launch

A few things in the setup are permanent, and they're easy to get wrong in a hurry.

Your connected app's category can't be changed after creation, and it sets baseline capabilities you're expected to support. On the Android path, "Each Play app can only be linked to a single Android MCP connected app," and once you pick the Play app you can't change it. On the server path, Google takes a snapshot of your tools when you publish a version, and after that you can't change the tools, descriptions or server details without a new version.

Then there's the reviewer. If people sign in to use your tools, Google asks for test credentials with realistic sample data and two-factor authentication switched off. The setup guide is clear about why: "If Google cannot fully test your connected app, it may be rejected during review." An empty demo account is a common way to stall. On Android, the connected app is reviewed alongside your Play release, "which may increase the time it takes to review your Play app," so don't stack it on a release you need out on a fixed date.

And it's a preview. Google says, "We're opening access in phases, and will add more developers, markets, and Google products over the coming months." You apply through an interest form. For AppFunctions, Google's own FAQ says that during the experimental phase "only a limited number of apps and system agents can access the entire pipeline." Testers have to use @gmail.com accounts. None of that is a reason to wait. It's a reason to apply now and build the first action while you're in line.

What to bring to the first meeting

If you're deciding whether to do this, here's what we'd want on the table:

• The two or three requests people make most often, in their own words.
• For each one: does it only read, or does it change something? Who undoes it if it's wrong?
• Which actions need a customer's yes, and which should send them back into your app to finish.
• Whether you're a web service, an Android app or both, and whether Search matters to you.
• The account that will own Connected Console and accept the terms, and who on your team can manage Play releases.
• A seeded test account a reviewer can actually use.
• What you'll watch once it's live, and who looks at the error rate on Monday morning.

That list fits on one page, and it's most of the work. The code that follows is smaller than people expect when the first version is small enough that a reviewer, and a customer, can see exactly what it does.

If you'd like help with the app side, AppFunctions included, that's our mobile application development work. For a hosted MCP server and the agent design around it, see AI applications and agents. Or bring us your top three requests and we'll help you pick the first one.

Related work: Spin:Market.