Google's Connected Apps Platform: Make Your Service

By Lazar Milicevic · Published October 30, 2026 · 9 min read

You run a small business or ship a SaaS product, and you've probably noticed that people increasingly ask an AI assistant instead of opening a browser tab. On October 28, 2026, Google put out a way to be one of the services that assistant can actually call. Here is what the Connected Apps Platform is, what it demands technically, what we don't know yet, and how to prepare without betting the company on a preview.

What Google actually announced

Google announced a preview of the Connected Apps Platform, described as a single place for developers to build and manage apps for Search and the Gemini app. Instead of an assistant only summarizing the web, it can call your service directly: look something up, check a booking, start an action.

The mechanics, per Google's announcement:

• You integrate through a cloud-hosted MCP server, or through Android MCP using the AppFunctions APIs.
• You register, test and submit the app in the Google Connected Console.
• Before review, you choose whether the app goes live in Search, the Gemini app, or both.
• After launch, you can track traffic, latency and error rates, and manage brand identity, including verified logos and authenticated accounts.

Why it matters beyond the headline: before this platform, Google's connected apps came from a set of chosen partners. According to AI Agent Blog's write-up, the new platform opens the process to any business or developer who wants to reach users through Search or Gemini. Google says it has launched more than 50 Connected Apps across Search and Gemini, in areas from productivity and event ticketing to health and fitness. Adobe, Experian, Localiza and Peloton are already live in Gemini and will come to Search in the coming weeks, and a new Calm integration will launch across both.

Primary source: Google's announcement.

What we don't know yet

Several things that matter for a business decision are undisclosed, and I'd rather list them than let you assume.

• Pricing, fees or revenue share. Google's announcement says nothing on this. Don't assume the platform is free or paid.
• Review duration and admission criteria. Not disclosed. Plan with no timeline.
• Markets and languages. Search availability is described as AI Mode in the US, in English (per Google's Search Help page, as reported by Relevant Audience). Gemini availability is set per app; Localiza, for example, is Brazil-only in Portuguese. Beyond that, nothing is confirmed.
• How requests get routed between competing apps. If two ticketing apps both fit a query, how Google chooses is not documented. Nothing published says connected apps get a ranking or discovery advantage.
• Access mechanism. TechCrunch reports a US public preview for developers who sign up for a waitlist; Google's docs describe onboarding in the Connected Console. The safest reading: apply or sign up, and expect access to open in phases. Google says it plans to add more developers, markets and Google products over the coming months.
• Outcome data. The console shows traffic, latency and error rates. Nothing in the announcement mentions conversion or revenue reporting, and Google gave no usage figures. Claims that this channel brings "high-intent users" are marketing, not data.

So this is a preview with open commercial questions. That shapes the advice below: build things that are valuable regardless of how this particular platform plays out.

The technical contract: what your MCP server must satisfy

Google's integration standards are specific, and they're stricter than a hobby MCP server. These come from Google's MCP integration standards page:

Three of those deserve emphasis.

Version pinning. If you've been building against a newer MCP spec revision, you may need to hold your server to 2025-11-25 for this target. Check what your SDK negotiates by default.

Schema freeze. Many teams treat tool definitions as living documents: rename an argument here, add a field there. A snapshot at registration means tool changes become a deliberate release process, not a casual deploy. Version your tool contract, and treat a change as a re-submission.

String IDs. This one bites quietly. If your database uses 64-bit integers and your tool schema declares them as integer, a client that parses JSON numbers as floats can corrupt the value. Declare them as strings:

{
  "name": "get_booking",
  "description": "Fetch a booking by its ID.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "booking_id": {
        "type": "string",
        "description": "Booking identifier. Pass as a string, not a number."
      }
    },
    "required": ["booking_id"]
  }
}

A minimal remote MCP server, shaped for this platform

Google's recommended default path is the remote MCP server, which per Relevant Audience's write-up works across Android, iOS and web. The Android MCP route runs on-device and is built with the Jetpack AppFunctions SDK; unless you already ship a native Android app, start with remote.

Here is a skeleton using the official Python MCP SDK's FastMCP helper. Check the SDK's current docs for exact options and for how to pin protocol behavior, since APIs shift between releases:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("acme-scheduling")

@mcp.tool()
def list_open_slots(service_id: str, date: str) -> list[dict]:
    """List open appointment slots for a service on a date (YYYY-MM-DD).

    service_id is a string, never a number.
    """
    return fetch_slots(service_id, date)  # your real implementation

@mcp.tool()
def create_booking(service_id: str, slot_id: str, customer_email: str) -> dict:
    """Create a booking for an open slot. Returns the booking_id as a string."""
    booking = book_slot(service_id, slot_id, customer_email)
    return {"booking_id": str(booking.id), "status": booking.status}

if __name__ == "__main__":
    # Streamable HTTP is required; legacy HTTP+SSE is not supported.
    mcp.run(transport="streamable-http")

Design notes that apply to any agent-callable service, not just this platform:

• Few, sharp tools. An assistant picks tools from their descriptions. "list_open_slots" beats a generic "query" tool.
• Request only what you strictly need. The policy rules reported by Relevant Audience say tools must ask only for data strictly needed. That's good practice anyway: every extra argument is another way for a call to fail.
• Fast, boring responses. The console tracks latency and error rates, and the same policy summary says apps that consistently return errors or time out are prohibited. Your server's uptime now directly affects whether your listing survives.

Console prerequisites and the registration checklist

Google's Connected Console guide lists the prerequisites: MCP server endpoints, IP allowlisting, domain verification and metadata assets. The flow is: create the app, connect the MCP endpoint, set availability, test with users, send it for review.

A secondary write-up of Google's docs (datastudios) adds specifics worth preparing now, with the caveat that you should verify them against the official docs before relying on exact numbers:

• Domain verification for a remote server uses a file at /.well-known/google-connected-apps that must return HTTP 200 with no redirects.
• The listing needs a 512×512 icon (JPG/PNG, up to 1 MB) and a description under 30 words.

The no-redirects detail is the kind of thing that wastes an afternoon. If your domain forces www or trailing-slash redirects, test the verification path explicitly:

# Expect a 200 and no Location header. Any redirect will fail verification.
curl -sS -o /dev/null -D - example.com

Prep list, none of which depends on being admitted yet:

1. Confirm your MCP server speaks Streamable HTTP and holds to spec 2025-11-25.
2. Audit every tool schema for numeric IDs; convert to strings.
3. Freeze tool names and arguments behind a versioned contract.
4. Find out your hosting provider's outbound IP ranges, since the console expects IP allowlisting.
5. Check that .well-known paths on your domain are served directly, not redirected.
6. Draft the icon and a description of under 30 words.

Policy rules that decide whether you're a fit

According to the policy summary reported by Relevant Audience, the platform prohibits:

• Pure wrappers around third-party APIs you don't own
• Multiple near-duplicate apps
• Apps that consistently return errors or time out

As with the other secondary-sourced specifics, confirm the exact wording on Google's site.

The wrapper rule is the strategically important one. It means the platform is for businesses that own a real service: a scheduling system, a catalog, a membership, a ticketing inventory. If your plan was to put a thin MCP layer over someone else's API and list it, that's the pattern the rules push against. The businesses that fit are the ones with their own data and their own transactions.

For a small business, a good first tool surface is read-heavy and low-risk: availability, pricing, order status, store hours. Write actions (create booking, cancel order) come second, after you've decided how authentication and confirmation should work. Brand identity management in the console includes authenticated accounts, so account linking is part of the picture; plan how a user proves who they are before your tool touches their data.

Should you build for this now? A decision framework

Because the commercial terms are undisclosed, treat this as a low-cost option, not a channel to depend on.

Move now if:

• You already run a clean API and an MCP server is an afternoon of wrapping, not a quarter of re-architecture.
• Your customers are in the US and use English (the stated Search scope).
• You own the underlying service, so the wrapper rule isn't a problem.

Wait and prepare if:

• Your market or language is outside the documented scope.
• Your tool surface would change weekly; the schema freeze will hurt.
• You'd need to invest heavily before knowing fees, review criteria, or whether you'd be admitted.

Either way, the work compounds. A well-described, string-ID, fast, versioned MCP server is useful to other agent surfaces too, including other assistants, internal automation, and customer-built workflows. The Google-specific part is registration and verification, which is small next to the server itself. Don't tie your roadmap to one platform's preview; tie it to making your service callable.

A reasonable sequence:

1. Week 1: Inventory what your service can expose safely. Pick 3 to 5 read-only tools.
2. Week 2: Build the remote MCP server with Streamable HTTP; test with a standard MCP client.
3. Week 3: Harden: string IDs, timeouts, error messages that an agent can act on, request logging.
4. Then: Sign up for the preview, work through the console prerequisites, and test with real users before submitting.

Measure latency and error rate yourself from day one. The console will show them, but you want your own numbers first.

How BizFlowAI approaches this

Making a business service callable by an AI agent is the same work whether the front door is Gemini, another assistant, or your own internal tooling: expose a small, well-described set of tools over MCP, keep the contract stable, and make the server fast and observable. That's the integration work I do for small teams, where the practical questions are which two or three operations are worth exposing, how to handle authentication safely, and how to keep the schema from drifting.

I haven't seen Google's review process from the inside, and nothing here implies any partnership with Google; the platform is in preview and the commercial terms aren't public. If you want help planning an agent-ready integration (scoping the tool surface, auditing your API against the requirements above, or building the MCP server), book a discovery call and we'll work out whether it's worth doing now or after the preview matures.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.