Google Connected Apps for Gemini and Search

On October 28, 2026, Google opened a preview of its Connected Apps Platform. It is one place for a developer to build an app that works inside Google Search, the Gemini app, or both. A user can ask Gemini to book, order or look something up, and Gemini calls your service to do it. Google says more than 50 Connected Apps are already live between Search and Gemini, from companies such as Adobe, Experian, Localiza and Peloton, with Calm coming to both.

For a business that already takes bookings or orders online, this is a new front door. It is also a new way for a model to call your systems without a person watching each step. This post covers how the platform works, what we would expose first, and what to check before you submit.

We read Google's launch post on the Connected Apps Platform and its MCP server developer guide on October 29, 2026. Every Google fact below comes from those two pages. We have not shipped a Connected App for a client yet, so the workflows below are designs, not results.

You connect your service to Gemini and Search with a remote MCP server on a public HTTPS address, or on Android with AppFunctions. You test it in Gemini Developer mode, then register it in the Google Connected Console, pick Search, Gemini or both, and submit it for review. Access is opening in phases through an interest form. Expose a few clear actions, mark which ones change data, require a confirmation on anything that books, buys or cancels, and watch the error rate once it is live.

Google gives two ways in.

1. 1A remote MCP server. Google calls this the recommended default. It works across Android, iOS and the web, and if you already have web APIs or a remote MCP server, you can build on them.
2. 2Android MCP with AppFunctions. This is for deeper Android features that use content on the device and the current state of your app. Support comes through a Jetpack library.

Most service businesses will want the first path. A clinic, salon, property manager or delivery shop usually has a booking or ordering system with an API already, and the MCP server sits in front of it.

Once your app is live, a user can call it by name with an @ mention, and it stays in context for related prompts in that chat. Google's launch post says you can track traffic, latency and error rates, and keep control of your brand, including verified logos and signed-in accounts.

1. 1Build. Write the remote MCP server. Google asks for clear server instructions that describe your business and what the server can do, because the model uses them to decide when to hand a task to you. Every tool should carry a safety annotation: read-only lookups marked with readOnlyHint, and actions that change or delete data marked with destructiveHint. Give each tool typed arguments and plain descriptions of the allowed values, such as which service categories or locations it accepts. You can also attach your own UI to a tool result, which Gemini shows in a sandboxed frame inside the chat.
2. 2Validate. Run the server on your own machine and connect to it with the MCP Inspector (npx @modelcontextprotocol/inspector). Call each tool, read the raw JSON in and out, and check that any custom UI renders.
3. 3Deploy and test. Put the server on a public HTTPS address on any host. Google mentions Cloud Run as one option. Then test it live in Gemini Developer mode, which has tabs for the event log, tool schemas, a simulated date, time and location, and sign-in settings.
4. 4Register. Ask for access through the interest form. In the Google Connected Console you add your app details, set up sign-in and endpoints, discover your tools, manage preview testers, choose where it goes live, and submit it for review.

Start smaller than you think. A model calling your system on behalf of a stranger is a different risk from your own staff using it. Here is the order we would use.

1. 1Read-only lookups. Opening hours, services and prices, open slots, order status for a signed-in customer. These are marked read-only and cannot change anything.
2. 2Holds and drafts. Put a slot on hold for ten minutes, or build a cart, without charging or confirming. If the model picks the wrong thing, nothing is lost.
3. 3Confirmed actions. Book the slot, place the order, cancel a visit. Mark each one destructive and turn on the confirmation step in the Connected Console, so the user sees what will happen and says yes before it runs.

We would leave refunds, account changes and anything that moves money for a second phase, after you have a few weeks of logs to read.

Google's console has a place to set up how users sign in to your service. Plan who the model acts as. A booking tool that works with no sign-in is fine for open slots; a tool that reads past orders needs the user's own account, scoped to that user only.

Then put limits in your own server, not only in the instructions. Cap how many bookings one account can make in a day. Reject dates outside your booking window. Return a clear error message the model can read back to the user, such as "That slot was just taken, here are the next three," instead of a stack trace. Log every tool call with the account, the arguments and the result, so a support person can answer "why was I booked for Tuesday?"

Our guide on how to secure an MCP server for production covers sign-in, rate limits and logging in more depth, and local vs remote MCP servers explains why this one has to be remote.

These are setups we would build. None of them is a client result.

1. 1Appointment booking for a clinic or salon. Tools to list services, find open slots by date and location, hold a slot, and confirm it after the user says yes. The confirm tool writes to the real calendar and sends the usual confirmation email from your system, not from Gemini.
2. 2Order status for a small shop. A signed-in customer asks where their order is. The tool reads the order and the tracking number and nothing else.
3. 3Quote request for a service business. The tool collects the job details in a typed form and drops them into your CRM as a new lead for a person to price. The model never quotes a price you did not set.
4. 4Rental availability for a property manager. Read-only tools for units, rent and viewing times, plus a viewing request that lands in your leasing inbox for a person to confirm.

For each one we would test with the MCP Inspector, then in Gemini Developer mode with fake accounts, and run the checks in our checklist for testing AI agents before production before submitting.

Read the traffic, latency and error numbers in the console every week for the first month. A rising error rate usually means the model is sending arguments your server does not expect, which you fix with clearer tool descriptions and stricter types. Read a sample of your own logs too: look for bookings people cancel within the hour, which often means the model picked the wrong date or location.

If you have no API or online booking system yet, build that first; a Connected App needs something to call. If most of your customers book by phone and do not use Gemini, the effort may not pay back soon. If your booking rules live in a person's head, such as "Dr. Lee does not take new patients on Fridays," write them down as rules your system enforces before any model touches the calendar. And because access opens in phases, you may wait for a slot in the preview even with the server ready. In that case the same MCP server can still serve other AI tools that support remote MCP while you wait.

We build MCP servers in front of booking, ordering and CRM systems through our MCP development service, connect them to the rest of a business through systems integration, and set up AI agent systems that use them with approvals and logs. If you want to know which of your actions are safe to put in front of Gemini first, start with the free automation audit. For the basics, read what MCP servers are.

OrchestriAI is an independent implementation provider. Product names are used for identification only. OrchestriAI is not affiliated with, endorsed by, or sponsored by Google. This article summarizes Google's public launch post and developer guide as of October 29, 2026. The platform is in preview, so access, steps and limits can change; confirm them in Google's current docs.